Event-Driven Architecture — The WhatsApp Group of Your Backend

The WhatsApp Group Analogy

Imagine a WhatsApp group called "Office Updates." When the HR posts "Tomorrow is a holiday," everyone in the group sees it — accounts, engineering, marketing. HR doesn't need to message each department individually.

Event-Driven Architecture works the same way. When something happens (an "event"), it's published to a channel. Any service interested in that event can listen and react independently.

Traditional vs Event-Driven

Traditional (Request-Response)

User places order
  → Order Service calls Payment Service (waits)
  → Order Service calls Inventory Service (waits)
  → Order Service calls Email Service (waits)
  → Order Service calls Analytics Service (waits)
Total: 4 sequential calls, slow, tightly coupled

Event-Driven

User places order
  → Order Service publishes event: "ORDER_PLACED"
  → Done! Returns to user immediately.

Meanwhile, independently:
  Payment Service hears "ORDER_PLACED" → processes payment
  Inventory Service hears "ORDER_PLACED" → reserves stock
  Email Service hears "ORDER_PLACED" → sends confirmation
  Analytics Service hears "ORDER_PLACED" → logs data

Order Service doesn't know or care about the other services. It just announces what happened.

Core Concepts

Event

A record of something that happened. Immutable (can't be changed).

{
  "type": "ORDER_PLACED",
  "timestamp": "2026-04-03T10:30:00Z",
  "data": {
    "orderId": "ORD-12345",
    "userId": "USR-789",
    "amount": 1500,
    "items": ["item_1", "item_2"]
  }
}

Producer

The service that creates and publishes events (Order Service).

Consumer

The service that listens for and reacts to events (Payment Service, Email Service).

Event Broker

The middleman that receives events from producers and delivers them to consumers (Kafka, RabbitMQ, AWS SNS/SQS).

Event Sourcing

Instead of storing the current state, store ALL events that led to the current state.

Traditional: Bank account balance = ₹10,000 (just the final number)

Event Sourcing:

Event 1: Account opened with ₹0
Event 2: Deposited ₹15,000
Event 3: Withdrew ₹3,000
Event 4: Deposited ₹5,000
Event 5: Withdrew ₹7,000
Current balance: ₹10,000 (calculated from events)

Why? Complete audit trail. You can replay events to rebuild state. You can ask "what was the balance on March 15?" by replaying events up to that date.

Used by: Banking systems, stock exchanges, Git (every commit is an event).

Real-World Example: Uber

When a ride is completed:

Event: "RIDE_COMPLETED"
  → Payment Service: Charge the rider
  → Driver Service: Update driver earnings
  → Rating Service: Prompt for rating
  → Analytics Service: Log ride data
  → Surge Service: Recalculate demand
  → Notification Service: Send receipt

6 services react independently. If the Rating Service is down, the payment still goes through. Services are completely decoupled.

Benefits

• Loose coupling: Services don't know about each other

• Scalability: Add new consumers without changing producers

• Resilience: One service failing doesn't affect others

• Audit trail: Events provide a complete history

• Real-time: React to things as they happen

Challenges

• Complexity: Harder to debug (events flow through multiple services)

• Eventual consistency: Data isn't immediately consistent across services

• Event ordering: Ensuring events are processed in the right order

• Idempotency: Handling duplicate events (consumer must handle receiving the same event twice)

Key Takeaway

Event-Driven Architecture = "Announce what happened, let others react." It's the backbone of modern distributed systems. In interviews, use it whenever you need services to react to changes without tight coupling. Mention Kafka as the event broker — it's the industry standard.