System Design Event Driven Architecture

Event driven architecture connects services through events. An event is a record that says something happened, such as "Order Placed" or "Payment Received". Services announce events and other services react to them. Nobody waits for a direct reply.

Request-Response vs Events

In the request-response style, one service calls another and waits for the answer. A chain of waiting services makes the whole path slow and fragile. One broken link stops everything.

In the event style, a service publishes an event and moves on. Interested services pick up the event whenever they are ready.

Layman example

A school principal makes an announcement on the loudspeaker. The sports teacher, the librarian, and the canteen staff each hear it and act on their own. The principal never calls each person one by one.

Core Parts

• Event: a small message that describes a fact, such as the order number and the time.
• Producer: the service that creates and sends the event.
• Event broker: the middle layer that receives, stores, and delivers events. Kafka, RabbitMQ, and cloud messaging services play this role.
• Consumer: a service that listens for events and reacts.

Architecture Diagram

 [Order Service]
        |
        |  publishes "OrderPlaced"
        v
 +----------------+
 |  EVENT BROKER  |
 +----------------+
  |       |       |
  v       v       v
[Payment] [Stock] [Email]
 charges   reduces  sends
 the card  items    receipt

The order service knows nothing about payment, stock, or email. A new consumer, such as a loyalty points service, joins the system without any change to the order service.

Common Event Patterns

Publish and Subscribe

One event reaches many subscribers. Each subscriber gets its own copy and works independently.

Event Streaming

The broker keeps events in an ordered log for days or weeks. New consumers replay old events to catch up, and analytics tools read the same stream.

Event Sourcing

The system stores every change as an event instead of storing only the latest state. A bank account holds a list of deposits and withdrawals. Adding them up gives the current balance. The full history stays available for audits.

CQRS

Command Query Responsibility Segregation separates writing from reading. Events from the write side update fast read-only views for queries.

Benefits

• Loose coupling: teams change services without breaking each other.
• Scalability: consumers scale up or down by their own workload.
• Resilience: the broker holds events while a consumer is offline, and the consumer catches up later.
• Flexibility: new features subscribe to existing events.

Challenges

Duplicate Events

Brokers sometimes deliver the same event twice. Consumers must handle repeats safely. An idempotent consumer produces the same result even when it processes one event two times. A payment service checks the order ID before it charges a card.

Event Order

Events can arrive out of order. Brokers often guarantee order only inside one partition. Designers use a key, such as the customer ID, to keep related events together.

Hard Debugging

No single call chain shows the full story. Teams add correlation IDs to events and rely on tracing tools to follow a business action across services.

Eventual Consistency

Consumers update at slightly different times. The stock count may lag behind the order for a moment. Users and designers must accept short delays.

When to Use It

Design Tips

• Name events in the past tense, such as OrderShipped.
• Keep events small and include only the facts consumers need.
• Version event formats so old consumers keep working.
• Send failed events to a dead letter queue for later inspection.
• Monitor consumer lag to catch slow consumers early.