Event Streams contracted
Event documentation starts from AsyncAPI and the event taxonomy. This page is the reading guide for developers and operators who need to understand which events exist, where they flow, and how consumers should behave.
Generated event reference direction is tracked in AsyncAPI Rendering Path.
Event Model
Every event uses the shared envelope:
{
"event_id": "uuid",
"event_type": "domain.name",
"occurred_at": "RFC3339",
"version": "1.0",
"correlation_id": "...",
"payload": {}
}
Stream Map
Reader Rules
| Rule | Meaning |
|---|---|
| AsyncAPI first | Event shape changes start in doc/api/asyncapi.draft.yaml or domain fragments |
| Outbox required | Domain mutation and outbox row are committed in one database transaction |
| Correlation required | Events carry correlation IDs for traceability |
| Durable consumers | Consumers should tolerate duplicate delivery and retry |
| DLQ visible | Poison messages need operational review and replay posture |
High-Value Event Families
- Provisioning lifecycle: requested, active, failed, releasing, released, release failed.
- Billing lifecycle: low balance, auto release pending, balance depleted.
- Payments lifecycle: balance credited.
- Future app/runtime events should follow the same envelope and contract-first authoring model.