TL;DR: You cannot scale into a spike that arrives faster than a pod can start. Absorb it instead: put a durable queue in front of writes so the database sees a steady rate, cache aggressively so reads never reach it, scale consumers on queue depth rather than CPU, and pre-warm before a sale you know the time of.
How to approach it
Say why autoscaling fails here before proposing anything, because the interviewer chose "database locks" and "reacts too slowly" deliberately. Then separate reads from writes, since they need opposite solutions.
A strong answer
The arithmetic first. A spike reaching 10x in under a minute against a scaling loop that needs two to five minutes to add capacity means the system is unprotected for the entire event. And the database is the component you cannot scale on that timescale at all, so any design that depends on the database absorbing 10x is already lost.
Reads: never reach the database. A flash sale is overwhelmingly reads on a small set of hot products. Cache the catalogue, the pricing and the inventory display in Redis, with the sale items pre-warmed before it opens. Put the static content and product images behind a CDN. The goal is that the origin sees a small fraction of the traffic, and the specific failure to prevent is cache stampede: when a hot key expires, thousands of requests miss simultaneously and all hit the database at once. Fix it with request coalescing (one miss fetches, the rest wait) and staggered TTLs rather than a single expiry.
Writes: queue them. Order placement does not need to be synchronous. Accept the request, write it to a durable queue (Kafka or SQS), return an acknowledgement, and let consumers drain into the database at whatever rate the database can sustain. The user gets "order received" immediately and a confirmation shortly after, which is how large sales actually work. Bound admission and queue age/capacity; acknowledgement means durably received, not confirmed stock. Reject or defer new work explicitly when the queue budget is exhausted.
Scale on the queue, not on CPU. Consumer count driven by queue depth through KEDA. Queue depth is a leading indicator that moves the instant load arrives, whereas CPU is a lagging one that moves after the damage. This is the single most important configuration change in the answer.
Inventory is the hard part, and it is where the question gets interesting. Overselling a limited stock is a business failure and the naive fix (a database row lock per purchase) is exactly what is locking up. Options: use a conditional reservation that checks available stock and decrements only if sufficient, keyed by idempotent order ID. A Redis Lua script can make that check/update atomic on one primary, but ordinary async failover can lose acknowledged reservations. Strict no-oversell needs a durable authoritative reservation design and safe promotion; or pre-allocate stock into tokens and hand them out. Both accept a small reconciliation burden in exchange for not serialising every purchase on one row.
Then the things that are not scaling at all. Pre-warm before a sale whose start time you know, because scheduled capacity beats reactive scaling every time. Rate limit per user at the edge so one script cannot consume the sale. And shed load deliberately: if you must fail requests, fail browsing before checkout, and return a queue position rather than an error.
What interviewers probe next
"What does the user see if the queue is deep?" A position or an estimated time, not a spinner and not a 500. Designing the degraded experience is part of the answer.
"How do you prevent overselling with the Redis counter?" DECR is atomic but can go negative. Check and decrement in one conditional transaction/script, deduplicate order IDs and expire/release reservations deliberately. Async Redis failover can lose reservations, so reconciliation detects a mismatch but does not retroactively guarantee no overselling.
"Would you scale the database?" Read replicas for reads, yes. For writes you are buying a bigger instance in advance, which is a capacity decision made days earlier, not during the sale.
Common mistakes
Answering "autoscaling and caching" without noticing that autoscaling cannot react in time.
Leaving writes synchronous, which means the database still absorbs the spike.
Ignoring inventory correctness, which is the one thing the business will not forgive.
References