Review the prerequisites
Suitable for: Understand the request and response, and retry the write operation for the first time.
- Idempotent
- When the same business operation is requested repeatedly, no additional repeated business effects will be generated; the scope of the guarantee depends on the server implementation and validity period.
- operating identity
- A stable identifier representing the same business intent, which is different from the identifier for each network attempt.
- Checkpoint
- The calculation state saved by the caller does not automatically equal the fact that the external service has occurred.
- Unknown result
- The caller does not get a reliable receipt and cannot assert success or failure.
How does the mechanism work?
- persistence intent
Save the stable operation identity and parameters before initiating the action.
- Submitted by service provider
The service party executes and removes duplication with its own contract.
- Caller Check
Response is lost when querying or retrying along the same identity.
- Update task status
Confirm after obtaining a verifiable receipt. If it cannot be verified, the status will remain unknown.
Foundation · Understand the concepts
Why does a timeout not mean that publication failed?
Objectives of this level: Can explain the response loss window and distinguish the number of attempts from the number of business effects.
Start with a lost receipt
A caller requests report publication. The provider writes the report, but the connection breaks before its receipt arrives. A timeout establishes only that the caller lacks a reliable result. Treating it as no publication and creating a new request can produce a second report.
A progress checkpoint is insufficient
A checkpoint records the caller's saved progress. The provider may already be further ahead. Saving local state does not make two independent systems one transaction. The critical window is after the provider commits and before the caller saves the result.
Identify the same business intent across retries
Reuse a stable business operation identity so the provider can recognize retries. Publishing a genuinely new version is a new operation. Reusing an identity with changed arguments needs an explicit conflict or other contracted behavior; silently mixing new content with an old result is unsafe.
Run experiments and observe counterexamples
Two local SQLite files simulate independent submission and response loss; there is no real remote end, process termination or network failure, and it does not prove end-to-end exactly-once.
Python 3.10+ · Runs by default using only the standard library · Runs on your computer
- Observe the differences between the caller's prepared and the server's submitted
- Get the original receipt along the same operation identity
- Use the same identity to change content and verify conflicts
python3 idempotency_recovery.pyView the entry-point script
"""Two local SQLite files model independent caller/provider commits.
Not a real remote service, production queue or end-to-end exactly-once proof.
"""
import json
import sqlite3
import tempfile
from pathlib import Path
def provider(path, operation, payload):
with sqlite3.connect(path) as db:
db.execute("CREATE TABLE IF NOT EXISTS effects (operation TEXT PRIMARY KEY, payload TEXT NOT NULL, receipt TEXT NOT NULL)")
# Serializes the read/check/write in this local demonstration.
db.execute("BEGIN IMMEDIATE")
existing = db.execute("SELECT payload,receipt FROM effects WHERE operation=?", (operation,)).fetchone()
if existing:
if existing[0] != payload:
raise ValueError("same operation with different payload")
return existing[1]
receipt = "receipt:" + operation
db.execute("INSERT INTO effects VALUES(?,?,?)", (operation, payload, receipt))
return receipt
def demo():
with tempfile.TemporaryDirectory() as folder:
remote, local = Path(folder) / "provider.db", Path(folder) / "caller.db"
with sqlite3.connect(local) as db:
db.execute("CREATE TABLE intents(operation TEXT PRIMARY KEY, payload TEXT, status TEXT, receipt TEXT)")
db.execute("INSERT INTO intents VALUES('publish-1','report-v1','prepared',NULL)")
first = provider(remote, "publish-1", "report-v1")
# Simulated response loss: provider committed, caller did not get receipt.
with sqlite3.connect(local) as db:
before = db.execute("SELECT status FROM intents").fetchone()[0]
second = provider(remote, "publish-1", "report-v1")
with sqlite3.connect(local) as db:
db.execute("UPDATE intents SET status='confirmed', receipt=?", (second,))
with sqlite3.connect(remote) as db:
effects = db.execute("SELECT COUNT(*) FROM effects").fetchone()[0]
assert before == "prepared" and first == second and effects == 1
return dict(caller_before_recovery=before, same_receipt=first == second,
provider_effects=effects, caller_after_recovery="confirmed")
if __name__ == "__main__":
print(json.dumps(demo(), sort_keys=True))
Expected output when running locally
{"caller_after_recovery": "confirmed", "caller_before_recovery": "prepared", "provider_effects": 1, "same_receipt": true}- There is only one business effect for the server
- Consent diagram retry receipt consistent
- Remote capabilities and deduplication deadlines need to be verified separately
Acceptance task for this level
Draw the three moments when the server commits, when the response is lost, and when the caller tries again, and write down the facts that each party knows.
Check each item after completion
- The caller retains unknown judgment after timeout
- The provider may already have committed the effect
- The identity remains unchanged when retrying the same business intent.
Save your own processes, code and results. Acceptance requirements are provided here, and course mastery status will not be automatically graded or saved at this time.
Hide the answer and check your understanding
Is idempotency achieved by generating a new UUID each time it is retried?
Expand reference derivation
No. The service treats a new identity as a new operation. Idempotency requires the same business intent to keep a stable identity across attempts, with atomic deduplication at the service.
Further explanations and practice
When encountering unfamiliar principles, first read the implementation, continuous questioning and migration cases, and then independently explain the premise and boundaries. Answers and notes are saved to the original account record.
All linked explanations and exercises (5 )
- Idempotency and compensation when outcomes are unknown · answer independently
- Checkpoints, replay, and external side-effect boundaries · answer independently
- Lease takeover and fencing stale workers · answer independently
- One state machine for retries, deadlines, cancellation, and budgets · answer independently
- Approval snapshots, durable waiting, and one logical resumption · answer independently
Sources and verification scope
The principles are based on public information; the numbers, cases and tasks are the teaching design of this website. Offline experiments verify the range noted on this page, and the learning effect still needs to be judged through independent tasks and feedback.