Alibaba reported a peak of 583,000 order creations per second during Singles' Day in 2020. Suppose one promoted item accounts for 0.5% of those orders and its stock is held in a single row. Roughly how many updates per second does that row have to absorb?

The assumptions, stated

• 583,000 order creations per second at peak, as reported for Singles' Day 2020.
• One item is 0.5% of orders during that window.
• Stock for that item is one row, decremented inside the order transaction.

The arithmetic

583,000 × 0.005 = 2,915 updates per second on one row.

Why one row cannot do that

Row-level locking serialises every update to that row. Each transaction acquires the lock, reads, writes, appends to the write-ahead log and releases. Even at an optimistic 100 microseconds of lock hold, the ceiling is 10,000 per second — and real transactions include a client round trip inside the lock's lifetime, so a 1 ms transaction gives a ceiling near 1,000 per second.

At 2,900 arrivals against a ~1,000 service rate, the queue grows without bound and latency diverges. This is Little's Law with λ greater than the service rate, and no amount of waiting fixes it.

The deeper point: this is a serialisation constraint, not a capacity constraint. Faster CPUs, more replicas, more shards and more application servers change nothing, because every update must touch the same row.

Why the other options fail

• 30 per second applies 0.005% instead of 0.5% — two orders of magnitude out, and the answer that makes a flash sale look like an ordinary workload.
• 290 per second is 0.05%: the right method with a misplaced decimal, and the decimal decides the architecture, because 290 per second is uncomfortably feasible on one row and 2,900 is not.
• 29,000 per second is 5%, which over-states the concentration and would rule out designs that in fact work.

Which assumption dominates the error

The concentration, by far. Flash-sale traffic is far more skewed than a percentage suggests: in the opening seconds a single promoted item can be several percent of all orders. Model the peak of the skew rather than its average, because the architecture is chosen for the worst second, not the mean minute.

What the number rules in and out

Out: any design where the authoritative stock count is decremented synchronously in the request path.

In: bucketed counters — split the stock into N sub-counters, route by hash, rebalance as buckets empty; at N = 100 the 2,900 per second becomes 29 per second per bucket · an in-memory reservation service that owns the count, issues reservations and persists asynchronously · admission control that admits only as many requests as there is stock, so the database sees thousands of requests rather than millions.

When this is over-engineering

For a catalogue whose hottest item is 0.01% of a 1,000 per second workload, the row sees 0.1 updates per second and a single row with optimistic concurrency is exactly right. Bucketed counters there add reconciliation complexity, a harder "is it really sold out" question, and operational surface, in exchange for headroom nobody will use.