Last updated: August 2026
Event-Driven Architecture
Event-driven architecture is an architectural pattern where components communicate asynchronously through events, decoupling producers (that emit events) from consumers (that respond to them), enabling loosely coupled, scalable systems.
How it works
In event-driven architecture, services emit events when something significant happens (e.g., "Order Placed", "Payment Received"). These events are published to a message broker (like Apache Kafka, RabbitMQ, or AWS SNS/SQS). Other services subscribe to events they care about and react accordingly, without needing to know about each other directly.
For example, when an order is placed, the Order Service emits an "OrderPlaced" event. The Billing Service subscribes to this event and generates an invoice. The Inventory Service subscribes and decrements stock. The Notification Service subscribes and sends a confirmation email. No service calls another directly.
Key benefits
- Decoupling — services don't need to know about each other, only about events
- Scalability — adding new event consumers doesn't require modifying existing services
- Resilience — if one consumer is slow, it doesn't block other consumers
- Real-time responsiveness — asynchronous event processing enables low-latency reactions
- Audit trail — events create a complete record of all state changes in the system
Event-driven vs. Request-Response
| Aspect | Event-Driven | Request-Response |
|---|---|---|
| Coupling | Loose (asynchronous) | Tight (synchronous calls) |
| Latency | Eventual consistency | Immediate response required |
| Scalability | Easier to scale independently | Scaling is linked |
| Complexity | Higher (async, distributed) | Lower (familiar, simpler) |
Working with Code Ninety
See Code Ninety's enterprise delivery case studies. See the enterprise ERP modernization case study for a completed migration of this type.