CODEWITHSUNDEEP
architecturemicroservicesdomain-driven-designintegrationapi-design
not_resolved
not_resolved

Reputation: 1

Filtering REST API responses and single responsibility

There is an online casino application that wants to get a filtered list of accounts by game type for a specific player that are available for enrollment winnings based on the request like

GET/players/accounts?playerId=123,gameType=roulette

There are also two microservices: Accounts, Games. The Accounts service has a list of playerId, accountTypeId, accountNumber. The game service has a list of gameType, accountTypeId

What should be the architectural solution for integrating this application with microservices in a high load microservice architecture?

My options:

  1. Option #1 If you make a request to the Accounts service as described at the very beginning, then there is a violation of the principle of sole responsibility. Because the Accounts service will need to make a second request to the Games service. Because to filter the list of accounts, he will need the key:value of the account type by game type.
  2. Option #2 The study of microservice architecture led to the Gateway API pattern, which says that you need to build an aggregating service that will make both requests and collect the response. That's the right decision? Could you add some pros and cons? What alternatives do you see?

Upvotes: 0

Views: 99

Answers (1)

paradise
paradise

Reputation: 511

Here is another solution.

Let's say that usually each microservice has its own database. If you know that your microservice A will query a lot microservice B because some of its data is required, another option is to duplicate relevant data from B to A. In such a way that B remains the "source of truth" regarding its data, but A becomes more autonomous.

This option brings another concern which is data consistency between B and A. The most used synchronization technique is to send an event from B to A whenever data is modified within B. This event has a payload which contains all necessary information to update data on A-side.
This solution will obviously require an eventing/messenging bus to be set up, with A subscribing to B's domain events.

Upvotes: 0

Related Questions