In a monolithic application, different components can communicate by calling methods or functions directly. Everything runs within the same application, so communication is usually fast and straightforward.

Microservices work differently. Each service runs independently, often on a separate server or container. When one service needs information or functionality from another, it must communicate over the network.

For example, consider an e-commerce application with separate services for orders, payments, inventory, and notifications. When a customer places an order, several things need to happen:

How should these services communicate? Should the Order Service call each service directly and wait for a response? Or should it publish a message and allow other services to process it independently?

These two approaches are known as synchronous and asynchronous communication. Choosing between them is one of the most important architectural decisions when designing microservices.

In synchronous communication, one service sends a request to another service and waits for a response before continuing. This follows the familiar request-response model.

For example, suppose the Order Service needs to check whether a product is available. It sends an HTTP request to the Inventory Service:

The Inventory Service checks its database and returns:

The Order Service receives the response and decides whether to proceed. The important characteristic is that the Order Service depends on the Inventory Service's response to continue its operation.

Common Technologies

Two popular technologies for synchronous communication in microservices are:

REST over HTTP

Services expose HTTP endpoints that other services can call. REST is widely used because it is simple, familiar, and supported by almost every programming language.

gRPC

Services communicate using Remote Procedure Calls, typically with Protocol Buffers for serialization. gRPC is particularly useful for internal service-to-service communication where efficient serialization and strongly defined contracts are important.

Both approaches allow one service to request information or trigger an operation in another service and receive a response.

Advantages of Synchronous Communication

1. Simple to understand

Synchronous communication follows a straightforward request-response flow. A service sends a request, receives a response, and continues processing. This makes the application easier to develop, especially when building a relatively small microservices system.

2. Immediate results

The caller receives the result of an operation directly. For example, when a user enters a coupon code during checkout, the Order Service can immediately call the Pricing Service to validate the discount. The user can see whether the coupon is valid without waiting for background processing.

3. Easier control flow

The sequence of operations is explicit in the calling service. Developers can usually follow the execution path from one service to another, making application logic easier to reason about. However, debugging still requires distributed tracing and good observability because requests cross service boundaries.

Disadvantages of Synchronous Communication

Synchronous communication becomes more challenging as the number of services grows.

1. Temporal coupling

The calling service needs the receiving service to be available and responsive at the time of the request. Suppose the Order Service calls the Inventory Service, but the Inventory Service is temporarily unavailable. The Order Service cannot complete the inventory check until the dependency recovers or the request fails.

2. Increased latency

Every network request adds latency. Imagine a checkout flow that makes three sequential service calls:

The checkout operation takes at least 270 milliseconds just for these service calls, excluding other processing. If one service becomes slow, the entire operation becomes slow. This becomes especially problematic when requests travel through long chains of services.

3. Cascading failures

Consider a dependency chain in which the Order Service calls the Payment Service, which in turn calls the Fraud Detection Service.

If the Fraud Detection Service becomes slow, the Payment Service may start waiting for responses. As more payment requests accumulate, the Payment Service may exhaust its available connections, threads, or other resources. Eventually, the Order Service may also experience failures.

A problem in one service has now affected multiple services. This is known as a cascading failure. To reduce this risk, synchronous communication should use appropriate timeouts, bounded retries, circuit breakers, and resource isolation.

Here is how slowness in the Fraud Detection Service travels back up the chain:

In asynchronous communication, a service initiates an operation without waiting for the receiving service to finish processing it. Instead of directly calling another service, the producer can publish a message to a message broker. The receiving service processes the message independently.

Let's return to our e-commerce example. After an order is created, the Order Service publishes an event:

Other services can react to this event. The Inventory Service might reserve the required items. The Payment Service might begin payment processing. The Notification Service might send an appropriate notification after the order is confirmed.

The Order Service does not need to wait for every downstream operation to finish before acknowledging that the order has been accepted. Instead, it can return an initial status such as:

The customer can check the order status later or receive an update when processing finishes.

The Order Service publishes the event once, and each interested service consumes it independently:

Common Technologies

Asynchronous communication is commonly implemented using message brokers and event streaming platforms.

Message Queues

Technologies such as RabbitMQ and Amazon SQS allow services to send messages that are processed by consumers. Queues are useful for distributing background work, such as sending emails or processing images.

Event Streaming

Apache Kafka allows services to publish events to topics that multiple consumers can process independently. Kafka is particularly useful for high-throughput event processing, data pipelines, and event-driven architectures. Asynchronous communication can also be implemented using other mechanisms, but messaging is one of the most common approaches in microservices.

Advantages of Asynchronous Communication

1. Loose temporal coupling

The producer and consumer do not need to be available simultaneously. Suppose the Notification Service becomes unavailable after an order is confirmed. With a durable message broker, the notification message can remain available until the service recovers and processes it. The Order Service can continue functioning without depending on the immediate availability of the Notification Service.

2. Better responsiveness

The initiating service does not need to wait for every background task to finish. For example, an application might accept a video upload and start processing it asynchronously. Instead of keeping the HTTP request open while the video is encoded, it can return a job identifier immediately.

The client can later check the processing status. This improves perceived responsiveness, although it does not necessarily reduce the total time required to complete the work.

3. Independent scaling

Producers and consumers can scale independently. Suppose an application receives 10,000 image uploads per minute, but its image processing workers can handle only 5,000. A queue can buffer the additional work temporarily. As demand increases, the system can add more workers to process messages faster.

However, queues do not eliminate capacity limits. If consumers remain slower than producers, the backlog will continue growing.

4. Better resilience

Temporary consumer failures do not necessarily prevent producers from accepting new work. Messages can be retained and processed after consumers recover. This makes asynchronous communication particularly attractive for workloads that can tolerate processing delays.

Disadvantages of Asynchronous Communication

Asynchronous communication improves decoupling, but introduces new challenges.

1. Eventual consistency

Different services may not update their state at exactly the same time. For example, the Order Service might create an order with the status PENDING, while the Payment Service is still processing the payment. For a short period, different services may have different views of the order's progress. The system must clearly define how these states are represented and eventually reconciled.

2. More complex debugging

In synchronous communication, the caller usually receives an immediate response. In asynchronous communication, processing might happen seconds or minutes later. A message may pass through several consumers before the complete workflow finishes. Debugging requires message identifiers, correlation IDs, distributed tracing, structured logs, and appropriate monitoring.

3. Duplicate message processing

Message brokers commonly provide at-least-once delivery, meaning a message may be delivered more than once. For example, a consumer might successfully process a payment-related message but crash before acknowledging it. The broker may deliver the message again.

If the consumer blindly processes every delivery, it could perform the same business operation twice. Consumers should therefore be designed to be idempotent, so repeated processing of the same logical request does not create duplicate effects.

4. Message ordering

Messages are not always processed in the order they were produced. For example, an OrderCancelled event might be processed before an earlier OrderCreated event if the messages travel through different queues or partitions. Applications that depend on ordering must design for it explicitly. Kafka, for example, provides ordering within an individual partition, not across all partitions.

5. Operational complexity

Asynchronous systems require additional infrastructure and operational practices. Teams must manage message brokers, consumer failures, retries, dead-letter queues, backlogs, and message retention. They must also decide what happens when a message cannot be processed successfully.

In real-world microservices systems, the best approach is often to combine both communication styles. Consider an e-commerce checkout system. When a customer places an order, the application may need to validate the shopping cart and calculate the final price immediately. Synchronous communication works well for these operations because the customer needs an immediate answer.

However, other tasks can happen asynchronously. For example:

If inventory reservation or payment fails, the workflow can mark the order as failed and perform necessary compensating actions, such as releasing reserved inventory. This is an example of an asynchronous business workflow.

The asynchronous part of the checkout, including the failure path, looks like this:

What happens if the database commit succeeds but publishing the event fails?

A common solution is the Transactional Outbox Pattern, where the service stores the business change and an outgoing event record in the same database transaction. A separate publisher reliably delivers the event to the broker. This pattern helps prevent lost events.

A useful rule is:

Use synchronous communication when the caller needs an immediate result. Use asynchronous communication when work can be processed independently.

Choose Synchronous Communication When

Common examples include checking account balances, fetching product information, validating permissions, and calculating prices.

Choose Asynchronous Communication When

Common examples include email notifications, video processing, analytics pipelines, order fulfillment, and event propagation. Keep in mind that asynchronous processing is not automatically more reliable. Reliability depends on durable messaging, correct acknowledgments, idempotent processing, monitoring, and recovery mechanisms.

Synchronous and asynchronous communication are two fundamental approaches to connecting microservices. Synchronous communication is simple, direct, and suitable when immediate results are required. However, it creates runtime dependencies between services and can contribute to higher latency and cascading failures.

Asynchronous communication allows services to process work independently, improving decoupling, responsiveness, and resilience to temporary failures. The trade-off is additional complexity around consistency, message delivery, ordering, and error handling.

In practice, most well-designed microservices architectures use both approaches. The key is to understand the requirements of each interaction and choose the communication model that provides the right balance of simplicity, reliability, performance, and scalability.