/System Design /Event-Driven Architecture ← All Designs
⚡

Event-Driven Architecture

Services communicate via events — fully decoupled, infinitely scalable

Decoupled Async
🎮 What you can do
  • Pick a scenario (E-Commerce / Signup / Payment)
  • Toggle Inject Failure to crash one subscriber
  • Enable Comparison Mode for sync vs async side by side
👁 What to watch
  • Events fan out to all subscribers simultaneously
  • Failed subscriber routes to the Dead Letter Queue
  • Comparison shows total latency: sequential vs parallel
Scenario
Failure Injection
One subscriber crashes — events go to Dead Letter Queue
View Mode
Side-by-side: sync vs async
Controls
0
Published
0
Delivered
0
In DLQ
0
Active Subs
Open/Closed Principle
Event-driven enables open/closed at system level — add new subscribers without touching publishers. The Order Service doesn't know who listens.
Event Log
Events will appear here...
When to Use
Microservice decoupling, audit trail, CQRS pattern, saga orchestration, real-time notifications, event sourcing, multi-consumer fan-out.
Trade-offs
Eventual consistency — harder to debug end-to-end flows. Need idempotency. DLQ for failed events. Distributed tracing is essential.
Interview Tip
Event-driven enables the open/closed principle at system level — new subscribers attach without touching publishers. Ask about idempotency keys.