Resources · Integration patterns
Event-driven integration
Producers publish events to a broker and consumers process them independently and repeatably.
Integration status: Documented pattern
A documented pattern. The product has no event broker.
Description
Events describe facts ("the order was created"). The broker stores them, consumers read at their own pace and schemas are versioned.
Prerequisites
- A chosen broker and ownership model.
- Agreed event schemas.
- Idempotent consumers.
When to use it
- Many consumers of the same changes.
- Systems need decoupling.
- Load peaks.
When not to use it
- An immediate synchronous answer is needed.
- Few systems and small volumes — REST is simpler.
- The team has no broker experience.
Reference diagram
An illustration of the components and the flow — not a running system.
01Producers
- Applications
- Database changes (CDC)
02Broker
- Topics
- Schema registry
- Retention
03Consumers
- Handlers
- Dead-letter queue
The diagram as a list
| Stage | Components |
|---|---|
| Producers | Applications, Database changes (CDC) |
| Broker | Topics, Schema registry, Retention |
| Consumers | Handlers, Dead-letter queue |
Security controls
- Authentication and per-topic permissions.
- Encryption in transit and at rest.
- No personal data in events without need.
Observability
- Consumer lag.
- Publish rate and errors.
- Tracing across events.
Failure modes
| Failure | Mitigation |
|---|---|
| Incompatible schema change | A schema registry with compatibility checks. |
| Slow consumer | Lag monitoring and scaling. |
| Reprocessing | Idempotency by key. |