How Microservices Actually Talk to Each Other

"Just split it into microservices." Sure. But how do a dozen services actually talk to each other without turning into chaos?

That question trips up a lot of people moving off a monolith. Splitting the code is the easy part. Deciding how the pieces communicate is where systems succeed or quietly fall apart.

Here is the mental model I use.

One front door

A request comes in and hits one entry point: the API Gateway. It handles routing and auth, so no service is ever exposed directly to the outside world.

From there, the request fans out to the services that own each job: Auth, Orders, Payments. Each one owns its own database. No service reaches into another's tables. That data ownership is the whole point of the split.

Now the part people get wrong: how services talk to each other.

Two modes, and picking the right one is the real skill

There are two ways for services to communicate, and choosing correctly per interaction is what separates a clean system from a fragile one.

Call directly (synchronous)

Use a direct call, over REST or gRPC, when you need an answer right now. Checkout needs to know the payment succeeded before it continues. That is a synchronous call, and you accept that you are now waiting on another service.

Publish an event (asynchronous)

Publish an event, through a message broker, when others just need to know something happened, eventually. Order placed? Drop an event on the bus. The email service, the analytics service, and the inventory service all react on their own time. The order service does not wait for any of them, and does not even need to know they exist.

The trap

The trap is making everything a direct call.

Do that and you have not built microservices. You have built a distributed monolith, where one slow service freezes the whole chain and a single outage cascades everywhere. It is the worst of both worlds: the operational cost of many services with the fragility of one.

The quiet rule: call synchronously only when the caller genuinely cannot continue without the answer. Everything else is an event.

Your turn

That one decision, direct call versus event, shapes how resilient your whole system is. Get it right and services fail in isolation. Get it wrong and they fail together.

If you run microservices, where do you draw the line between a direct call and an event?