Request-response vs event-driven in Microservices - When to Use Which

The Big Idea

What if your system could keep working smoothly even when parts slow down or fail?

The Scenario

Imagine a busy restaurant where every customer must wait for the waiter to take their order, deliver food, and bring the bill before the next step can happen. If the waiter is slow or busy, everyone waits longer.

The Problem

Using only request-response communication in microservices is like that waiter system. Services wait for replies before moving on, causing delays and bottlenecks. It's hard to scale and can break if one service is slow or down.

The Solution

Event-driven design lets services send messages (events) without waiting for immediate replies. Like customers placing orders and continuing to chat while the kitchen prepares food, services work independently and react to events when ready, making the system faster and more resilient.

Before vs After

✗ Before

response = serviceA.callServiceB(data)
process(response)

✓ After

serviceA.publishEvent('orderCreated', data)
serviceB.subscribe('orderCreated', handleOrder)

What It Enables

This approach enables systems to handle many tasks at once, recover from failures smoothly, and grow easily without slowing down.

Real Life Example

Online shopping platforms use event-driven systems to update inventory, notify shipping, and send customer alerts independently, so orders flow smoothly even during big sales.

Key Takeaways

Request-response waits for answers, causing delays and tight coupling.

Event-driven lets services work independently by sending and reacting to events.

This leads to faster, scalable, and more reliable systems.