1

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?

4
  • 2
    I don't really understand your situation based on your description, but I can tell you that absolute uniformity is usually a non-productive goal to work for. Software that does interesting things is not uniform by definition, and sacrificing a simple solution to a simple problem for the sake of consistency seems inadvisable to me, unless that conformity produces benefits that exceed the benefits of the simple solution.
    – Robert Harvey
    Commented Mar 6, 2018 at 15:45
  • In response to the loose coupling argument, loose coupling has a specific purpose. You only need it if you need to fulfill that purpose. So ask yourself why it needs to be loosely-coupled. If the answer is demonstrably beneficial, then by all means, make the effort. Otherwise, all other things being equal, the simpler solution is generally the better one.
    – Robert Harvey
    Commented Mar 6, 2018 at 15:47
  • @RobertHarvey "A foolish consistency is the hobgoblin of little minds" Ralph Waldo Emerson
    – candied_orange
    Commented Mar 6, 2018 at 16:28
  • My team leader thinks that this maintenance process should be started by performing a simple function call from code which emits events your leader is right. It's part of the SRP of the process that emits the event. 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 that would be similar to a goto, and they are evil. Right? :-)
    – Laiv
    Commented Mar 6, 2018 at 16:51

1 Answer 1

Reset to default
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.