Choosing the right communication style between microservices is one of the most important architectural decisions you will make.

Get it wrong, and you end up with a fragile system where one failing service brings everything down. Get it right, and your services stay independent, scalable, and resilient.

In distributed systems, there are two fundamental ways services talk to each other: synchronous and asynchronous communication. Each comes with trade-offs in latency, coupling, reliability, and complexity.

Throughout my career, I have designed and built distributed systems using both approaches. In this post, I will break down how each communication style works, when to use each one, and how real systems often combine both to achieve the best results.

In this post, we will explore:

• How Microservices Communicate
• Synchronous Communication: HTTP and gRPC
• Asynchronous Communication: Message Brokers and Event Streaming
• Synchronous vs Asynchronous: Deep Comparison
• Hybrid Communication: Mixing Sync and Async in One Flow
• How to Choose: Decision Checklist
• Summary

Let's dive in.

In a Modular Monolith application, components call each other through in-process method calls. It's fast, simple, and reliable.

But when you break a Modular Monolith into microservices, those calls become network calls. And network calls introduce latency, failures, and a whole new set of challenges.

There are two fundamental approaches for microservices communication:

Synchronous communication: the caller sends a request and waits for a response before continuing. The caller is blocked until the response arrives or a timeout occurs.

Think of it like a phone call - you dial, the other person picks up, you talk, and you wait for an answer before continuing the conversation.

Asynchronous communication: the caller sends a message and moves on without waiting for an immediate response. The message is processed later by the receiving service at its own pace.

Think of it like sending an email - you send it and continue with your work, without waiting for the recipient to read and reply.

These two styles lead to fundamentally different system behaviors in terms of coupling, resilience, and scalability.

Now let's explore each communication style in detail.

Synchronous communication is the most intuitive way for services to talk. Service A calls Service B, waits for the result, and then continues its work.

The two most popular protocols for synchronous communication in .NET are HTTP (REST) and gRPC.

You can also use HotChocolate GraphQL Strawberry Shake for HTTP/REST communication. But this is a pretty niche approach. If you want to learn more about HotChocolate GraphQL, see this article.

HTTP-based REST APIs are the most common way microservices communicate synchronously. They are simple to build, easy to debug, and supported by virtually every language and framework.

Here is a typical example. The Booking Service needs to check room availability from the Property Service before confirming a reservation:

csharp
1public class PropertyServiceClient
2{
3    private readonly HttpClient _httpClient;
4
5    public PropertyServiceClient(HttpClient httpClient)
6    {
7        _httpClient = httpClient;
8    }
9
10    public async Task<RoomAvailability?> CheckAvailabilityAsync(
11        int propertyId, DateOnly checkIn, DateOnly checkOut)
12    {
13        var response = await _httpClient.GetAsync(
14            $"/api/properties/{propertyId}/availability?checkIn={checkIn}&checkOut={checkOut}");
15
16        response.EnsureSuccessStatusCode();
17
18        return await response.Content.ReadFromJsonAsync<RoomAvailability>();
19    }
20}

HTTP/REST works well when:

• You need a simple request-response interaction
• The client needs data immediately to continue
• You are building public APIs
• You want broad compatibility across languages and platforms

The main downside is temporal coupling - the caller must wait for the receiver to respond. If the Property Service is slow or down, the Booking Service is stuck.

gRPC is a high-performance RPC (Remote Procedure Call) framework built on HTTP/2. It uses Protocol Buffers (Protobuf) for serialization, which is significantly faster and smaller than JSON.

gRPC shines in service-to-service communication where performance matters.

Let's explore an example: how to check the room availability with gRPC.

First, define the service contract in a .proto file:

protobuf
1syntax = "proto3";
2
3option csharp_namespace = "BookingPlatform.Protos";
4
5service PropertyService {
6  rpc CheckAvailability (AvailabilityRequest) returns (AvailabilityResponse);
7}
8
9message AvailabilityRequest {
10  int32 property_id = 1;
11  string check_in = 2;
12  string check_out = 3;
13}
14
15message AvailabilityResponse {
16  bool is_available = 1;
17  double price_per_night = 2;
18  string currency = 3;
19}

Then call it from the Booking Service:

csharp
1public class PropertyGrpcClient
2{
3    private readonly PropertyService.PropertyServiceClient _client;
4
5    public PropertyGrpcClient(PropertyService.PropertyServiceClient client)
6    {
7        _client = client;
8    }
9
10    public async Task<AvailabilityResponse> CheckAvailabilityAsync(
11        int propertyId, string checkIn, string checkOut)
12    {
13        var request = new AvailabilityRequest
14        {
15            PropertyId = propertyId,
16            CheckIn = checkIn,
17            CheckOut = checkOut
18        };
19
20        return await _client.CheckAvailabilityAsync(request);
21    }
22}

gRPC works well when:

• You need low-latency, high-throughput communication between internal services
• You have strict performance requirements
• You want strongly typed contracts between services
• You need streaming capabilities (server streaming, client streaming, or bidirectional)

gRPC is not ideal for browser-to-service communication (though gRPC-Web exists as a workaround) or when you need human-readable payloads for debugging.

The biggest risk with synchronous communication is cascading failures. When Service A calls Service B, and Service B calls Service C - if Service C is down, all three services are affected.

To mitigate this, you should implement resilience patterns:

Retries with backoff - retry failed requests with increasing delays between attempts:

csharp
1builder.Services.AddHttpClient<PropertyServiceClient>(client =>
2{
3    client.BaseAddress = new Uri("https://property-service:5001");
4})
5.AddStandardResilienceHandler(options =>
6{
7    options.Retry.MaxRetryAttempts = 3;
8    options.Retry.BackoffType = DelayBackoffType.Exponential;
9    options.Retry.Delay = TimeSpan.FromMilliseconds(500);
10    
11    options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(10);
12    options.CircuitBreaker.FailureRatio = 0.9;
13    options.CircuitBreaker.MinimumThroughput = 5;
14    
15    options.AttemptTimeout.Timeout = TimeSpan.FromSeconds(2);
16});

The AddStandardResilienceHandler from Microsoft.Extensions.Http.Resilience gives you retries, circuit breaker, and timeouts in a single configuration.

Circuit Breaker - stops calling a failing service to give it time to recover.

When a service fails repeatedly, the circuit "opens," and all subsequent requests fail immediately instead of waiting for a timeout. After a cooldown period, the circuit "half-opens" to test if the service has recovered.

These patterns don't eliminate the problem of synchronous coupling. They reduce the impact. If you need true independence between services, you need asynchronous communication.

Asynchronous communication decouples services. The sender publishes a message and moves on. The receiver processes it when ready.

This decoupling makes your system more resilient: if a downstream service is temporarily unavailable, messages wait in the queue until the service comes back online.

There are several communication patterns that fall under the asynchronous style.

Point-to-Point integration: when one service communicates directly with another service by sending a message to a specific queue. In Point-to-Point, there is only one receiver.

Publish-Subscribe: when a service publishes an event, and multiple subscribers can react to it independently.

Both patterns are fundamental building blocks in distributed systems. You can learn more about these and other patterns in my article on 12 Essential Distributed System Design Patterns Every Architect Should Know.

There are two main categories of async communication: message queues and event streaming.

Message queues follow a Point-to-Point model. A producer sends a message to a queue, and a single consumer picks it up and processes it.

Once a message is consumed, it's removed from the queue.

This is ideal for task-based work - "process this payment", "send this email", "generate this invoice".

Popular message queue technologies include:

• RabbitMQ - a widely-used open source message broker with rich routing capabilities
• Azure Service Bus - a fully managed enterprise message broker on Azure with support for queues and topics

Here is an example of publishing a booking confirmation message to Azure Service Bus:

csharp
1public class BookingMessagePublisher : IAsyncDisposable
2{
3    private readonly ServiceBusSender _sender;
4
5    public BookingMessagePublisher(ServiceBusClient client)
6    {
7        _sender = client.CreateSender("booking-confirmations");
8    }
9
10    public async Task PublishBookingConfirmedAsync(
11        BookingConfirmed message,
12        CancellationToken cancellationToken = default)
13    {
14        var json = JsonSerializer.Serialize(message);
15        var serviceBusMessage = new ServiceBusMessage(json)
16        {
17            ContentType = "application/json",
18            MessageId = Guid.NewGuid().ToString()
19        };
20
21        await _sender.SendMessageAsync(serviceBusMessage, cancellationToken);
22    }
23
24    public async ValueTask DisposeAsync()
25    {
26        await _sender.DisposeAsync();
27    }
28}

And consuming it in the Notification Service:

csharp
1public class BookingConfirmationConsumer : BackgroundService
2{
3    private readonly ServiceBusClient _client;
4    private readonly ILogger<BookingConfirmationConsumer> _logger;
5
6    public BookingConfirmationConsumer(
7        ServiceBusClient client,
8        ILogger<BookingConfirmationConsumer> logger)
9    {
10        _client = client;
11        _logger = logger;
12    }
13
14    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
15    {
16        var processor = _client.CreateProcessor("booking-confirmations",
17            new ServiceBusProcessorOptions
18        {
19            AutoCompleteMessages = false,
20            MaxConcurrentCalls = 1
21        });
22
23        processor.ProcessMessageAsync += async args =>
24        {
25            var message = JsonSerializer.Deserialize<BookingConfirmed>(
26                args.Message.Body.ToString());
27
28            _logger.LogInformation(
29                "Sending confirmation email for booking {BookingId}", message!.BookingId);
30
31            // Send email, push notification, etc.
32
33            await args.CompleteMessageAsync(args.Message, stoppingToken);
34        };
35
36        processor.ProcessErrorAsync += args =>
37        {
38            _logger.LogError(args.Exception,
39                "Error processing message from queue {QueueName}", args.EntityPath);
40            
41            return Task.CompletedTask;
42        };
43
44        await processor.StartProcessingAsync(stoppingToken);
45
46        // Keep the service running
47        await Task.Delay(Timeout.Infinite, stoppingToken);
48
49        await processor.StopProcessingAsync(stoppingToken);
50        await processor.DisposeAsync();
51    }
52}

When a consumer fails to process a message, you don't want it to be lost. Dead-letter queues capture messages that couldn't be processed after a certain number of retries. This lets you inspect failed messages, fix the issue, and reprocess them later.

Azure Service Bus supports dead-letter queues out of the box.

It's a common misconception that message queues only support fire-and-forget. You can also implement a Request-Response pattern over message queues.

In this pattern, the sender publishes a request message with a correlation ID and a reply-to queue. The receiver processes the request and sends a response back to the reply-to queue. The sender correlates the response using the correlation ID.

This gives you the decoupling benefits of async communication while still getting a response.

And both services in Request-Response async communication don't know about each other.

You may consider Request-Response over queues when:

• You need a response but don't want tight synchronous coupling
• You want the broker to act as a buffer between services

It adds complexity compared to simple fire-and-forget, so use it only when you genuinely need the response back. And for such request-response cases, gRPC or REST can be a better choice.

Event streaming follows a Publish-Subscribe model. A producer publishes events to a topic, and multiple consumers can independently subscribe and process those events.

Unlike message queues, events are not removed after consumption. They are stored for a configurable retention period, which allows consumers to replay events if needed.

This is ideal for broadcasting facts - "a booking was created", "a payment was processed", "a guest checked in". Multiple services can react to the same event independently.

Popular event streaming technologies include:

• Apache Kafka - the industry standard for high-throughput event streaming
• Azure Event Hubs - a fully managed event streaming platform on Azure

Here is an example of publishing a booking event to Kafka:

csharp
1public class BookingEventPublisher : IDisposable
2{
3    private readonly IProducer<string, string> _producer;
4
5    public BookingEventPublisher(IConfiguration configuration)
6    {
7        var config = new ProducerConfig
8        {
9            BootstrapServers = configuration["Kafka:BootstrapServers"],
10            Acks = Acks.All,
11            EnableIdempotence = true
12        };
13
14        _producer = new ProducerBuilder<string, string>(config).Build();
15    }
16
17    public async Task PublishBookingCreatedAsync(BookingCreated bookingEvent)
18    {
19        var message = new Message<string, string>
20        {
21            Key = bookingEvent.BookingId.ToString(),
22            Value = JsonSerializer.Serialize(bookingEvent)
23        };
24
25        await _producer.ProduceAsync("booking-events", message);
26    }
27
28    public void Dispose()
29    {
30        _producer.Dispose();
31    }
32}

And consuming events in multiple independent services:

csharp
1public class BookingEventConsumer : BackgroundService
2{
3    private readonly IConsumer<string, string> _consumer;
4    private readonly ILogger<BookingEventConsumer> _logger;
5
6    public BookingEventConsumer(
7        IConfiguration configuration,
8        ILogger<BookingEventConsumer> logger)
9    {
10        _logger = logger;
11
12        var config = new ConsumerConfig
13        {
14            BootstrapServers = configuration["Kafka:BootstrapServers"],
15            GroupId = "analytics-service",
16            AutoOffsetReset = AutoOffsetReset.Earliest,
17            EnableAutoCommit = false
18        };
19
20        _consumer = new ConsumerBuilder<string, string>(config).Build();
21    }
22
23    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
24    {
25        _consumer.Subscribe("booking-events");
26
27        await Task.Run(() =>
28        {
29            while (!stoppingToken.IsCancellationRequested)
30            {
31                var result = _consumer.Consume(stoppingToken);
32
33                var bookingEvent = JsonSerializer
34                    .Deserialize<BookingCreated>(result.Message.Value);
35
36                _logger.LogInformation(
37                    "Processing booking event {BookingId} for analytics",
38                    bookingEvent!.BookingId);
39
40                // Process the event for analytics
41
42                _consumer.Commit(result);
43            }
44        }, stoppingToken);
45    }
46}

The key difference from message queues: multiple consumer groups can independently read the same events. The Analytics Service, Notification Service, and Reporting Service can all subscribe to booking-events and process them independently.

If you want to simplify working with message brokers in .NET, consider MassTransit or Wolverine.

MassTransit is an open-source abstraction layer that works with RabbitMQ, Azure Service Bus, Amazon SQS, and Kafka. It provides a consistent API, automatic retries, dead-letter handling, saga orchestration, and much more.

However, MassTransit recently moved to a commercial license model for production use. But still, MassTransit V8 will remain free with support until the end of 2026.

If you're looking for an alternative, consider Wolverine.

Let's compare synchronous and asynchronous communication across the criteria that matter most when designing microservice architectures.

Coupling

• Synchronous: high coupling - the caller depends on the receiver being available
• Asynchronous: low coupling - services are independent and communicate through a broker

Latency

• Synchronous: low latency - the caller gets an immediate response
• Asynchronous: higher latency - the message is processed later, not in real time

Service Availability

• Synchronous: if the receiver is down, the caller fails (unless you implement retries and circuit breakers)
• Asynchronous: if the receiver is down, messages wait in the queue and get processed when the service recovers

Scalability

• Synchronous: scaling requires load balancing across service instances
• Asynchronous: scaling is natural - add more consumers to process messages in parallel

Data Consistency

• Synchronous: easier to maintain strong consistency with immediate responses
• Asynchronous: eventual consistency - data may not be immediately up-to-date across services

Complexity

• Synchronous: simpler to implement, debug, and trace
• Asynchronous: more complex - requires a message broker, monitoring, dead-letter queues, and idempotency handling

Failure Handling

• Synchronous: failures are immediate and visible - you get an error response or timeout right away
• Asynchronous: failures can be silent - a message might sit in a dead-letter queue without anyone noticing unless monitoring is set up

Debugging and Tracing

• Synchronous: straightforward to trace - you can follow the request-response chain through logs
• Asynchronous: harder to trace - requires distributed tracing and correlation IDs to follow a message across services

Best Use Cases

• Synchronous: real-time queries, user-facing APIs, operations that need an immediate response
• Asynchronous: background processing, notifications, event-driven workflows, cross-service data synchronization

Neither approach is universally better. The right choice depends on your specific use case, and most real systems use both.

In practice, most microservice architectures don't use purely synchronous or purely asynchronous communication. They mix both styles in the same request flow.

The idea is simple: use synchronous communication where you need an immediate response, and asynchronous communication for everything that can happen in the background.

Here is a common pattern. A user books a hotel room:

1. The API Gateway receives the booking request (sync HTTP)
2. The Booking Service calls the Property Service to verify availability (sync gRPC)
3. The Booking Service calls the Payment Service to charge the guest (sync HTTP)
4. The Booking Service confirms the booking and publishes a BookingConfirmed event (async)
5. The Notification Service picks up the event and sends a confirmation email (async)
6. The Analytics Service picks up the same event and updates dashboards (async)
7. The Property Service picks up the same event and updates availability (async)

Steps 1-3 are synchronous because the user is waiting for a response. Steps 5-7 are asynchronous because they don't affect the user's immediate experience.

In some workflows, you can move Payment to an async flow as well, depending on your requirements.

For example, after booking, the user is redirected to a payment page and may receive an email notification that their booking is being processed and is awaiting payment. While the payment happens in the background, the user sees it as a seamless process in the same browser tab.

On the backend, it can be an asynchronous flow. Once the payment is confirmed, you send an email notification that your booking is now active.

This hybrid approach gives you the best of both worlds:

• The user gets an immediate confirmation because the critical steps (availability check, payment) happen synchronously
• Background work (notifications, analytics, availability updates) happens asynchronously without blocking the user
• If the Notification Service is temporarily down, the confirmation email is not lost - it waits in the message queue

The key principle is: be synchronous at the boundary, be asynchronous behind it.

What happens at the boundary (user-facing API) should be fast and responsive. What happens behind the boundary (service-to-service coordination) should be resilient and decoupled.

When you are deciding between synchronous and asynchronous communication for a specific interaction, walk through this checklist:

Use synchronous communication when:

• The caller needs data from the receiver to continue processing
• The user is waiting for an immediate response
• You need strong consistency - the caller must know the result before moving on
• The interaction is a simple query or lookup
• The operation is short-lived (milliseconds to low seconds)

Use asynchronous communication when:

• The caller doesn't need an immediate response
• The work can be done in the background
• Multiple services need to react to the same event
• You need resilience - the system should work even if some services are temporarily unavailable
• The operation is long-running (seconds to minutes)
• You need to handle traffic spikes - the message broker acts as a buffer

Use a hybrid approach when:

• The user-facing operation requires an immediate response, but the side effects can happen later
• You want fast response times at the API boundary but decoupled processing behind it
• Some parts of the flow require data from other services (sync), while others are independent reactions (async)

Use Request-Response over message queues when:

• You need a response but don't want tight synchronous coupling
• You want the broker to buffer requests during load spikes

Red flags that you need to switch from sync to async:

• You see cascading failures across services
• Timeouts are a frequent issue
• You are adding more and more retries and circuit breakers to keep things stable
• Downstream services can't keep up with the request volume
• You need to scale services independently but they are blocking each other

Red flags that you need to switch from async to sync:

• Users complain about stale data or delayed responses
• You need immediate confirmation or validation results
• Eventual consistency creates too many edge cases in your business logic

Synchronous and asynchronous communication are both essential tools in a microservice architecture. Neither one is universally better - they solve different problems.

Synchronous communication (HTTP, gRPC) is simple, immediate, and easy to reason about. It is the right choice when users need real-time responses and strong consistency.

Asynchronous communication (RabbitMQ, Kafka, Azure Service Bus, Azure Event Hubs) is resilient, scalable, and decoupled. It is the right choice for background processing, event-driven workflows, and broadcasting events to multiple services.

Most production systems use a hybrid approach - synchronous at the user-facing boundary and asynchronous behind it.

The key decisions come down to:

• Does the caller need a response right now?
• Can this work happen in the background?
• How many services need to react?

Start simple. Use synchronous communication where it's natural.

Introduce asynchronous communication where you need resilience and scalability.

And always design for failure - regardless of which style you choose.

Hope you find this newsletter useful. See you next time.