Why should you care?

Flipkart product page reads should not lock checkout updates — MVCC lets SELECT proceed while INSERT order_items runs.

See it live — copy this example

Run in MySQL Workbench or the mysql CLI.

-- Session A
START TRANSACTION;
SELECT stock_qty FROM products WHERE product_id = 10;
-- Session B updates stock and COMMIT
-- Session A (REPEATABLE READ):
SELECT stock_qty FROM products WHERE product_id = 10;
COMMIT;

What happened?

• First SELECT pins a snapshot.
• B’s commit does not change A’s second SELECT under REPEATABLE READ.
• Undo chains let InnoDB serve old versions without blocking B’s write.

Practice next

1. Two sessions, REPEATABLE READ default.
2. A reads stock; B changes stock; A reads again — same value.
3. Reset A; use READ COMMITTED — second read sees B’s change.
4. Hold transaction open 5 minutes — watch undo length conceptually.
5. SELECT with LOCK IN SHARE MODE — bypasses plain MVCC read.

Remember

MVCC = versioned rows + undo logs. Readers use snapshots; writers create new versions. Long open transactions hurt purge and disk.

DataFlow catalog browse during sale

Millions of SELECTs on products while orders decrement stock — MVCC keeps pages loading.

Outcome: Browsing stays fast without serializing every read.