When should I use synchronous REST vs asynchronous messaging for microservice communication?

Use synchronous REST (or gRPC) when: you need an immediate response to return to the caller (user wants to know if their order was accepted right now), the operation is simple and fast, or the downstream service has high availability. Use asynchronous messaging when: the operation can be processed in the background (sending a welcome email after signup), you need to fan-out to multiple consumers (order placed → notify 3 services simultaneously), you need to handle traffic spikes gracefully (queue absorbs bursts), or the downstream service may be temporarily unavailable and you need durable delivery. The guiding principle: synchronous calls create temporal coupling — both services must be available at the same time. Async messaging removes that coupling at the cost of eventual consistency.

What is the difference between Kafka and RabbitMQ and when should I use each?

Kafka is a distributed commit log optimized for high-throughput event streaming and fan-out. Messages are retained for days or weeks and can be replayed by new consumers. Multiple independent consumer groups can read the same topic without interfering. Best for: event sourcing, audit logs, analytics pipelines, data lake ingestion, fan-out to many services. RabbitMQ is a traditional message broker built around queues, routing, and competing consumers. Messages are deleted after successful acknowledgment. Best for: task queues where each message is processed exactly once by one worker (email sending, image resizing), complex routing logic (exchanges + binding keys), and when message ordering within a queue is important. If you are just starting and need a task queue, RabbitMQ or AWS SQS is simpler. If you need event replay, fan-out to multiple services, or very high throughput, use Kafka.

What is the saga pattern and why is it needed for microservices?

A saga is a sequence of local database transactions across multiple services, where each step publishes an event or sends a message to trigger the next step. Sagas are needed because distributed transactions spanning multiple databases cannot use a single ACID transaction — there is no two-phase commit across microservices. The saga pattern handles this by defining compensating transactions that undo the effect of a step if a later step fails. Two styles: choreography (services react to each other's events with no central coordinator — simpler but harder to track) and orchestration (a central saga orchestrator service coordinates each step — easier to monitor and debug but adds a dependency). For financial workflows (order placement, payment processing), always implement sagas with proper compensating transactions and idempotent operations.

What is a dead letter queue and why is it critical in production?

A dead letter queue (DLQ) is a queue where messages are sent after they have failed processing a configured number of times (maxReceiveCount). Without a DLQ, failed messages either get stuck reprocessing in a loop (blocking healthy messages behind them), or are silently deleted and lost. With a DLQ: failed messages are preserved for inspection, your main queue keeps flowing, you can replay messages after fixing the bug, and you can alert on DLQ depth to detect processing failures. DLQ monitoring is a critical production metric — a non-empty DLQ means something is broken. Configure DLQs for every queue in production and set an alarm when DLQ depth exceeds 0.

How does a circuit breaker prevent cascade failures in microservices?

Without a circuit breaker, when Service B is slow (taking 10 seconds to respond), all callers of Service B hold threads open for 10 seconds waiting. If Service A calls Service B 100 times per second, within 10 seconds it has 1,000 stuck threads — exhausting its thread pool and crashing Service A too. The circuit breaker solves this by tracking the failure rate of calls to Service B. When failures exceed a threshold (e.g., 50% in a 10-second window), the circuit "opens" — subsequent calls immediately return a fallback response without calling Service B at all. After a cooldown period (e.g., 30 seconds), the circuit enters "half-open" state and allows one test call. If it succeeds, the circuit closes. This limits the blast radius of a failing downstream service to callers who depend on it directly.

Engineering·12 min read·June 21, 2026

🔧 Microservices Communication Patterns

A complete guide to microservices communication: synchronous patterns (REST, gRPC), asynchronous messaging (Kafka, RabbitMQ, SQS), event sourcing with CQRS, the saga pattern for distributed transactions, service discovery, and circuit breakers with Resilience4j.

📖Full-Stack SaaS with Next.js, Supabase & Groq AI (Full Access)

View →

The Core Problem: Services Need to Talk to Each Other

In a monolith, function calls are in-process, near-instant, and never fail due to network issues. In a microservices architecture, every cross-service interaction is a network call — subject to latency, packet loss, service downtime, and partial failures. Choosing the right communication pattern for each interaction type is one of the most consequential microservices architecture decisions. The wrong choice creates tight coupling, cascading failures, and hard-to-debug distributed transactions.

Topics covered

microservices communication patternssynchronous vs asynchronous microservicesgRPC microservicesKafka event streamingRabbitMQ message queueevent sourcing CQRSsaga pattern distributed transactionsservice discovery consulcircuit breaker Resilience4jmicroservices REST APISQS AWS queuechoreography vs orchestration sagadead letter queue DLQat-least-once delivery Kafkamicroservices architecture guidedistributed systems patternsAPI gateway microservicesservice mesh Istio Linkerd