I think about serialized transactions whenever concurrency can create an impossible business outcome. Speed is useful, but I recommend protecting invariants when the final result must look like one valid order.
The result matters more than the internal schedule
The distributed systems test is delay, duplication, and loss. Everything else is the easy part.
The database may do clever locking or validation internally. From the application point of view, the outcome should look as if one transaction happened first and the other happened second.
Ledger example
If the approach cannot survive a real request, retry, and handoff, I do not treat it as ready.
Two customers try to reserve the last seat. Serialized transactions let one reservation commit and force the other to retry or fail. The last seat is not sold twice.
Serialized write code
A code sample earns space here only when it explains the safety rule.
Serializable isolation keeps the last seat from being sold twice:
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
UPDATE seats
SET held_by = 'customer-42'
WHERE seat_id = '12A' AND held_by IS NULL;
COMMIT;The serializable transaction makes the seat hold behave as if one buyer acted at a time. If two buyers race, the database must reject one conflicting write.
Sequence diagram: last seat reservation
Both requests are concurrent, but the committed result has one clear order.
The serialization choice
- Use serialized behavior when invariants must never be broken.
- Expect retries when conflicts are real.
- Do not weaken isolation just to hide a design conflict.