Event-driven Architecture
Event-Driven Architecture (EDA) — architectural style, где services communicate через publish/subscribe events, а не direct API calls. Producer emits event → message broker (Kafka, RabbitMQ, AWS SNS) delivers → consumers react. Loose coupling: producer не знает consumers. Use cases: order processing, notifications, analytics pipelines. Contrast: synchronous REST/gRPC.
Ниже: подробности, пример, смежные термины, FAQ.
Подробности
- Event broker: Kafka (streams), RabbitMQ (queues), AWS EventBridge, GCP Pub/Sub
- Schema: JSON/Avro/Protobuf. Schema registry (Confluent) для evolution
- Delivery guarantees: at-least-once (standard), exactly-once (expensive)
- Event sourcing pairing: хранить events как source of truth
- Pitfalls: debug сложнее (distributed flow), eventual consistency
Пример
// 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);
});Смежные термины
Больше по теме
Часто задаваемые вопросы
EDA vs request/response?
EDA — async, decoupled. RR — sync, tight coupling. EDA лучше scale, RR проще debug. Most systems — гибрид (EDA для cross-service, RR внутри service).
Kafka vs RabbitMQ?
Kafka — high-throughput streams, long retention, replay. RabbitMQ — queues с routing rules. Kafka для analytics/logs, RabbitMQ для task queues.
Eventually consistency — как handle?
UI shows optimistic updates + reconciles позже. APIs return pending state. Для banking apps — use saga pattern с compensating actions.