Event-Driven Architecture

1. What Is It?

Event-driven architecture (EDA) is a system design style where components communicate by producing and consuming events through a durable, asynchronous channel — rather than by calling each other synchronously over RPC or HTTP. An event is an immutable record that something happened in the past (OrderPlaced, PaymentCaptured, UserSignedUp), and the producer doesn't know or care which services consume it.

The problem it solves: in request/response architectures, every new consumer of an action requires the producer to call it — adding latency, coupling, and a new failure mode for the producer. EDA decouples what happened from who reacts. Without it, your checkout service ends up calling inventory, email, analytics, fraud, recommendations, and warehouse — each call a new way for checkout to fail or slow down.

2. How It Works

1. A producer service performs its own business logic and writes an event to a log or broker (Kafka topic, SNS topic, EventBridge bus).
2. The broker durably stores the event and makes it available to any subscribed consumer.
3. Consumers independently read the event, do their own work, and update their own state. They don't acknowledge back to the producer.
4. Each consumer maintains its own progress (offset) and failure handling. A slow consumer doesn't slow down the producer or other consumers.

-+ResetFullscreen

Concrete example. Compare a checkout flow before and after:

• RPC style: Checkout synchronously calls InventoryService.reserve(), EmailService.send(), AnalyticsService.track(). If email is slow, the user waits. If analytics is down, the request fails (or you add try/catch noise everywhere).
• EDA style: Checkout writes one OrderPlaced event to Kafka and returns 201 to the client. Inventory, Email, and Analytics each have their own consumer reading the topic. Each fails or scales independently. Adding a fifth consumer (recommendations) requires zero changes to checkout.

3. What Mid-Senior SWEs Actually Need to Know

• Events are facts, not commands. OrderPlaced (past tense, immutable, public fact) is an event. SendEmail (imperative, addressed to one service) is a command — that's still RPC, just over a queue.
• The contract is the event schema, not an interface. Breaking changes to an event schema break every consumer. Schema registry (Avro/Protobuf) with compatibility rules is how you survive.
• Producer never knows the consumer. This is the point. If your producer needs to know whether a downstream succeeded, you're building request/response on top of a broker — pick the right tool.
• Ordering is per-key, not global. All OrderPlaced events for the same order_id will arrive in order at the consumer if you partition by order_id. Across orders, no guarantee.
• Idempotency in consumers is mandatory. At-least-once delivery is the default; consumers must handle the same event twice (dedupe by event ID, or use idempotent writes).
• Common misunderstanding: "EDA gives me real-time." Not directly — it gives you decoupling. The latency win comes from removing synchronous chains; the latency floor is the broker's end-to-end propagation, typically tens to hundreds of ms.
• Failure mode shift. In RPC, failures are synchronous and visible. In EDA, failures are async — a stuck consumer produces a growing lag. You must monitor consumer lag the way you monitor RPC latency.

4. Tradeoffs & Decisions

When to choose EDA:

• You need to add new reactions to a business action without modifying the originator.
• Multiple downstream systems need the same facts (analytics + ML + audit).
• Producer and consumer have different scaling, latency, or availability characteristics.
• You want services to fail independently.

When NOT to choose EDA:

• You need an immediate result from a single downstream (RPC is correct).
• You need a transactional read-your-write — the consumer is eventually consistent.
• The team has no operational maturity for async failure modes (lag, replays, dead-letter queues).

Key tradeoff: decoupling vs traceability. Tracing a user action across an EDA system requires distributed tracing, structured logging with correlation IDs, and tooling discipline. In RPC, the call stack is the trace.

5. Interview & System Design Cheat Sheet

• EDA is fundamentally about inversion of dependency: producer publishes facts, consumers subscribe — producer has no dependency on consumers.
• Use past-tense, business-meaningful event names. OrderPlaced, not OrderPlacedHandler or ProcessOrder.
• The event log is the system of record for what happened — that's why log-based brokers (Kafka) dominate over fire-and-forget queues for serious EDA.
• Consumers must be idempotent because the contract is at-least-once. Exactly-once is achievable only at specific boundaries (Kafka transactions, idempotent sinks).
• The cost of EDA is eventual consistency, harder debugging, and the need for a schema-registry / observability stack. Pay it when the decoupling is worth it; skip it for simple two-service interactions.

Common follow-ups:

• "How do you handle a consumer that needs to call back the producer with a result?" — That's request/reply; do it with a correlation ID and a response topic, or use RPC directly. Don't fake RPC over events.
• "What's the difference between event-driven and event-sourced?" — EDA is about communication between services. Event sourcing is a storage pattern where the events are the source of truth for one service's state. They compose well but solve different problems.
• "How do you handle schema evolution?" — Backward-compatible additions only; deprecate fields before deleting; enforce via schema registry compatibility rules; version the topic if a breaking change is unavoidable.

If asked to design X, anchor on this: Identify which interactions are "tell me something happened" (events) vs "do this now and tell me the result" (commands/RPC). Events go on a broker; commands stay synchronous. Mixing them is where most EDA designs go wrong.