A consumer that survives being replayed
A consumer reads payment events and credits an account. It is currently at-least-once, so a rebalance during processing replays the batch and credits twice.
Make it safe to replay. You may not switch the broker to exactly-once.
Example
- input
event PAY-1001 delivered twiceoutputbalance credited onceThe second delivery is recognised and does nothing, and the offset still advances.
Constraints
- Offsets are committed manually, after the work.
- The dedupe store and the balance must move together — two systems means a window where one is written and the other is not.
Hints
Hint 1
Auto-commit is what makes a replay silently skip work. It is also what makes it repeat work.
Hint 2
A unique constraint on the event id turns the second insert into a caught exception rather than a second credit.
Hint 3
The same transaction, or the outbox pattern. Not two transactions.
Stuck? The lesson behind this problem: 📨 Kafka with Spring
java
Tab indents · Escape first to tab out
Test cases
These are the specification. Run tests checks your answer against them.
| Case | Input | Expected |
|---|---|---|
| single delivery | PAY-1001 ×1 | credited once |
| duplicate delivery | PAY-1001 ×2 | credited once |
| a failure does not commit the offset | credit throws | offset unchanged, event redelivered |