EVENT STREAM · AT-LEAST-ONCE DELIVERY
Agent events: deduplicate a redelivered effect
Deliver eight agent events with a lost acknowledgement or a consumer crash, and see which dedupe key and window keep exactly one ledger effect per event.
Your experiment
The producer emits E1 to E8 and each event should change a booking ledger exactly once. E2 and E7 are two different 40-credit charges with the same payload text. Start with the lost acknowledgement and no dedupe, then add an event-ID key, shrink the window below the redelivery gap, and try the payload key and the crash fault.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Deterministic teaching model, not an ADK runner or a message broker. Each delivery is processed in order by one consumer; the dedupe store is updated in the same step as the ledger effect; a lost acknowledgement causes exactly one redelivery; a crash happens at one fixed point. Real brokers add partitions, concurrent consumers, visibility timeouts and store durability concerns. All events and charges are fictional.
One lost acknowledgement, one extra charge
The producer emits eight events, E1 to E8, and each one should change the booking ledger exactly once. With the opening settings the acknowledgement for E4 is lost, so the broker redelivers E4 after three later deliveries (E5, E6 and E7). The consumer has No dedupe, applies the redelivery and charges 25 credits twice. The trace shows nine deliveries, the ledger lane shows E4 x2 and the result is DUPLICATE EFFECT. At-least-once delivery is the normal contract for event streams, so the consumer has to make the second delivery harmless.
Deduplicate on the event ID, for long enough
Set Consumer dedupe key to Event ID. The consumer remembers the IDs it has applied and suppresses the redelivered E4: EXACTLY ONE EFFECT PER EVENT. Now lower Applied keys the consumer remembers. The redelivery arrives three applies after E4, so a window of 3 has already forgotten E4 and the duplicate returns, while a window of 4 still catches it. Applied keys the consumer remembers matters only when a dedupe key is chosen. The retention of a dedupe store must exceed the longest redelivery delay, not the typical one.
A payload key confuses different events
Choose Payload text with the full window of 8. The redelivery is caught, but E7 is a second, legitimate 40-credit charge whose text matches E2, so it is dropped: DISTINCT EVENT DROPPED with one missing effect. With a window of 4 the payload key happens to give the right answer because E2 has been forgotten by the time E7 arrives; with 3 it lets the E4 duplicate through again. Content is not identity; two events can look the same and still both need to happen.
Crash before or after the acknowledgement
Set Delivery fault to Consumer crashes while handling E5. With Apply effect, then acknowledge the consumer applies E5, crashes before acknowledging, and the broker redelivers E5 at once: a duplicate without dedupe, and exactly once with an Event ID key at any window, even 1. Consumer order (crash fault) applies only to this crash case. Switch it to Acknowledge, then apply effect and the broker considers E5 done before the effect exists: EFFECT LOST, and no dedupe key can recover it. Apply first and deduplicate, rather than acknowledging early.
Inspecting the run and its limits
Play, Next event, Restart, Speed and Inspection time walk through the setup, every delivery and the ledger check across sixty seconds; the table lists each delivery, the consumer decision and the running effect count. Later deliveries before E4 is redelivered moves the redelivery between one and four positions later. The model has one consumer and one partition, and the dedupe record is written atomically with the effect; real systems must make that write durable and transactional with the side effect, which this page assumes rather than shows.