Event-Driven Notification Platform · View 10 of 26 · 3 · Data

Event Topology and Priority Tiers

Which topics exist, why three tiers, how ordering is guaranteed, and how a stuck message gets out.

Editable source SVG draw.io All views

The tiering decision

Three tiers end to end — transactional, operational, bulk — with separate topics, consumer groups and Flink slot groups
Without this, one campaign of 20 M sends delays a one-time passcode; priority inside a single topic cannot fix head-of-line blocking
The cost is roughly triple the topic and consumer-group count, which is operational overhead, not runtime cost

Ordering

Partition key is tenant_id:entity_id, giving per-entity ordering with no global ordering requirement
OrderCreated, OrderPaid, OrderShipped, OrderDelivered stay ordered for one order id
Ordering across entities, tenants or tiers is explicitly not guaranteed and is documented per event type

Recovery

Replay reads the Iceberg archive rather than rewinding a live consumer group, so replay never disturbs live traffic
Replayed events land on a separate topic with a separate consumer group; deduplication suppresses what was already sent
DLQ retention is 30 days, long enough to survive a holiday weekend plus a fix

◀ Data Flow All views Data Architecture and Retention ▶