🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🤝 धडा 11 — Services ओलांडून transactions: शाळेच्या सहलीचे booking

📍 तुम्ही इथे आहात: 18 पैकी धडा 11 · पुढील: lesson-12-rate-limiting

📦 या ब्रँचमध्ये काय आहे

धडे 01–10, आणि काम अनेक services मध्ये पसरलेले असताना "सगळे किंवा काहीच नाही", जिथे प्रत्येकीचा स्वतःचा database असतो. तुम्ही शिकता की local transaction पुरेसा का नाही, two-phase commit (2PC) आणि तो का अडकतो, sagas (orchestration आणि choreography), compensations, idempotency, आणि पुन्हा धडा 08 मधील outbox.

design/blocks.py — two_phase_commit(votes, coordinator_alive) आणि saga(steps, fail_at)
design/demo.py — python3 design/demo.py transactions
design/test_design.py — check L11

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कतरिना तिच्या मुलीसाठी शाळेची सहल book करते. तीन कार्यालयांचे एकमत हवे: seats कार्यालय, fees कार्यालय आणि bus कार्यालय. प्रत्येक कार्यालयाची स्वतःची नोंदवही आहे.

योजना A — फोन कॉल (2PC). दीपिका तिघांनाही फोन करते: "तुम्ही हे करू शकता का? हो असेल तर ते राखून ठेवा आणि माझ्या शब्दाची वाट पाहा." तिघेही हो म्हणतात आणि राखून ठेवतात: seat राखली, पैसे राखले, bus मधली जागा राखली. मग दीपिका म्हणते "चला!" आणि तिघेही ते लिहून घेतात. पण "राखून ठेवा" नंतर दीपिकाचा फोन बंद पडला, तर तिन्ही कार्यालये वाट पाहत राहतात. Seat राखलेलीच राहते. पैसे राखलेलेच राहतात. दुसरे कोणीच ते वापरू शकत नाही. दीपिका परत फोन करेपर्यंत ते थांबतात.

योजना B — undo यादी (saga). प्रत्येक कार्यालय आपला भाग लगेच करते आणि सोबत तो undo कसा करायचा हे लिहून ठेवते. Seats: झाले (undo: seat मोकळी करा). Fees: झाले (undo: पैसे परत). Bus: "माफ करा, bus भरली आहे." म्हणून कार्यालय उलट क्रमाने मागे जाते: पैसे परत करा, seat मोकळी करा. कोणीच थांबले नाही. थोड्या वेळासाठी seat घेतलेली होती आणि पैसे कापलेले होते — आणि मग दोन्ही undo झाले.

🗺️ आकृती

flowchart LR
    subgraph tpc["📞 2PC: one coordinator"]
      co["coordinator"] -->|"1 prepare"| s1["seats"]
      co -->|"1 prepare"| p1["fees"]
      co -->|"1 prepare"| b1["bus"]
      co -.->|"2 commit or abort"| s1
      dead["💀 coordinator dies after prepare<br/>→ BLOCKED, locks held"]
    end
    subgraph sg["📋 saga: local steps + undo"]
      a["✓ reserve seat"] --> b["✓ charge ₹500"] --> c["✗ book the bus"]
      c -->|"compensate"| rb["↩ refund ₹500"] --> rs["↩ release seat"]
    end

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l11

❓ काय

Local transaction — एकाच database च्या आत: BEGIN … COMMIT, सगळे किंवा काहीच नाही. तो दुसऱ्या service च्या database पर्यंत पोहोचू शकत नाही. Seats, fees आणि bus या तीन services झाल्या (धडा 09) की कोणताही एक COMMIT तिघांना व्यापत नाही.
Two-phase commit (2PC) — एक coordinator दोन टप्पे चालवतो:
1. prepare — प्रत्येक participant काम करतो, ज्याला स्पर्श केला त्याला lock लावतो, disk वर "ready" लिहितो, आणि हो किंवा नाही असे मत देतो;
2. commit किंवा abort — सगळे हो → सगळीकडे commit; कोणी एक नाही → सगळीकडे abort.
2PC का अडकतो — हो असे मत दिलेल्या participant ने coordinator चे ऐकण्याचे वचन दिलेले असते. तो स्वतःहून commit किंवा abort करू शकत नाही. दोन टप्प्यांच्या मध्ये coordinator गेला, तर हो म्हणणारे तो परत येईपर्यंत आपले locks धरून ठेवतात. (नाही असे मत दिलेला participant लगेच abort करू शकतो — फक्त हो म्हणणारे अडकतात.) 2PC मुळे प्रत्येक participant सर्वात हळू participant इतका हळू होतो, आणि प्रत्येक service ला एकच protocol बोलावा लागतो (उदाहरणार्थ XA).
Saga — local transactions ची मालिका. प्रत्येक पायरी तिच्या स्वतःच्या service मध्ये लगेच commit होते. प्रत्येक पायरीचे एक compensation असते: तिचा परिणाम undo करणारी एक नवी कृती. पायरी k अपयशी झाली, तर पायऱ्या k−1 … 1 ची compensations उलट क्रमाने चालवा.
Compensation म्हणजे delete करणे नव्हे — refund ही fees नोंदवहीतील एक नवी नोंद आहे; charge इतिहासात तसाच राहतो. काही पायऱ्या undo करता येत नाहीत (आधीच पाठवलेला SMS). त्या शेवटी ठेवा, अजूनही अपयशी होऊ शकणाऱ्या पायऱ्यांनंतर.
Orchestration — एक orchestrator (workflow service) पायऱ्या जाणतो आणि प्रत्येक service ला क्रमाने call करतो. एकाच ठिकाणी वाचायला आणि monitor करायला सोपे.
Choreography — केंद्र नाही: प्रत्येक service एका event ची वाट ऐकते आणि पुढचा publish करते (SeatReserved → fees charge करते → FeeCharged → bus book करते …). 2–3 पायऱ्यांसाठी कमी हलणारे भाग; अनेक पायऱ्यांसाठी मागोवा घेणे कठीण.
Idempotency — एखादी पायरी किंवा compensation दोनदा चालू शकते (retry, at-least-once queue — धडा 07). प्रत्येक call सोबत एक key असते (trip-42-charge), आणि service पुनरावृत्तीसाठी पहिलाच निकाल परत करते. दोनदा चाललेला refund एकदाच refund करायला हवा.
पुन्हा outbox (धडा 08) — प्रत्येक saga पायरी स्वतःचे table बदलते आणि पुढचा event त्याच local transaction मध्ये लिहिते. "charged" आणि "पुढच्या पायरीला सांगा" यांच्या मध्ये crash झाला तरी काहीच हरवत नाही.

🤔 का

कारण microservices data विभागतात. नियोजन कार्यालयाला तरीही वचन द्यायचे असते की "सहल एकतर पूर्ण book होते किंवा अजिबात होत नाही". 2PC हे वचन देतो, पण तो services ओलांडून locks धरून ठेवतो आणि coordinator थांबला की थांबतो. Saga कधीच global lock धरत नाही आणि प्रत्येक service स्वतंत्र ठेवते — त्याची किंमत म्हणजे थोड्या वेळाची एक मधली अवस्था जी इतर वाचकांना दिसू शकते (seat घेतली, मग मोकळी केली). म्हणून कार्यालय काहीही बांधण्याआधी दोन्ही लिहिते: पायऱ्या आणि त्यांचे undo.

🔧 कसे (या repo मध्ये)

design/blocks.py मध्ये:

two_phase_commit(votes, coordinator_alive=True) सगळी मते हो असतील तर COMMIT, कोणतेही नाही असेल तर ABORT, आणि prepare नंतर coordinator गेला तर BLOCKED … परत करतो. (हे model प्रत्येक मत-यादीसाठी BLOCKED परत करते; खऱ्या system मध्ये फक्त हो म्हणणारेच थांबतात.)
saga(steps, fail_at=None) (do, undo) जोड्या क्रमाने चालवतो. fail_at ला तो ✗ log करतो, पूर्ण झालेल्या पायऱ्यांचे undo उलट क्रमाने चालवतो (↩), आणि COMPENSATED परत करतो.

design/demo.py मधील transactions() शाळेची सहल book करतो.

🧪 करून पाहा

python3 design/demo.py transactions
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import two_phase_commit, saga
for votes in ([True] * 3, [True, False, True], [False] * 3):
    print(votes, "→", two_phase_commit(votes), "| coordinator dead →", two_phase_commit(votes, coordinator_alive=False)[:7])
steps = [("reserve seat", "release seat"), ("charge Katrina ₹500", "refund Katrina ₹500"), ("book the bus", "cancel the bus")]
for f in (None, 0, 1, 2):
    s, log = saga(steps, fail_at=f)
    print(f"fail_at={f!s:<4} → {s:<11} {' · '.join(log)}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

transactions हे छापतो:

── a school-trip booking touches 3 services: seats, payment, bus
   2PC, all vote yes → COMMIT · one votes no → ABORT
   2PC, the coordinator dies after 'prepare' → BLOCKED — participants hold locks until the coordinator returns
   saga, the bus is full → COMPENSATED: ✓ reserve seat · ✓ charge Katrina ₹500 · ✗ book the bus · ↩ refund Katrina ₹500 · ↩ release seat
   sagas trade 'all at once' for 'eventually consistent, with an undo for every step'

तुमचा snippet हे छापतो:

[True, True, True] → COMMIT | coordinator dead → BLOCKED
[True, False, True] → ABORT | coordinator dead → BLOCKED
[False, False, False] → ABORT | coordinator dead → BLOCKED
fail_at=None → DONE        ✓ reserve seat · ✓ charge Katrina ₹500 · ✓ book the bus
fail_at=0    → COMPENSATED ✗ reserve seat
fail_at=1    → COMPENSATED ✓ reserve seat · ✗ charge Katrina ₹500 · ↩ release seat
fail_at=2    → COMPENSATED ✓ reserve seat · ✓ charge Katrina ₹500 · ✗ book the bus · ↩ refund Katrina ₹500 · ↩ release seat

Tests मध्ये ✅ L11 2PC blocks without its coordinator; a saga compensates in reverse असते.

🏁 तुम्ही आत्ताच काय सिद्ध केले

Coordinator जिवंत असेपर्यंत 2PC सोपा आहे: सगळे हो → COMMIT, एक नाही → ABORT. Prepare नंतर तो गेला, तर उत्तर BLOCKED — locks धरलेले, काम थांबलेले. Saga कधीच अडकत नाही: पायरी 0 वर अपयश आले तर कोणताही undo लागत नाही, पायरी 1 वर अपयश एक पायरी undo करते, पायरी 2 वर अपयश दोन undo करते, नेहमी सर्वात नवी आधी. Saga किती पुढे गेला त्यानुसार compensations ची संख्या वाढते — आणि प्रत्येक compensation दोनदा चालवणे सुरक्षित असायला हवे.

⚠️ नेहमीच्या चुका

वेगवेगळ्या teams च्या मालकीच्या services ओलांडून 2PC — एक हळू team इतर प्रत्येक team ला अडवते
compensation नसलेली saga पायरी, जी production मधील पहिल्या अपयशावर लक्षात येते
idempotent नसलेली compensations — पुन्हा चाललेला refund पालकाला दोनदा पैसे देतो
undo न होणारी पायरी (SMS पाठवणे, ticket छापणे) अपयशी होऊ शकणाऱ्या पायरीच्या आधी ठेवणे
पुढचा saga event local transaction च्या बाहेर publish करणे — धडा 08 मधील dual-write bug; outbox वापरा
saga पूर्ण होण्याआधीच मधली अवस्था अंतिम म्हणून दाखवणे ("सहल book झाली!") — शेवटच्या पायरीपर्यंत "booking…" दाखवा
दहा पायऱ्यांसाठी choreography — booking कुठे आहे हे कोणीच सांगू शकत नाही; orchestrator वापरा

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — AWS Step Functions मध्ये एक orchestrated saga. प्रत्येक task मध्ये एक Catch असतो जो compensations कडे, उलट क्रमाने, उडी मारतो (Amazon States Language, छोटे केलेले):

{
  "StartAt": "ReserveSeat",
  "States": {
    "ReserveSeat": { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:reserve-seat",
      "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "Failed" }], "Next": "ChargeFee" },
    "ChargeFee":   { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:charge-fee",
      "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "ReleaseSeat" }], "Next": "BookBus" },
    "BookBus":     { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:book-bus",
      "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "RefundFee" }], "End": true },
    "RefundFee":   { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:refund-fee",
      "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 5, "BackoffRate": 2 }], "Next": "ReleaseSeat" },
    "ReleaseSeat": { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:release-seat",
      "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 5, "BackoffRate": 2 }], "Next": "Failed" },
    "Failed":      { "Type": "Fail", "Error": "TripNotBooked" }
  }
}

Compensations retry करतात (ती पूर्ण व्हायलाच हवीत), म्हणून ती idempotent हवीत. प्रत्येक service मध्ये, आधीच हाताळलेल्या keys लक्षात ठेवा:

CREATE TABLE handled_requests (idempotency_key text PRIMARY KEY, result jsonb, created_at timestamptz DEFAULT now());
-- inside the same transaction as the refund:
INSERT INTO handled_requests (idempotency_key, result) VALUES ('trip-42-refund', '{"refunded": 500}')
ON CONFLICT (idempotency_key) DO NOTHING;   -- 0 rows inserted → it was done before; return the saved result

2PC एकाच database कुटुंबाच्या आत खरोखर असतो. PostgreSQL मध्ये prepared transactions आहेत (default ने बंद — max_prepared_transactions = 0), जे transaction managers वापरतात:

BEGIN; UPDATE seats SET taken = true WHERE trip = 42 AND seat = 17;
PREPARE TRANSACTION 'trip-42';     -- phase 1: saved to disk, locks held
COMMIT PREPARED 'trip-42';         -- phase 2 (or ROLLBACK PREPARED 'trip-42')

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: विसरलेला prepared transaction locks धरून ठेवतो आणि VACUUM थांबवतो. SELECT * FROM pg_prepared_xacts; तपासा. Sagas साठी, compensation मार्गाने संपणाऱ्या executions वर alarm लावा — प्रत्येक म्हणजे charge आणि refund दोन्ही पाहिलेला एक पालक.

⏭️ पुढे

कार्यालय आता एकमत करू शकते आणि undo करू शकते. पण एका पालकाच्या app ने सेकंदाला 1,000 requests पाठवल्या तर? Rate limiting.

git checkout lesson-12-rate-limiting

🤝 Lesson 11 — Transactions across services: the school trip booking

📍 You are here: Lesson 11 of 18 · Next: lesson-12-rate-limiting

📦 What's in this branch

Lessons 01–10, plus "all or nothing" when the work spans several services, each with its own database. You learn why a local transaction is not enough, two-phase commit (2PC) and why it blocks, sagas (orchestration and choreography), compensations, idempotency, and the outbox from lesson 08 again.

design/blocks.py — two_phase_commit(votes, coordinator_alive) and saga(steps, fail_at)
design/demo.py — python3 design/demo.py transactions
design/test_design.py — check L11

🧒 Explain like I'm 5

Katrina books a school trip for her daughter. Three offices must agree: the seats office, the fees office and the bus office. Each office has its own book.

Plan A — the phone call (2PC). Dipika phones all three: "Can you do it? If yes, hold it and wait for my word." All three say yes and hold: a seat is held, the money is held, the bus place is held. Then Dipika says "Go!" and all three write it down. But if Dipika's phone dies after "hold", the three offices wait. The seat stays held. The money stays held. Nobody else can use them. They wait until Dipika calls back.

Plan B — the undo list (saga). Each office does its part at once and also writes down how to undo it. Seats: done (undo: release the seat). Fees: done (undo: refund). Bus: "Sorry, the bus is full." So the office walks back in reverse: refund the money, release the seat. Nobody waited. For a short time, the seat was taken and the money was charged — and then both were undone.

🗺️ Diagram

flowchart LR
    subgraph tpc["📞 2PC: one coordinator"]
      co["coordinator"] -->|"1 prepare"| s1["seats"]
      co -->|"1 prepare"| p1["fees"]
      co -->|"1 prepare"| b1["bus"]
      co -.->|"2 commit or abort"| s1
      dead["💀 coordinator dies after prepare<br/>→ BLOCKED, locks held"]
    end
    subgraph sg["📋 saga: local steps + undo"]
      a["✓ reserve seat"] --> b["✓ charge ₹500"] --> c["✗ book the bus"]
      c -->|"compensate"| rb["↩ refund ₹500"] --> rs["↩ release seat"]
    end

🗺️ Drawn version + a lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l11

❓ What

Local transaction — inside one database: BEGIN … COMMIT, all or nothing. It cannot reach into another service's database. Once seats, fees and the bus are three services (lesson 09), no single COMMIT covers all three.
Two-phase commit (2PC) — a coordinator runs two phases:
1. prepare — each participant does the work, locks what it touched, writes "ready" to disk, and votes yes or no;
2. commit or abort — all yes → commit everywhere; any no → abort everywhere.
Why 2PC blocks — a participant that voted yes has promised to obey the coordinator. It may not commit or abort on its own. If the coordinator dies between the phases, the yes-voters hold their locks until it comes back. (A participant that voted no may abort at once — only the yes-voters are stuck.) 2PC also makes every participant as slow as the slowest one, and it needs every service to speak the same protocol (XA, for example).
Saga — a sequence of local transactions. Each step commits in its own service at once. Each step has a compensation: a new action that undoes its effect. If step k fails, run the compensations of steps k−1 … 1 in reverse.
Compensation is not deletion — a refund is a new entry in the fees book; the charge stays in the history. Some steps cannot be undone (an SMS already sent). Put those last, after the steps that can still fail.
Orchestration — one orchestrator (a workflow service) knows the steps and calls each service in order. Easy to read and to monitor in one place.
Choreography — no centre: each service listens for an event and publishes the next one (SeatReserved → fees charges → FeeCharged → bus books …). Fewer moving parts for 2–3 steps; hard to follow for many steps.
Idempotency — a step or a compensation may run twice (a retry, an at-least-once queue — lesson 07). Each call carries a key (trip-42-charge), and the service returns the first result for a repeat. A refund that runs twice must refund once.
The outbox again (lesson 08) — each saga step changes its own table and writes the next event in the same local transaction. A crash between "charged" and "tell the next step" loses nothing.

🤔 Why

Because microservices split the data. The planning office must still promise "a trip is either booked fully or not at all". 2PC gives that promise, but it holds locks across services and stops when its coordinator stops. A saga never holds a global lock and keeps each service independent — the price is a short in-between state that other readers can see (a seat taken, then released). So the office writes both: the steps and their undo, before building anything.

🔧 How (in this repo)

In design/blocks.py:

two_phase_commit(votes, coordinator_alive=True) returns COMMIT if all votes are yes, ABORT if any is no, and BLOCKED … if the coordinator died after prepare. (The model returns BLOCKED for every vote list; in a real system only the yes-voters wait.)
saga(steps, fail_at=None) runs (do, undo) pairs in order. At fail_at it logs ✗, runs the finished steps' undo in reverse (↩), and returns COMPENSATED.

transactions() in design/demo.py books a school trip.

🧪 Try it

python3 design/demo.py transactions
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import two_phase_commit, saga
for votes in ([True] * 3, [True, False, True], [False] * 3):
    print(votes, "→", two_phase_commit(votes), "| coordinator dead →", two_phase_commit(votes, coordinator_alive=False)[:7])
steps = [("reserve seat", "release seat"), ("charge Katrina ₹500", "refund Katrina ₹500"), ("book the bus", "cancel the bus")]
for f in (None, 0, 1, 2):
    s, log = saga(steps, fail_at=f)
    print(f"fail_at={f!s:<4} → {s:<11} {' · '.join(log)}")
EOF

✅ Verify — what you should see

transactions prints:

── a school-trip booking touches 3 services: seats, payment, bus
   2PC, all vote yes → COMMIT · one votes no → ABORT
   2PC, the coordinator dies after 'prepare' → BLOCKED — participants hold locks until the coordinator returns
   saga, the bus is full → COMPENSATED: ✓ reserve seat · ✓ charge Katrina ₹500 · ✗ book the bus · ↩ refund Katrina ₹500 · ↩ release seat
   sagas trade 'all at once' for 'eventually consistent, with an undo for every step'

Your snippet prints:

[True, True, True] → COMMIT | coordinator dead → BLOCKED
[True, False, True] → ABORT | coordinator dead → BLOCKED
[False, False, False] → ABORT | coordinator dead → BLOCKED
fail_at=None → DONE        ✓ reserve seat · ✓ charge Katrina ₹500 · ✓ book the bus
fail_at=0    → COMPENSATED ✗ reserve seat
fail_at=1    → COMPENSATED ✓ reserve seat · ✗ charge Katrina ₹500 · ↩ release seat
fail_at=2    → COMPENSATED ✓ reserve seat · ✓ charge Katrina ₹500 · ✗ book the bus · ↩ refund Katrina ₹500 · ↩ release seat

The tests include ✅ L11 2PC blocks without its coordinator; a saga compensates in reverse.

🏁 What you just proved

2PC is simple while the coordinator lives: all yes → COMMIT, one no → ABORT. When it dies after prepare, the answer is BLOCKED — locks held, work stopped. The saga never blocks: a failure at step 0 needs no undo, a failure at step 1 undoes one step, a failure at step 2 undoes two, always newest first. The number of compensations grows with how far the saga got — and each one must be safe to run twice.

⚠️ Common mistakes

2PC across services owned by different teams — one slow team blocks every other team
a saga step with no compensation, found out on the first failure in production
compensations that are not idempotent — a retried refund pays the parent twice
an irreversible step (send SMS, print a ticket) placed before a step that can fail
publishing the next saga event outside the local transaction — the dual-write bug of lesson 08; use the outbox
showing the in-between state as final ("Trip booked!") before the saga is done — show "booking…" until the last step
choreography for ten steps — nobody can say where a booking is; use an orchestrator

🏭 In production

On a real account — an orchestrated saga in AWS Step Functions. Each task has a Catch that jumps to the compensations, in reverse (Amazon States Language, shortened):

{
  "StartAt": "ReserveSeat",
  "States": {
    "ReserveSeat": { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:reserve-seat",
      "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "Failed" }], "Next": "ChargeFee" },
    "ChargeFee":   { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:charge-fee",
      "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "ReleaseSeat" }], "Next": "BookBus" },
    "BookBus":     { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:book-bus",
      "Catch": [{ "ErrorEquals": ["States.ALL"], "Next": "RefundFee" }], "End": true },
    "RefundFee":   { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:refund-fee",
      "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 5, "BackoffRate": 2 }], "Next": "ReleaseSeat" },
    "ReleaseSeat": { "Type": "Task", "Resource": "arn:aws:lambda:ap-south-1:111122223333:function:release-seat",
      "Retry": [{ "ErrorEquals": ["States.ALL"], "MaxAttempts": 5, "BackoffRate": 2 }], "Next": "Failed" },
    "Failed":      { "Type": "Fail", "Error": "TripNotBooked" }
  }
}

Compensations retry (they must finish), so they must be idempotent. In each service, remember the keys you have already handled:

CREATE TABLE handled_requests (idempotency_key text PRIMARY KEY, result jsonb, created_at timestamptz DEFAULT now());
-- inside the same transaction as the refund:
INSERT INTO handled_requests (idempotency_key, result) VALUES ('trip-42-refund', '{"refunded": 500}')
ON CONFLICT (idempotency_key) DO NOTHING;   -- 0 rows inserted → it was done before; return the saved result

2PC does exist inside one database family. PostgreSQL has prepared transactions (off by default — max_prepared_transactions = 0), used by transaction managers:

BEGIN; UPDATE seats SET taken = true WHERE trip = 42 AND seat = 17;
PREPARE TRANSACTION 'trip-42';     -- phase 1: saved to disk, locks held
COMMIT PREPARED 'trip-42';         -- phase 2 (or ROLLBACK PREPARED 'trip-42')

🏭 Why this matters in production: a forgotten prepared transaction holds locks and stops VACUUM. Check SELECT * FROM pg_prepared_xacts;. For sagas, alarm on executions that end in the compensation path — each one is a parent who saw a charge and a refund.

⏭️ Next

The office can now agree and undo. But what if one parent's app sends 1,000 requests a second? Rate limiting.

git checkout lesson-12-rate-limiting

← Previousconsistency Next →rate limiting

This page is the lesson's README from the lesson-11-distributed-transactions branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.