Read Committed versus Serializable isolation levels

WHAT THIS TESTS The interviewer wants to know if you can reason about the safety-versus-throughput trade-off in concurrent workloads, and whether you can precisely map isolation levels to the anomalies they eliminate.

A GOOD ANSWER COVERS Isolation defines how visible one transaction's uncommitted or in-flight changes are to others. The ANSI levels in increasing strictness are Read Uncommitted, Read Committed, Repeatable Read, and Serializable. The three classic anomalies are dirty reads (seeing uncommitted data), non-repeatable reads (a row changes value between two reads in the same transaction), and phantom reads (a range query returns different rows because another transaction inserted or deleted matching rows). Read Committed blocks dirty reads only: every statement sees the latest committed snapshot, so values can shift between statements. Serializable guarantees the outcome is equivalent to some serial ordering, eliminating all three anomalies plus subtler ones like write skew.

COMMON WRONG ANSWERS Saying Serializable just adds phantom protection on top of Repeatable Read; the bigger point is full serial equivalence. Assuming all engines implement a level identically; PostgreSQL Repeatable Read is snapshot isolation, while standard Repeatable Read still allows phantoms. Believing higher isolation has no cost when it raises lock contention or serialization-failure retries.

LIKELY FOLLOW-UPS How does MVCC let Read Committed avoid read locks? What is write skew and why does Snapshot Isolation permit it? How does Serializable Snapshot Isolation detect dangerous read-write dependencies?

ONE CONCRETE EXAMPLE Under Read Committed, a report summing account balances reads accounts twice and sees a transfer applied to the second read but not the first, producing an inconsistent total. Under Serializable, that report either sees the transfer fully or not at all, and conflicting transactions are aborted and retried rather than producing a phantom-corrupted sum.