Transactions across services
How can a business invariant survive concurrency and partial progress?
Slide contents
1. Transactions across services
How can a business invariant survive concurrency and partial progress?
2. Reservations protect a business invariant
Two tasks compete for one resource.
3. The lab’s atomicity boundary is etcd
One Txn links task-creation keys.
4. Atomicity does not choose concurrent order
An indivisible commit can still break a shared invariant.
5. An isolation label needs a concrete history
Compare observations rather than vendor labels.
6. Two writes can lose one increment
Reading and writing occur at different times.
7. Version comparison protects the decision
A mutation is allowed only for the observed state.
8. A consistent snapshot may be insufficient
Now SQL: same questions, a different storage model.
9. Different rows can violate one constraint
Each transaction is valid against its snapshot.
10. Serializability can require abort and retry
The system rejects an incompatible concurrent history.
11. A shared invariant suggests a data boundary
Joint decisions are simpler within one transaction.
12. 2PC separates preparation from decision
Participant readiness is not commitment.
13. Prepared preserves an obligation across restart
A participant persists enough state to honor the decision.
14. The decision must survive redelivery
Commit or abort is persisted before notifying participants.
15. A prepared timeout does not authorize abort
Another participant may already know the decision.
16. Paxos and 2PC have different responsibilities
Replicating a decision does not by itself merge business boundaries.
17. A saga makes intermediate results explicit
Local commits become visible before the process finishes.
18. Compensation preserves others’ work
Cancelling a reservation does not restore an old snapshot.
19. The intermediate state gets its own status
A lost reply is neither success nor cancellation.
20. Two separate writes leave a loss window
The database and broker do not share one commit.
21. Outbox commits intent with the task
Publication becomes recoverable work.
22. A broker acknowledgment can also be lost
The relay retries with the same eventId.
23. Every crash leaves a defined continuation
Inspect durable state at each boundary.
24. Repair reservation and intent delivery
Limit 1, both reads count=0, quota mod_revision=17: prove the invariant.
Find write skew
Choose the atomic boundary
Trace the lost reply
Separate compensation from rollback
25. Guarantees start at the invariant boundary
Choose mechanisms by valid intermediate states.
26. After this lecture, you can
Expose an invariant violation through a concurrent history.
Distinguish local transactions, 2PC and sagas.
Explain durable intent and duplicate publication.