All patterns
Integration
Event-Driven
Services react to facts instead of calling each other directly
Producers publish domain events to a broker; consumers process asynchronously. Improves decoupling and resilience at the cost of eventual consistency and more complex debugging.
Enterprise scalehigh complexity
Architecture diagram
High-level component relationships
Key components
Event producers
Emit immutable facts after state changes
Event broker
Durable log (Kafka, RabbitMQ, SNS/SQS)
Consumers
Idempotent handlers with retry and DLQ
Schema registry
Contract evolution for event payloads
Data flow
- Service commits local transaction, then publishes event
- Broker fans out to interested consumers
- Consumers update projections or trigger side effects
- Failures retry; poison messages go to dead-letter queue
Pros
- Loose coupling — add consumers without changing producers
- Natural audit trail and replay for analytics
- Absorbs traffic spikes via buffering
- Enables event sourcing and CQRS read models
Cons
- Eventual consistency complicates UX (stale reads)
- Ordering, idempotency, and duplicate handling are non-trivial
- End-to-end tracing requires correlation IDs
- Schema changes need versioning discipline
When to use
- Many downstream reactions to one business action
- High throughput pipelines and real-time analytics
- Integrating third-party systems without tight coupling
When to avoid
- Strong immediate consistency is mandatory everywhere
- Simple request/response with one consumer
Real-world examples
- LinkedIn activity pipeline
- E-commerce order fulfillment
- IoT telemetry
Related technologies
Apache KafkaRabbitMQAWS EventBridgeDebezium