In a traditional request-response system, Service A calls Service B directly. If B is slow or down, A suffers. If you later need Service C to also react to the same event, you modify A. This creates tight coupling that compounds over time. Event-driven architecture (EDA) flips this: instead of telling specific services what to do, you announce what happened and let interested parties react.

The core idea: producers emit events, consumers subscribe to them, and a broker sits in the middle. The producer doesn't know or care who's listening.

A real-world example: An e-commerce order system. Without EDA, your OrderService.placeOrder() method calls the inventory service, the payment service, the email service, and the analytics service — sequentially or with brittle orchestration. With EDA, OrderService publishes an OrderPlaced event. The inventory service reserves stock. The payment service charges the card. The email service sends confirmation. The analytics service logs it. Each subscribes independently. When you add a loyalty points service next quarter, you touch zero existing code — it just subscribes to OrderPlaced.

There are two main flavors:

• Event notification: Lightweight messages that say "something happened" with minimal data (e.g., {event: "OrderPlaced", orderId: "abc123"}). Consumers fetch details they need. Simple but can create chatty callback traffic.
• Event-carried state transfer: Events carry the full payload consumers need. Reduces downstream queries but increases message size and creates data duplication.

Key tradeoffs to understand:

• Eventual consistency: You trade immediate consistency for availability and decoupling. If the email service is down for 30 seconds, the user still gets their confirmation — just slightly later. Not every system can tolerate this.
• Debugging complexity: A request-response call stack is easy to trace. An event that triggers five consumers, two of which emit their own events, creates a tree that's hard to follow without proper correlation IDs and distributed tracing.
• Ordering guarantees: Messages can arrive out of order. Your consumers must be idempotent — processing the same event twice should produce the same result.

Rule of thumb: If more than 3 services need to react to the same action, or if you're modifying a producer every time you add a new downstream concern, you've outgrown direct calls and should consider EDA. But if you have only 2 services with a simple request-response need, an event bus adds complexity for no gain.

Common broker choices include Kafka (high throughput, log-based), RabbitMQ (flexible routing, traditional queue), and cloud-managed options like SQS/SNS or Google Pub/Sub. Pick based on your durability, ordering, and throughput requirements — not hype.