Event-Driven Architecture
Event-Driven Architecture (EDA) — architectural style where services communicate via publish/subscribe events rather than direct API calls. Producer emits event → message broker (Kafka, RabbitMQ, AWS SNS) delivers → consumers react. Loose coupling: producer doesn't know consumers. Use cases: order processing, notifications, analytics pipelines. Contrast: synchronous REST/gRPC.
Below: details, example, related terms, FAQ.
Details
- Event broker: Kafka (streams), RabbitMQ (queues), AWS EventBridge, GCP Pub/Sub
- Schema: JSON/Avro/Protobuf. Schema registry (Confluent) for evolution
- Delivery guarantees: at-least-once (standard), exactly-once (expensive)
- Event sourcing pairing: store events as source of truth
- Pitfalls: debugging is harder (distributed flow), eventual consistency
Example
// Producer
producer.send('order.placed', {
orderId: 'ord-123',
customerId: 'c-456',
total: 99.99
});
// Consumer (OrderService reads)
consumer.on('order.placed', async (event) => {
await sendEmail(event.customerId);
await updateInventory(event.items);
});Related Terms
Learn more
Frequently Asked Questions
EDA vs request/response?
EDA — async, decoupled. RR — sync, tight coupling. EDA scales better, RR easier to debug. Most systems — hybrid (EDA cross-service, RR inside service).
Kafka vs RabbitMQ?
Kafka — high-throughput streams, long retention, replay. RabbitMQ — queues with routing rules. Kafka for analytics/logs, RabbitMQ for task queues.
Eventual consistency — how to handle?
UI shows optimistic updates + reconciles later. APIs return pending state. For banking — use saga pattern with compensating actions.