I'm designing an application in a microservices architecture. The app has its own logic but also needs to collaborate with other services.

For example, the app is A, and other apps are B and C. Whenever there's an event "X" happens in A, The B and C also need to do something like sth-B(), sth-C().

There are two ways that I can think of:

  1. Keep the logic in A. So A will know all the things to do when event "X" happens. It will do sth-A(), then call restful sth-B() and sth-C(). B and C are simply passive.
  2. Distribute logic to B and C. So A will only do sth-A() and publish the event "X" into a message queue. B and C will subscribe the event and do sth-B() and do sth-C() respectively. In this way, A doesn't need to care about what subscribers do, but it's hard to know what in the whole system are really being done when the event happens.

My questions are 1) are the above two design ways common? Do they have formal names? 2) Which one should I choose in a microservices architecture?

  • 1
    Is there any relation between the actions, besides that they are triggered by the same event? For example, might sth-B need information calculated in sth-A? How bad is it if one of the services is temporarily unavailable and processes the event much later than the others? The answers to these kinds of questions can help in determining how the microservices should interact (or not) with each other. Jul 9, 2019 at 7:59
  • Thanks @BartvanIngenSchenau for raising the important questions! Let's simplify the scenario, and assume the actions are independent.
    – Wei Huang
    Jul 10, 2019 at 4:04


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.