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
A shared past does not coordinate independent writes.
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 automatically 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. Uncertainty gets its own status
Users need a valid intermediate state.
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
Prove the invariant for two concurrent attempts.
Find write skew
Choose the atomic boundary
Trace the lost reply
25. Guarantees start at the invariant boundary
Choose mechanisms by valid intermediate states.
26. Decisions for our service
Expose an invariant violation through a concurrent history.
Distinguish local transactions, 2PC and sagas.
Explain durable intent and duplicate publication.