Event-driven vs request-driven in Microservices - Architecture Trade-offs

Problem Statement

When services communicate only by direct requests, a slow or failing service can block the entire flow, causing delays and failures. This tight coupling makes the system fragile and hard to scale under varying loads.

Solution

Event-driven architecture decouples services by using events to signal changes or actions asynchronously. Instead of waiting for a response, services emit events that others listen to and react upon, allowing independent scaling and failure isolation.

Architecture

Service A

→Event Broker

↓

Service B

Service B

↓

Client

→Service A

The diagram shows two communication styles: event-driven where Service A emits events to an event broker that Service B consumes asynchronously, and request-driven where a client sends a request to Service A and waits synchronously for a response.

Trade-offs

✓ Pros

→

Event-driven allows services to operate independently, improving fault tolerance.

→

It supports asynchronous processing, which can improve system throughput and responsiveness.

→

Request-driven is simpler to implement and easier to reason about for synchronous workflows.

→

Request-driven provides immediate feedback to clients, useful for real-time interactions.

✗ Cons

→

Event-driven systems can be harder to debug due to asynchronous flows and eventual consistency.

→

They require infrastructure like message brokers and careful event schema management.

→

Request-driven systems can become bottlenecks if services are slow or fail, impacting user experience.

→

Tight coupling in request-driven can reduce system resilience and scalability.

Use event-driven when services need loose coupling, asynchronous processing, or must handle high throughput and variable loads. Use request-driven for simple, synchronous interactions requiring immediate responses, especially under low to moderate load.

Avoid event-driven if your system requires strict immediate consistency or if debugging complexity is unacceptable. Avoid request-driven when services are highly interdependent or when scaling to high concurrency and fault tolerance is critical.

Real World Examples

Netflix

Uses event-driven architecture to decouple microservices for streaming and recommendations, allowing independent scaling and resilience.

Uber

Employs request-driven APIs for synchronous ride requests but uses event-driven patterns for asynchronous updates like trip status and notifications.

Amazon

Combines request-driven APIs for order placement with event-driven workflows for inventory updates and shipment processing.

Code Example

The before code shows a synchronous request where ServiceA calls ServiceB and waits for the result. The after code uses an event broker where ServiceA publishes an event and ServiceB subscribes to handle it asynchronously, decoupling the services.

Microservices

### Before: Request-driven (synchronous call)
class ServiceA:
    def process(self, data):
        result = ServiceB().handle(data)
        return result

class ServiceB:
    def handle(self, data):
        return f"Processed {data}"

# Usage
service_a = ServiceA()
response = service_a.process('input')
print(response)


### After: Event-driven (asynchronous event emission)
import queue

class EventBroker:
    def __init__(self):
        self.subscribers = []
        self.events = queue.Queue()

    def subscribe(self, handler):
        self.subscribers.append(handler)

    def publish(self, event):
        self.events.put(event)

    def dispatch(self):
        while not self.events.empty():
            event = self.events.get()
            for subscriber in self.subscribers:
                subscriber(event)

class ServiceA:
    def __init__(self, broker):
        self.broker = broker

    def process(self, data):
        self.broker.publish({'type': 'process', 'data': data})

class ServiceB:
    def __call__(self, event):
        if event['type'] == 'process':
            print(f"Processed {event['data']}")

# Setup
broker = EventBroker()
service_b = ServiceB()
broker.subscribe(service_b)
service_a = ServiceA(broker)

# Usage
service_a.process('input')
broker.dispatch()

Alternatives

Synchronous request-response

Direct calls with immediate responses, tightly coupling services.

Use when: When operations require immediate results and system scale is manageable.

Batch processing

Processes data in large groups at scheduled times instead of real-time events.

Use when: When real-time processing is not required and throughput optimization is prioritized.

Summary

Request-driven architecture uses direct synchronous calls, suitable for immediate responses but can cause tight coupling and bottlenecks.

Event-driven architecture decouples services with asynchronous events, improving scalability and fault tolerance but increasing complexity.

Choosing between them depends on system requirements for consistency, latency, scalability, and complexity.