2

I have conceptual/design problem which I am not able to solve. I will try to explain it on sport terminology example, but of course same problem can be applied to e-shop or any other system.

I want to build 2 "standalone" micro services with API to perform needed actions. Service A will handle player management and Service B will handle team management.

In Service A I can for example perform player training, buy player items, set player appearance etc. In Service B I can for example set team tactic, hire team staff, set team appearance (logo, color) etc.

I have read many artictles and topic´s about microservices and as written in one article: "... hardest part about microservice = your data ..."

And here comes my problem. How and where I should store relation between player and team (imagine table TeamPlayer as simple relation table with columns player_id, team_id) ? So these are my concerns:

  1. Should be table TeamPlayer part of microservice A or B? Or should both micro services share same database?
  2. If it will be standalone databases and if I will decide that microservice B will store this relation how I can validate that player exists? What if somebody sent me wrong player identifier? Or do I need to care? Do I need to validate that player exists or this is not microservice B concern? Of course microserivce B knows teams, so I can return error when wrong team identifier is provided. I do not want to call microservice A from microservice B because then I will tight them together and made dependency on from microservice B to microservice A.
  3. If it will be standalone databases how I will read the data? Imagine that in UI I want list of player names inside team. Microsoervice B knows team and just relations and microservice A know names. Do I need to make at least two calls to collect data?
  4. If it will be shared database can microservice B read some data about player dicrectly from database? I can imagine some situation where this should not be allowed because of some access rights etc, but all these business logic is build in microservice A API which normally reads and return data about player.

How to solve this in the best way? Is API gateway the answer or how to do it in best way?

I hope so that it clear what are my concerns :)

MarioooCZ
  • 21
  • 2

3 Answers3

1

In general, the proper boundaries for microservices aren't going to line up that well with the normalized tables that you'd use in a monolithic application backed by a relational DB with foreign key constraints. Instead, I advise letting each service maintain its own view of the data it needs to perform its tasks (having services publish durable logs of events for changes to the state for which they control the writes is the mechanism I recommend). There are probably multiple "bounded contexts" in your conception of services A and B: it will probably make sense to have a microservice for each bounded context.

So with that in mind, what is a team? From the perspective of the "assign player to team" operation, a team is probably just a set of players associated with some sort of unique ID. Tactics and logo/color are irrelevant for that operation. All it needs is:

  • what players exist (derivable from the events published by a service which manages creating new players)
  • what teams have been created (this service might own that, or it could derive from the events published by a service which manages creating teams)
  • which players are on which teams (this service would definitely own that data)

Note that this approach does bring in eventual consistency: it won't be until some (likely short, think likely less than a second) time has passed since a player was created that an assignment of that player to a team will succeed.

Levi Ramsey
  • 18,884
  • 1
  • 16
  • 30
  • I had a related question on microservice boundaries - Extending the above example how would we implement business functionalities that do not have a data entity attached to it? i.e. they are pure business functions. They do not read or update data of their own but they are broad enough to be called as a separate business functionality and hence a different microservice. – Andy Dufresne May 06 '21 at 13:33
  • Those are basically sagas: they coordinate processes that are composed of multiple operations touching multiple services. They're not stateless: they still have to manage where in the process they are (because in microservices, you absolutely have to deal with partial failure (including of the service providing the saga) and then (most often) retry or rollback). That state should probably be a data entity of some sort (and making it so pays some dividends in terms of observability if nothing else). – Levi Ramsey May 06 '21 at 14:47
1

Considering the broad range of complex issues your question involves, I'll focus my response on the principal conceptual/design issue. With that in mind, I'm suggesting the following potential redesign:

  • Microservice A (Player Service): This service focuses on player-related functionality such as player training, purchasing player items, and modifying player appearance. It maintains its own dedicated database, which stores all pertinent player information.

  • Microservice B (Team Service): This service manages team-centric activities, including the setting of team tactics, the hiring of team staff, and altering team appearance (logo, color), among other functions. Like the Player Service, it too operates with its own dedicated database, holding all relevant team data.

  • Microservice C (TeamPlayer Service): This service is tasked with maintaining the relationships between players and teams. It houses a TeamPlayer table within its own standalone database. The table primarily consists of player_id and team_id columns. This service can offer APIs that manage the associations between players and teams.

The TeamPlayer service is also capable of performing validation to ensure the legitimacy of the provided player_id and team_id. It can do this by utilizing APIs offered by the Player and Team services.

Note that this approach is suitable even when you need to associate one player with multiple teams.

Davit Janashia
  • 11
  • 8
0

Short answer is - table TeamPlayer should be part of microservice A and B both.

For explanation I borrow the phrase from Levi's answer "I advise letting each service maintain its own view of the data". This is the correct way to design microservice.

You may raise questions on data duplication and data consistency. Yes, there will be data duplication but this is architecture trade-off to design, develop and maintain a microservice. On data consistency, eventual consistency should default mode to maintain database state unless there is specific use case (example - banking) to have strong consistency.

Hope this answer gives you clear and concise view of your design problem.

Dharman
  • 30,962
  • 25
  • 85
  • 135
Nitin Gaur
  • 922
  • 1
  • 14
  • 21