# Serializability > Serializability guarantees that concurrent transactions have the same effect as some one-at-a-time execution. In system design, it helps protect rules such as inventory limits and spendable balances when several requests read and update related data at once. Source: https://sysround.com/concepts/serializability Updated: 2026-11-05 ## How serializability works Start with an invariant: a rule that must remain true after every committed transaction. For an account with a two-stream limit, the transaction must check active streams and create a new stream only if capacity remains. Without sufficient isolation, two transactions can each count one active stream and insert a different new stream. Both commit, leaving three streams. This is write skew: the transactions write different rows, but their decisions depend on overlapping reads. Serializable isolation permits concurrent execution only when the committed outcome is equivalent to some serial order. In the stream example, both new admissions cannot commit successfully: the transaction that runs second in the equivalent serial order must see the limit reached. Databases can enforce this through serializable two-phase locking, optimistic validation, or serializable snapshot isolation. Locking may block conflicting work; validation-based approaches may abort transactions that cannot safely commit. MVCC alone does not imply serializability. The guarantee includes relevant predicates, not just existing rows. A query such as 'count active streams for this account' must account for concurrent inserts that would change its result. Keep that query and the admission write inside the same serializable transaction, and retry the whole transaction after a serialization failure. The guarantee stops at the transaction boundary: it does not automatically cover another database, a cache, or a payment provider. It also does not require real-time ordering between transactions; strict serializability adds that requirement. ## Worked example: Enforcing a two-stream account limit An account allows two active streams and currently has one. Requests A and B each begin a transaction, count one active stream, and insert a new session row. Under snapshot isolation, both may commit because they insert different rows, leaving three active streams. Under serializable isolation, that outcome cannot commit: in either serial order, the second request would see two streams and reject admission. The database may block one request or abort a transaction. If B aborts, the application retries its entire transaction, recounts two streams, and returns a limit-reached response. Both the count and insert must be inside the transaction. Starting playback is a separate step that needs authorization tied to the committed session. ## Trade-offs - **Simpler reasoning about invariants.** You can reason about one transaction at a time, provided each transaction preserves the invariant and all relevant operations share the isolation boundary. - **Contention costs.** Hot inventory, accounts, or broad predicates can cause blocking, deadlocks, or serialization failures that reduce throughput and increase latency. - **Retry complexity.** Applications must retry the entire aborted transaction with bounded attempts and backoff, without repeating irreversible external side effects. - **Transaction size matters.** Long transactions and large read sets hold resources longer or create more opportunities for validation conflicts. - **Distributed coordination.** Serializable transactions across shards require a database with cross-shard concurrency control and atomic commit, adding coordination and failure-handling costs. - **Not always necessary.** A conditional update, uniqueness constraint, or explicit lock can sometimes enforce a narrow invariant more directly than making the whole workflow serializable. ## When to use it in a system design interview - Several requests can concurrently check a condition and update different rows that collectively determine whether it still holds. - The design must preserve a hard limit, such as available cash, multi-night room inventory, or account-wide stream capacity. - An invariant depends on a query result or range rather than a single known row. - Snapshot isolation permits write skew, and enforcing the rule with explicit locking would be fragile or difficult to audit. - The correctness-critical work fits inside a short transaction supported by the chosen database. ## How to bring it up in the interview - Name the invariant first, then show a two-request interleaving that violates it under weaker isolation; do not introduce serializability as a blanket preference. - Draw the exact transaction boundary, including every read that informs the decision and every write needed to preserve the rule. - Explain whether the database blocks or aborts conflicting transactions, and describe whole-transaction retries; interviewers often probe what happens under hot-key contention. - Compare against a narrower solution, such as an atomic conditional decrement or a unique constraint, and explain why it is sufficient or insufficient. - State what remains outside the guarantee: external payments, cache reads, cross-service state, and real-time freshness are common follow-up probes. ## Common mistakes - Treating snapshot isolation or repeatable reads as universally equivalent to serializable isolation. - Assuming transactions must physically execute one at a time rather than merely produce an equivalent outcome. - Checking availability outside the transaction and expecting a serializable write transaction to protect that earlier decision. - Retrying only the failed statement, or calling an external provider inside a transaction that may be retried. - Confusing serializability with linearizability, or assuming a local transaction protects invariants across independent services. ## Interview questions where it comes up - [Design a ticket booking system like Ticketmaster](https://sysround.com/questions/design-ticketmaster): Seat holds and purchases require a concurrency-control strategy that prevents overlapping requests from claiming the same scarce inventory. - [Design a hotel booking system](https://sysround.com/questions/design-hotel-booking-system): Checking and reserving inventory across several nights requires one transaction boundary that preserves every night's capacity under concurrent bookings. - [Design a stock trading app like Robinhood](https://sysround.com/questions/design-robinhood): Concurrent orders must reserve cash or shares without collectively exceeding the account's available assets. - [Design a payment system](https://sysround.com/questions/design-payment-system): Concurrent refunds and payouts require transaction isolation that preserves refundable amounts and spendable balances. - [Design Netflix's concurrent screen limit](https://sysround.com/questions/design-netflix-screen-limit): Concurrent admission requests can produce write skew unless slot allocation enforces the account-wide limit atomically. - [Design a wire transfer system](https://sysround.com/questions/design-wire-transfer-system): Concurrent transfers must preserve balance and ledger invariants within a clearly defined transactional boundary. ## FAQ ### What is the difference between serializability and linearizability? Serializability makes transactions equivalent to some serial execution, without necessarily respecting real-time order. Linearizability makes operations appear to occur atomically between invocation and response while respecting real-time order. Strict serializability combines serializable transactions with real-time ordering. ### Does serializable isolation prevent write skew? Yes, when the relevant reads and writes are inside serializable transactions within the same supported transaction scope. The database must prevent both transactions from committing an outcome that has no valid serial ordering. Reads performed earlier through a cache are not automatically protected. ### Does serializable isolation use locks? It can, but locks are not the only implementation. Serializable two-phase locking uses locks to constrain conflicting operations, while serializable snapshot isolation uses snapshots and dependency tracking to detect unsafe concurrency. The implementation determines whether your application primarily encounters waiting, deadlocks, or serialization failures. ## Related concepts - [Transaction isolation levels](https://sysround.com/concepts/isolation-levels) - [MVCC](https://sysround.com/concepts/mvcc) - [Two-phase locking](https://sysround.com/concepts/two-phase-locking) - [Linearizability](https://sysround.com/concepts/linearizability) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.