Event-Driven Architecture

Event-driven architecture (EDA) is a design pattern where system components communicate by producing and consuming events — records of something that happened — rather than making direct synchronous calls.

What It Really Means

In a traditional request-response architecture, Service A calls Service B and waits for a response. This creates tight coupling: A must know about B, B must be available, and A is blocked until B responds. Event-driven architecture inverts this relationship.

Instead of calling other services directly, a service publishes an event: "OrderPlaced," "PaymentProcessed," "UserRegistered." Interested services subscribe to these events and react independently. The Order Service does not know or care that the Notification Service, Analytics Service, and Inventory Service all consume its OrderPlaced event. It simply publishes the fact and moves on.

This decoupling is both temporal (the producer does not wait for consumers) and spatial (the producer does not know who consumes). Adding a new consumer requires zero changes to the producer. This is the fundamental scaling advantage: teams can build new features by subscribing to existing events without coordinating with the producing team.

EDA is not a wholesale replacement for synchronous communication. It is a complement. Use synchronous calls when you need an immediate response ("Is this credit card valid?"). Use events when the action can happen eventually and the producer should not be blocked ("Send a confirmation email").

How It Works in Practice

Core Components

Events: Immutable records of something that happened. An event has a type, a timestamp, and a payload. Example: {type: "OrderPlaced", timestamp: "2026-04-25T10:30:00Z", payload: {orderId: "abc-123", userId: "user-456", total: 89.99}}

Producers: Services that emit events when something significant happens. The Order Service produces events; it does not know who consumes them.

Consumers: Services that subscribe to events and react. The Notification Service subscribes to OrderPlaced and sends a confirmation email.

Event Broker: Infrastructure that transports events from producers to consumers. Apache Kafka, AWS SNS/SQS, RabbitMQ, or Google Pub/Sub. The broker handles durability, ordering, and delivery guarantees.

Real-World Example: Uber Trip Lifecycle

When a rider requests a trip, Uber's system produces a sequence of events:

1. TripRequested — consumed by the matching service to find a driver
2. DriverAssigned — consumed by the notification service to alert the rider
3. TripStarted — consumed by the pricing service to start the meter
4. LocationUpdated — consumed by the ETA service, the tracking UI, and the safety service
5. TripCompleted — consumed by the billing service, the rating service, and the analytics pipeline

Each consumer reacts independently. If the rating service goes down, the trip still completes and the user is still charged. The rating event is processed when the service recovers.

Event Sourcing

Event sourcing takes EDA further: instead of storing the current state of an entity, you store the sequence of events that led to that state. To get the current state, you replay the events.

A bank account using event sourcing stores: AccountOpened(balance: 0), MoneyDeposited(100), MoneyWithdrawn(30), MoneyDeposited(50). The current balance (120) is derived by replaying these events. This gives you a complete audit trail and the ability to rebuild state at any point in time.

CQRS (Command Query Responsibility Segregation)

CQRS separates the write model (commands) from the read model (queries). Writes go through the event-sourced command side. Events are projected into read-optimized views (denormalized tables, search indexes, caches). This is powerful when read and write patterns differ significantly.

Implementation

Trade-offs

When to Use Event-Driven Architecture

• Multiple services need to react to the same business event
• You need temporal decoupling — producers should not wait for consumers
• The system needs a complete audit trail of what happened
• You want to add new features by subscribing to existing events
• Different parts of the system have different consistency requirements

When NOT to Use EDA

• Simple CRUD applications where synchronous request-response is sufficient
• When you need immediate confirmation of downstream processing
• Small teams where the operational overhead of a message broker is not justified
• When strong consistency across services is required for every operation

Advantages

• Loose coupling — producers and consumers evolve independently
• Scalability — consumers process at their own pace
• Resilience — if a consumer is down, events queue up and are processed on recovery
• Extensibility — add new consumers without changing producers
• Audit trail — events provide a natural log of everything that happened

Disadvantages

• Eventual consistency — you cannot guarantee when a consumer will process an event
• Debugging complexity — tracing a request across async event chains is harder than following a call stack
• Ordering challenges — ensuring events are processed in the correct order requires careful design
• Duplicate handling — consumers must be idempotent because events may be delivered more than once
• Operational complexity — message brokers need monitoring, scaling, and disaster recovery

Common Misconceptions

• "Event-driven means everything is asynchronous" — Most real systems use a mix. User-facing requests that need immediate responses (login, search, checkout) use synchronous calls. Background processing (notifications, analytics, reconciliation) uses events.

• "Events and messages are the same thing" — Events describe something that happened ("OrderPlaced"). Commands tell a service to do something ("SendEmail"). Events are broadcast to all interested consumers; commands are sent to a specific service. The distinction matters for coupling.

• "Event sourcing is required for EDA" — Event sourcing is a specific pattern within EDA. Most event-driven systems use simple pub/sub without event sourcing. Event sourcing adds significant complexity and should be applied selectively.

• "Kafka is required for event-driven architecture" — Kafka is popular but not the only option. RabbitMQ, AWS SQS/SNS, Google Pub/Sub, and Redis Streams all support event-driven patterns. Choose based on ordering guarantees, throughput, and operational requirements.

• "EDA eliminates the need for APIs" — Services still need APIs for synchronous queries and commands. EDA complements APIs; it does not replace them.

How This Appears in Interviews

Event-driven architecture is a key topic in system design interviews:

• "Design a notification system" — discuss event producers (order service, shipping service), the event broker, consumer groups, and delivery guarantees. See our system design interview guide.
• "How do you ensure exactly-once processing?" — discuss idempotency keys, deduplication, and the difference between at-least-once and exactly-once semantics.
• "How do you handle event ordering?" — discuss partition keys in Kafka, sequence numbers, and causal ordering.
• Practice with our event-driven architecture interview questions.

Related Concepts

• Microservices Architecture — The architecture EDA typically supports
• Domain-Driven Design — Events align with domain events in DDD
• Hexagonal Architecture — Ports and adapters for event producers/consumers
• API Gateway Pattern — Handling synchronous external traffic
• Compare: Kafka vs RabbitMQ — Choosing a message broker
• System Design Interview Guide — Comprehensive preparation
• Algoroq Pricing — Practice event-driven design questions