Asked about Timeouts, retries and exactly-once, in practice
How do you make a payment operation safe to retry?
An answer that works
Use an idempotency key generated by the client per payment attempt. The server stores the key and the outcome atomically with the charge, and returns the stored outcome for a repeated key. Combined with timeouts and backoff, retries are then harmless.
Then they push further
Can a message queue give you exactly-once processing?
Not end to end. Delivery is at least once in practice because acknowledgements can be lost. Some systems offer exactly-once within their own boundaries, but side effects outside them still need idempotent handling.
How do you save to the database and publish an event reliably?
The outbox pattern: write the event in the same transaction as the data change, and publish from the outbox table in a separate process, accepting possible duplicates.
What gets marked up
Strong answers combine idempotency keys, at-least-once delivery and the outbox pattern, and reject exactly-once claims.
Reading an answer is not being able to give one. The section that teaches this is Timeouts, retries and exactly-once, in practice, 4 hours of Distributed systems.
Learn this properlyAlso asked about Distributed systems