An event handler might receive the same event twice. How should it be built?
Why B is the answer
Idempotent, so that repeats do no harm
At-least-once delivery means duplicates can happen, so processing must be safe to repeat.
In detail
- Delivery can repeat.
- An idempotent handler means a repeat does no harm.
- Store processed IDs for as long as repeats can arrive.
Use case
An illustrative scenario, not a real incident.
An event arrives twice, and a customer could be charged twice. Checking the event ID first makes the repeat harmless.
See it in different ways
stateDiagram-v2 [*] --> Queued Queued --> Processing Processing --> Completed: success Processing --> Queued: failure, retry Processing --> DeadLetter: maximum delivery count reached Completed --> [*]
flowchart TD
Q{"Have you seen this event ID?"}
Q -->|"No"| A0["Process it"]
Q -->|"Yes"| A1["Skip it"]Key point: Idempotent handlers survive repeats.
Why the other options are wrong
- A. With a second handler that runs at the same time
- A second handler adds more duplicates.
- C. With a longer timeout on each request
- A timeout does not stop duplicates.
- D. With the assumption that duplicates never occur
- Duplicates do happen.