Flash Sale — Naive (Direct DB Lock)

Designing a flash sale system is one of the most challenging system design interview questions because it forces candidates to reason about concurrent access to a single shared resource — limited inventory — under extreme traffic conditions. The naive direct database lock approach is where every candidate should start: it establishes the correctness baseline that makes the improvements in queue-based and tiered architectures measurable and concrete.

The core challenge is atomically decrementing inventory without overselling. In the naive approach, every purchase attempt opens a PostgreSQL transaction, executes SELECT FOR UPDATE on the inventory row to acquire an exclusive row-level lock, checks if remaining_stock > 0, decrements the count via UPDATE, inserts an order record, and commits. The SELECT FOR UPDATE guarantees mutual exclusion: while one transaction holds the lock, all other transactions targeting the same row block in a wait queue until the lock is released.

This approach provides perfect correctness — zero overselling is guaranteed by PostgreSQL's row-level locking semantics. But the cost is serialization. Each transaction holds the lock for 50-100ms (lock acquisition + disk read + update + WAL write + commit). At 75ms average lock hold time, a single inventory row processes approximately 13 transactions per second. With 10,000 items available and 50,000 concurrent users, the math is brutal: 50K users competing for locks on a handful of hot item rows, with 99%+ of transactions timing out in the lock wait queue.

The connection pool becomes the hard ceiling. PostgreSQL typically supports 100-500 connections. Each blocked SELECT FOR UPDATE holds a connection for the duration of the lock wait (which can be seconds under contention). At 50K concurrent requests, the connection pool exhausts immediately, and subsequent requests receive connection errors before even attempting the transaction. The system does not degrade gracefully — it cliff-edges from functional to broken.

The read path (availability checks) compounds the problem. Without a cache layer, every GET /availability request queries PostgreSQL directly, competing with purchase transactions for the same connection pool. At 40% read traffic, availability checks consume connections that purchase transactions need, creating a tragic feedback loop: users see 'items available' from read queries but cannot purchase because the connection pool is saturated by other purchases.

This template makes the serialization bottleneck visible and quantifiable. Run the simulation at increasing RPS and watch lock wait time grow from milliseconds to seconds, then connection pool utilization hit 100%, then error rates spike. The comparison with the Queue and Tiered variants provides the concrete numbers needed to explain why demand shaping (virtual queues) and caching (Redis atomic DECR) are essential for production flash sales.

Another critical failure mode in the naive approach is deadlocks. When a single transaction touches multiple inventory rows (e.g., a user buying items A and B together), and another transaction touches the same rows in a different order, PostgreSQL detects a deadlock and aborts one transaction. Under high concurrency with multi-item carts, deadlock frequency increases quadratically with the number of concurrent transactions. The naive approach has no retry logic or deadlock avoidance strategy — aborted transactions simply fail.

The naive approach also lacks any observability into the lock contention. Without monitoring lock wait times, queue depths, or connection pool utilization, operators have no early warning before the system collapses. The simulation exposes these metrics, making the degradation curve visible. Understanding this degradation is essential for system design interviews — interviewers want to see candidates identify specific failure modes, not just wave at 'scalability issues.'

Flash sale system design appears in interviews at Amazon, Shopify, Ticketmaster, Nike, Walmart, and Target. Interviewers expect candidates to start with the database lock approach, identify the serialization bottleneck, and propose demand shaping as the first optimization — then discuss bot detection and CDN edge absorption that motivate the tiered approach.

The naive flash sale system is a four-component linear architecture: Client, Load Balancer, SaleService, and PostgreSQL database. There is no cache, no event stream, no queue, no bot detection, and no separation between the read and write paths. Every request follows the same synchronous path from client to database.

All traffic enters through the AWS Application Load Balancer, which distributes requests across SaleService pods using round-robin. The Load Balancer adds approximately 2ms of routing latency and supports up to 100K RPS, but the real capacity ceiling is determined entirely by the database behind SaleService. Both purchase attempts and availability checks flow through the same LB and service.

The SaleService is a stateless REST API running on 5 pods with 50 threads each (250 concurrent connections). It handles two operations: (1) purchase attempt — open a PostgreSQL transaction, SELECT FOR UPDATE on the inventory row, check remaining_stock > 0, UPDATE to decrement, INSERT an order record, COMMIT; (2) availability check — SELECT remaining_stock from the inventory table (no lock). The service processing time is approximately 8ms for business logic, but purchase latency is dominated by the database transaction time (50-100ms for the lock + write path, potentially seconds under contention).

PostgreSQL stores two tables: inventory and orders. The inventory table is the critical bottleneck — every purchase attempt acquires an exclusive row-level lock on the target item's inventory row. At high concurrency, the lock wait queue for popular items grows to thousands of transactions, most of which time out. The orders table stores confirmed purchases, inserted within the same transaction as the inventory decrement for atomicity.

The system has no redundancy at the data layer. A single PostgreSQL primary handles all reads and writes with 100 max connections. If the database fails, both purchases and availability checks stop entirely. There is no cache (every availability check hits the database), no event stream (payment is processed synchronously within the purchase transaction), and no demand shaping (all 50K concurrent users hit the database simultaneously).

The transaction isolation level matters significantly. At the default READ COMMITTED level, the SELECT FOR UPDATE sees committed data and acquires a lock. At SERIALIZABLE, PostgreSQL would detect more anomalies but abort more transactions due to serialization failures. The naive approach uses READ COMMITTED as the pragmatic choice — it prevents overselling via the explicit row lock without the overhead of full serializability. The trade-off is that phantom reads are possible on the availability check path (a user might see stale stock counts between the SELECT and the next committed UPDATE), but this is acceptable since the authoritative check happens within the locked purchase transaction.

Error handling in the naive approach is straightforward but limited. Lock wait timeouts (default 30 seconds in PostgreSQL) cause the transaction to abort with a timeout error. Connection pool exhaustion returns an immediate error. The service returns HTTP 503 (Service Unavailable) for both cases. There is no retry logic, no circuit breaker, and no fallback path — the system either succeeds or fails.

The concrete scaling ceiling is approximately 200 concurrent purchase attempts before lock contention causes cascading timeouts. At this point, the connection pool is saturated, lock wait times exceed SLO thresholds, and availability checks are starved of connections. The system degrades from functional to broken over a narrow traffic band — there is no graceful degradation curve.