Dealing with High Concurrency & Contention

High contention occurs when multiple concurrent requests attempt to mutate the exact same resource simultaneously (e.g. reserving the last seat on a flight, flash sale checkout, viral tweet like counter).

1. Concurrency Control Strategies

1. Optimistic Concurrency Control (OCC)

• Assumes conflicts are rare. Every record has a version column:

  UPDATE inventory 
  SET quantity = quantity - 1, version = version + 1 
  WHERE item_id = 42 AND version = 5;

• If zero rows were updated, a concurrent thread modified the record first; the application retries.

2. Pessimistic Locking (SELECT ... FOR UPDATE)

• Acquires a row-level lock on the database before reading:

  BEGIN;
  SELECT quantity FROM inventory WHERE item_id = 42 FOR UPDATE;
  UPDATE inventory SET quantity = quantity - 1 WHERE item_id = 42;
  COMMIT;

• Danger: Can cause thread starvation, connection pool exhaustion, and deadlocks under high load.

3. Distributed In-Memory Locking (Redlock)

• Use Redis SET resource_name my_random_value NX PX 30000 to acquire a lock across distributed workers with automated TTL release.

2. Advanced Mitigation: Write Coalescing & Sharded Counters

• Sharded Counters: If a celebrity post receives 100,000 likes per second, updating one row locks the database. Instead, create 20 counter slots (post_id_slot_1 through post_id_slot_20). Writes increment a random slot; reads sum all slots.
• Write Coalescing: Buffer increments in an in-memory ring buffer and flush aggregate batch updates to disk once every 100ms.

Key Architecture Trade-Offs & Decision Matrix