Event-Driven Architecture

Overview

Overview Event-driven architecture (EDA) is a design paradigm where services communicate through events — records of things that have happened. Instead of Service A calling Service B directly (synchronous coupling), Service A publishes an event ("OrderPlaced"), and any interested services react to it independently.

This decoupling is transformative for microservices. Services do not need to know about each other; they only need to know about events. Adding a new feature (e.g., sending order confirmation emails) means deploying a new consumer that listens for OrderPlaced events — without modifying the Order Service.

At its most ambitious, event sourcing stores every state change as an immutable event, making the event log the authoritative source of truth rather than the current state in a database. This powers systems at LinkedIn (Kafka processes trillions of events), Netflix (real-time recommendations), and financial systems (audit trails). Interviewers love EDA because it touches on eventual consistency, distributed systems, and architectural trade-offs.

Key concepts

• Domain events and event types
• Event sourcing (storing events as source of truth)
• Event streaming (Kafka, Kinesis)
• Pub/sub messaging patterns
• Event store design
• Event schema evolution
• Exactly-once vs at-least-once delivery
• Dead letter queues and poison messages

Interview questions

• What is event sourcing and how does it differ from traditional state storage?
• How do you handle event schema evolution without breaking consumers?
• Compare at-least-once, at-most-once, and exactly-once delivery semantics.
• How do you design an event store and handle event replay?

More Microservices topics

• API Gateway Pattern
• Backend for Frontend (BFF)
• Bulkhead Pattern
• Circuit Breaker Pattern
• Configuration Externalization
• CQRS
• Retry Pattern
• Saga Pattern
• Service Discovery
• Sidecar Pattern
• Strangler Fig Pattern