## Why Event-Driven? Modern applications demand responsiveness, loose coupling, and the ability to scale independently. Event-driven architecture (EDA) delivers all three. Over the past two years, I've migrated three monolithic services to an event-driven model using **Amazon EventBridge**, **SQS**, and **Lambda**. Here's what I learned. ### The Core Pattern Instead of services calling each other directly, they emit events: ```typescript await eventBridge.putEvents({ Entries: [{ Source: 'orders.service', DetailType: 'OrderPlaced', Detail: JSON.stringify({ orderId, userId, items }) }] }).promise(); ``` Downstream services subscribe to the events they care about. This means: - **No coupling** between producer and consumer - **Independent scaling** — each consumer scales based on its own load - **Resilience** — if a consumer is down, events queue up and replay ### Lessons Learned 1. **Schema registry is essential** — without it, breaking changes cascade silently 2. **Dead letter queues save lives** — always configure DLQs for failed event processing 3. **Idempotency is non-negotiable** — events can be delivered more than once 4. **Observability requires investment** — distributed tracing across event boundaries is harder than HTTP calls ### When NOT to Use EDA Not everything should be async. Request-response patterns are still better for: - User-facing queries that need immediate results - Operations requiring transactional consistency - Simple CRUD with no downstream effects
