Exactly-once effects
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
distinguish unavailable exactly-once delivery from designable exactly-once effects.
Planned topics
- Over an unreliable network a sender cannot know whether a message arrived, so it retries; delivery is at-least-once or at-most-once.
- Exactly-once effects: make duplicates harmless with idempotency keys, deduplication tables, and conditional updates.
- Some platform features (for example Kafka transactions) give exactly-once processing inside their own boundary; effects outside, such as charging a card, still need idempotency. Verify the guarantees for your versions.
- Pass an idempotency key to external providers and store the result per key.
Draft outline details
Demonstration
INSERT INTO processed(event_id) ... ON CONFLICT DO NOTHING, with the side effect applied only when the insert succeeds, in the same transaction. Provider call with Idempotency-Key: order-123-attempt-1.
Check your understanding
How do you get exactly-once effects from at-least-once delivery?
Show answer
Make handling idempotent, so repeated deliveries have the same effect as one.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.