Application Patterns
Event-Driven Integration
Event-driven integration helps systems decouple, absorb bursts, and react to business changes. It also creates new failure modes if events, ownership, and replay behavior are unclear.
When to use events
Events are a good fit when:
- Producers should not block on consumer availability.
- Multiple consumers need to react to the same business fact.
- Work can happen asynchronously.
- Replay or audit history is valuable.
- Bursts need buffering through queues or streams.
Use request and response APIs when the caller needs an immediate answer or when the operation must be strongly coordinated.
Event contract
Every event should define:
- Event name, schema, and version.
- Producer owner and support path.
- Semantics: what business fact happened?
- Required and optional fields.
- Ordering, retention, and replay expectations.
- Idempotency key or deduplication guidance.
- Data classification and privacy constraints.
Delivery patterns
Reliability practices
- Make consumers idempotent.
- Use bounded retries with backoff.
- Send poison messages to a dead-letter queue.
- Monitor lag, age, error rates, throughput, and replay volume.
- Document replay procedures and downstream impact.
- Keep event schemas backward-compatible where possible.
Watchouts
- Events without clear semantics become integration junk drawers.
- Silent consumer failure can hide business process failure.
- Replays can duplicate side effects without idempotency.
- Retention and deletion requirements must be designed up front.