Failure makes completion ambiguous#
| Model | Possible attempts | Trade-off |
|---|---|---|
| At-most-once | Zero or one | No retry duplicate, but work may be lost |
| At-least-once | One or more | Retries preserve work under assumptions; duplicates possible |
| Exactly-once | Scoped coordinated boundary | Requires explicit supported system and side-effect boundary |
Kafka transactions can coordinate supported Kafka read–process–write workflows. A call from a Kafka consumer to an external payment provider still needs application-level idempotency.
- Claiming acknowledgements eliminate duplicates.
- Saying “exactly once” without naming the boundary.
- Ignoring redelivery after a successful side effect.
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Kafka design and delivery semanticsApache Kafka Documentation
- RabbitMQ reliability guideRabbitMQ Documentation
Reach this point to mark the lesson as read.