Episode 011 · Kafka ordering lab
Payment succeeded. Checkout confirmed the order. A delayed payment event changes only the separate tracking view—not the payment itself.
Select an icon to explore its responsibility. Then deliver the next event.
Both consumers receive identical notifications. A Kafka offset identifies a record in one topic partition; an order version identifies its business sequence. Recovery is a separate worker step, not a new Kafka record.
The tracking view begins at CREATED v1, behind the order service. A held event means tracking is checking updates; it does not mean checkout or the actual payment failed.
This is an in-memory browser model. Production needs durable waiting events, atomic database checks, and reconciliation with the order service.
Can PAID v2 be processed after SHIPPED v3 even when both events use orderId as their key?