Imagine the follow basic (abstract) setup:

1 API Gateway -> GWAY

2 Auth service (i.e. keycloak) -> AS

2 Location microservice(s) -> LMS

3 Activity microservice(s) -> AMS

Every microservice would have its own database and is subscribed to a topic to consume events of interest.

The LMS manages the user location read & write. Can only query details related to location. The AMS manages the activity but requires a fixed location for the activity.

In theory the LMS could send out a message to the topic with the userId and location AMS who is interested consumes the message and updates its own database.

Here comes the concern Database IO. Imagine multiple instances of each microservice and a thousand active users. The every single AMS would be constantly starting up write transactions from the consumed messages to update their own database.

In the end the end I imagine requests have a lot of processing time because of all the write locks on the database. Is there a way around this problem?

I've seen people mention using the gateway can be a solution? i.e. gateway queries 2 services in a single request or something.

  • one database per microservice type not one per instance of that type
    – Ewan
    Oct 22, 2022 at 14:18

1 Answer 1


In theory the LMS could send out a message to the topic with the userId and location AMS who is interested consumes the message and updates its own database.

At this point you haven’t created micro services. You’ve created a distributed DB with eventual consistency. That’s not what micro services are typically built on.

A typical micro service architecture is built on the idea of each micro service being the single authority for whatever its subject is.

That means the location service doesn’t spam every database when it learns or updates a location.

Instead if you want to know where something is located now you ask the location service. If you want to record where something is located now without allowing that to change you simply ask the location service where it is now and retain what it said.

Done this way when locations change the only thing that needs to be told is the location service. Everything else can ask when it cares.

A sales record will have the location from when the sale was made. It will only ask for that once. When it makes the record.

This preserves each micro services authority and avoids duplicating information and unnecessary communication.

Now if you have multiple location services then sure, distribute that DB. Get your redundancy on. But don’t ask every micro service to be part of that.

Event driven architecture and micro services are different animals. But they both solve the problem of how to communicate between things.

Use one to solve problems the other solves means you’re duplicating work and confusing people. They solve the problem differently and each have their niches. They can be used together on the same project but not for solving the same problem.

And if anyone told you either is required to solve a problem they were either trying to sell you something or spent too much time listening to someone who was. Never assume you always need anything. Learn what they’re for.

  • Hey already a big thanks for the explanation, I do have one follow up question. From your reply I assume this communication between micro services can be http calls. But why is it often mentioned that an event driven architecture is crucial and the need of topics/queues? That only reason I can come up with now is to "message" other micro services to run logic based on the event. The result of the other micro services wouldn't be relevant for the response of the called microservice. Oct 22, 2022 at 13:23
  • @ViktorBaert better now? Oct 22, 2022 at 16:05
  • One thing that might be worth expanding on is the exponential problem of failure with respect to depth of requests. When you have two microservices this is mostly fine, but if the location service needs to ask a third microservice something to resolve activity microservices request, then the chance of failure is multiplied. Leading to an exponential chance of the request failing vs the depth of services called. Oct 22, 2022 at 18:49
  • The best way to avoid the issue of cascade failure is to not have microservices need to know about the information of other microservices too much. But if you do, event driven architectures allow you to avoid introducing the problem of cascading failures when things go down. Oct 22, 2022 at 18:50

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.