In microservices architecture, is it reasonable that service which emits event also listens to it?

Question

We have a complex app which built by using multiple microservices. At a runtime, one of the microservices emits an event to initialize some maintenance process in another microservices, it's ok. But lately, we were required to initialize a maintenance process at the same service from which this event was being emitted, and at the same time when this event is emitted.

My team leader thinks that this maintenance process should be started by performing a simple function call from code which emits events. I think that it will be more reasonable that service will listen to the event which it emits, and upon arriving this event maintenance process will be started.

I want to keep a consistent way in which all microservices initial the same process. It disturbs me that in one microservice this maintenance will be invoked in one way, while in other in a different way. Also, I think this is functionality which needs to be loose coupled.

What do you think?

Answer 1

If you have multiple instances of your Microservice running and they all fire the event, what happens? In other words, what safeguards do you have to ensure your maintenance process doesn't happen n times for each instance of your microservice?

That said, I can see both arguments.

• The pro for your side is that the trigger to start maintenance is the same in all microservices
• The pro for your team lead's side is that you are guaranteed that each instance of your application only handles it's own maintenance

Probably something to think about for your other services as well.

Unfortunately, there is no cut and dry answer to this, and since you are on a team you need to discuss the implications of either choice and make sure the team is on board.

These are the topics you need to discuss:

• Impacts to maintaining code
• Impacts to the reliability of the emitted event (i.e. running a function just after sending an event may have an impact on the timing of the next event)
• Impacts to scalability

That said, if you can't come to an agreement you both like, your team lead is the tie breaker. (S)He's on the hook to answer to management schedule impacts and decisions in the code base.