Duplicate and Late Events

1. Core problem: redelivery is not the same as repeated business execution

In event-driven systems, a message may be delivered again, arrive late, or appear out of order relative to another event. The central mistake is to treat arrival as proof of exactly-once business execution. This lesson separates transport delivery, ordering, and side effects so each boundary can be tested independently.

2. Keep eight evidence dimensions separate

For each event, record delivery attempt, duplicate detection, late classification, ordering policy, idempotency identity, side-effect evidence, replay result, and residual risk. Compressing those dimensions into one status hides whether the anomaly came from redelivery, a genuinely stale event, or repeated execution of the same business operation.

3. At-least-once means redelivery can occur

Kafka documentation distinguishes at-most-once, at-least-once, and exactly-once semantics, and separates publishing guarantees from consuming/output guarantees. [KAFKA-DESIGN] In an at-least-once path, seeing an event again can therefore be valid transport behavior; the consumer must define what redelivery means for state and side effects.

4. Producer idempotence has a bounded scope

Kafka's enable.idempotence is designed to prevent duplicate log entries caused by producer retries when its documented conditions hold. [KAFKA-PRODUCER] That statement is about the producer/log boundary. It does not prove that a consumer writing to a database, email system, payment endpoint, or another service performs the external side effect exactly once.

5. Do not confuse event identity with business-operation identity

A simple duplicate may repeat the same event_id. The harder failure appears when a new event ID carries the same business operation, such as order-42:charge. Deduplicating only by event ID misses this case. Side-effect protection needs an identity aligned with business meaning.

6. Consumer idempotency must protect the actual effect

A processed marker helps only when its boundary matches the effect you are protecting. If it is written before the effect, the effect can be lost; if it is written after an effect in independent storage, a crash can create ambiguity. This lesson therefore records side-effect evidence separately instead of treating the marker as a universal oracle.

7. Late is not the same as duplicate

An event may arrive for the first time while its sequence or event time is older than already-applied state; that event is late/stale but not a duplicate. Conversely, a duplicate can also be late relative to current state. The record marks both axes independently so the policy does not collapse them into one label.

8. Ordering is rarely global

Ordering usually belongs to a key, partition, or other bounded scope. If sequence 7 arrives before 6, it is not automatically a stale update that should be discarded; the correct policy may be buffering, gap detection, or reconciliation. Out-of-order and stale-late are related but distinct decisions.

9. Make the stale-update policy explicit

When an event is older than the latest valid state, the consumer needs an explicit rule: reject, merge, compensate, or reconcile. Blindly applying an older state-change event can roll current state backward. In the fixture, a stale update is prevented from producing a new side effect unless policy evidence permits it.

10. Dedupe retention is part of correctness

If a dedupe record expires before the realistic retry/replay window, an old event can later look new. Infinite retention also has cost and lifecycle consequences. The evidence record must state the bounded scope and residual risk; this lesson does not prescribe one universal retention duration.

11. Replay must preserve the same invariants

Replay can support recovery, but a replay path that bypasses dedupe or ordering policy can recreate the failure. Stronger evidence is that replay passes through the same duplicate gate and order policy and produces no unintended new side effect.

12. Counterexample: new event ID, repeated business key

One fixture uses two distinct event IDs for the same business operation. A learner who checks only event IDs sees no transport duplicate and may execute the side effect again. The correct diagnosis is that transport uniqueness and business idempotency are different contracts.

13. Transfer: two consumers and a changed ordering key

The transfer fixture changes the ordering key and enables two consumers. A single consumer's local state is no longer sufficient for deduplication. The learner must identify shared identity/state that spans the concurrency boundary and rebuild late/order handling without claiming global exactly-once execution.

14. Lab: eight fixtures and 64 assertions

The lab is fully local, deterministic, and synthetic. Eight cases cover a healthy baseline, same-event-ID duplicate, stale late event, new-event-ID business duplicate, out-of-order gap, producer retry deduplicated at the log, incomplete evidence, and two-consumer transfer. The hidden evaluator checks eight outputs per case for 64 assertions total.

15. Exit checklist and claim boundary

To exit, independently classify duplicate and late state; separate event identity from business idempotency; bound producer idempotence to its documented scope; make ordering policy explicit; inspect side-effect and replay evidence; preserve OPEN when evidence is insufficient; and rebuild the transfer from changed evidence. The synthetic fixture does not prove global exactly-once behavior in a production system.