How Services Communicate

Two styles

Services talk to each other in one of two ways, and most systems use both:

• Synchronous – a service makes a request and waits for a response, usually over REST/HTTP or gRPC.
• Asynchronous – a service publishes an event to a message broker and moves on; interested services react later.

Synchronous: REST between services

// Orders service asks Users service over HTTP
GET http://users-service/api/users/42
// waits for the response before continuing

Simple and easy to reason about, but it creates temporal coupling: if the Users service is slow or down, the Orders call suffers too. Guard synchronous calls with timeouts and circuit breakers.

Asynchronous: events

Instead of calling directly, a service emits an event to a broker like Kafka or RabbitMQ:

// Orders publishes and continues immediately
publish("order.created", { orderId: 100, userId: 42 })
// Billing and Shipping consume the event independently

This decouples services in time – the publisher does not care who listens or when – and improves resilience, at the cost of eventual consistency and harder debugging.

Choosing

• Use synchronous when you need an immediate answer (e.g. checking stock before confirming an order).
• Use asynchronous for “fire and react” workflows (e.g. send a receipt after an order is placed).

Key points

• Services communicate synchronously (REST/gRPC) or asynchronously (events).
• Synchronous is simple but couples services in time – use timeouts and circuit breakers.
• Asynchronous messaging decouples services and boosts resilience.
• Pick synchronous when you need an answer now, asynchronous for reactive workflows.