Chapter 7: Sync vs Async — RPC, Messaging, Event-Driven
Synchronous Communication
Caller waits for response. Simple but creates coupling and cascading failures.
Synchronous (REST/gRPC):
Client ──request──► Service A ──request──► Service B
Client ◄──response── Service A ◄──response── Service B
Total latency = A_processing + B_processing + 2×network
If B is slow or down → A is slow or fails → Client fails
= Cascading failure
Asynchronous Communication
Caller sends message and doesn't wait. Decouples services.
Asynchronous (Message Queue):
Client ──request──► Service A ──publish──► Queue ──consume──► Service B
Client ◄──"accepted"── Service A (processes later)
Service A responds immediately ("accepted").
Service B processes when ready.
If B is down → messages queue up → B processes when back.
No cascading failure!
When to Use Each
| Pattern | Use When | Examples |
|---|---|---|
| Synchronous | Need immediate response, simple flows | User login, get profile, search |
| Async (queue) | Work can be deferred, need resilience | Send email, process payment, generate report |
| Event-driven | Multiple consumers, loose coupling | Order placed → notify warehouse + billing + analytics |
Messaging Patterns
Point-to-Point (Queue)
// One producer, one consumer. Each message processed once.
Producer ──► [Queue] ──► Consumer
// Use: job processing, task distributionPublish-Subscribe (Topic)
// One producer, many consumers. Each gets a copy.
Producer ──► [Topic] ──► Consumer A (email service)
──► Consumer B (analytics)
──► Consumer C (notification)
// Use: event broadcasting, decoupled microservicesEvent-Driven Architecture
Order Service publishes: "OrderPlaced" event
│
├──► Inventory Service (reserve stock)
├──► Payment Service (charge card)
├──► Notification Service (send confirmation)
└──► Analytics Service (track metrics)
Services don't know about each other!
Adding a new consumer = zero changes to Order Service.
💡 Telecom Parallel
In 5G, the AMF publishes events (UE registered, PDU session created) and other NFs subscribe. The NRF enables this pub/sub discovery. This IS event-driven architecture applied to telecom.
Key Takeaways
- Synchronous: simple, immediate response, but creates coupling
- Asynchronous: resilient, decoupled, but adds complexity (eventual consistency)
- Queue (point-to-point): one consumer processes each message
- Topic (pub/sub): all subscribers get every message
- Event-driven: services react to events, zero coupling between producer/consumers