Communication Patterns
Master the patterns and protocols that enable services to communicate effectively in distributed systems. Learn when to use synchronous vs asynchronous communication and how to handle failures gracefully.
Types of Service Communication
How services communicate fundamentally shapes your system's performance, reliability, and complexity. Each approach has distinct trade-offs that affect user experience and operational requirements.
Communication Design Principles
- • Loose Coupling: Services should depend on contracts, not implementations
- • Fault Tolerance: Assume network calls will fail and design accordingly
- • Performance: Choose patterns that match your latency and throughput requirements
- • Consistency: Decide between strong consistency and availability based on business needs
Synchronous (Request-Response)
Direct communication where sender waits for response
- • User-facing APIs
- • Real-time queries
- • Simple CRUD operations
- • Blocking calls
- • Cascading failures
- • Tight coupling
Asynchronous (Fire-and-Forget)
Sender doesn't wait for response, continues processing
- • Background processing
- • Event notifications
- • Data pipeline
- • Message ordering
- • Duplicate handling
- • Dead letter queues
Event-Driven Architecture
Services communicate through domain events and state changes
- • Microservices coordination
- • Real-time analytics
- • CQRS/Event Sourcing
- • Event schema evolution
- • Eventual consistency
- • Complex debugging
Performance Characteristics
Different communication patterns have vastly different performance characteristics. Choose based on your system's latency, throughput, and reliability requirements.
Synchronous (HTTP/gRPC)
Asynchronous (Queues)
Event-Driven
Common Messaging Patterns
These patterns provide proven solutions for common distributed system communication challenges. Each pattern addresses specific reliability, scalability, and consistency requirements.
Point-to-Point (Queue)
One producer sends to one consumer via queue
- • Simple model
- • Load balancing
- • Guaranteed processing
- • Single consumer bottleneck
- • No broadcast capability
Publish-Subscribe (Topic)
One producer sends to multiple interested consumers
- • Multiple consumers
- • Loose coupling
- • Easy to add new consumers
- • Potential duplicate delivery
- • Consumer management complexity
Request-Reply with Correlation
Asynchronous request with response correlation ID
- • Non-blocking
- • Timeout handling
- • Parallel processing
- • Correlation complexity
- • Response handling
- • State management
Saga Pattern
Coordinate long-running transactions across services
- • Distributed transactions
- • Failure recovery
- • Business process modeling
- • Complex implementation
- • Compensation logic
- • Debugging difficulty
Real-World Implementations
Learn how major tech companies implement communication patterns at scale. These examples show practical applications and lessons learned from production systems.
Netflix
1M+ events/secondVideo upload triggers encoding, thumbnail generation, metadata extraction, CDN distribution
- • Event schemas matter
- • Dead letter queues essential
- • Monitor everything
Uber
100K+ rides/minuteReal-time location updates (async) + ride matching logic (sync) + payment processing (async)
- • Latency vs consistency trade-offs
- • Circuit breakers prevent cascades
- • Idempotency is crucial
Slack
10M+ concurrent connectionsReal-time message delivery with guaranteed ordering and offline support
- • Connection management is hard
- • Message ordering matters
- • Graceful degradation
Shopify
1M+ orders/dayInventory check → Payment → Fulfillment → Shipping with full audit trail
- • Event sourcing enables replay
- • Compensation is complex
- • Testing sagas is critical
Error Handling & Resilience Patterns
Failure Handling
Circuit Breaker
Prevent cascading failures by failing fast when downstream services are unhealthy
Retry with Backoff
Automatically retry failed requests with increasing delays
Dead Letter Queue
Route messages that can't be processed to special queue for investigation
Data Consistency
Idempotency
Ensure operations can be safely retried without side effects
Outbox Pattern
Ensure database updates and message publishing happen atomically
Eventual Consistency
Accept temporary inconsistency for better availability and performance
Communication Technology Comparison
| Technology | Type | Latency | Throughput | Ordering | Best For |
|---|---|---|---|---|---|
| HTTP/REST | Sync | Medium | Medium | N/A | User-facing APIs, CRUD operations |
| gRPC | Sync | Low | High | N/A | Service-to-service, high performance |
| Apache Kafka | Async | Low | Very High | Strong | Event streaming, real-time analytics |
| RabbitMQ | Async | Medium | Medium | Optional | Task queues, workflow orchestration |
| WebSocket | Async | Very Low | Medium | Strong | Real-time updates, gaming, chat |
Communication Pattern Decision Guide
Use Synchronous When:
- ☐ User is waiting for response (interactive)
- ☐ Strong consistency required
- ☐ Simple request-response pattern
- ☐ Error handling needs to be immediate
- ☐ Low latency is critical
Use Asynchronous When:
- ☐ Background processing acceptable
- ☐ High throughput required
- ☐ Loose coupling preferred
- ☐ Fault tolerance is critical
- ☐ Multiple consumers needed
🎯 Communication Pattern Successes and Failures
Learn from real-world communication pattern decisions and their impact on system reliability
Scenarios
Context
How WhatsApp ensures message delivery across 2+ billion users
Metrics
Outcome
Asynchronous message queuing with persistent storage enables reliable delivery even when recipients are offline. Messages stored until successful delivery.
Key Lessons
- •Store-and-forward queuing essential for mobile messaging reliability
- •Message acknowledgments at multiple levels (sent, delivered, read)
- •Offline-first design: assume network is unreliable
- •End-to-end encryption must work with asynchronous delivery patterns