Answer with a specific component and a reason, not a general statement about scaling.
Reason through the tiers in order:
- Stateless app tier - does not break first. Add instances behind the load balancer; it scales linearly.
- Database writes - usually the true answer. A single primary is a hard ceiling that you cannot scale out of without sharding. Say "the write path to the primary breaks first, at roughly X thousand writes per second."
- Database connections - often breaks even earlier than write throughput. Each instance holds a pool, so 10x instances means 10x connections and Postgres struggles in the low thousands. Fix with PgBouncer.
- Cache capacity and hit rate - a working set that grows past RAM causes the hit rate to collapse, which multiplies database load non-linearly. This is a nasty cliff, not a gentle slope.
- Hot partitions - traffic is never uniform. At 10x, a celebrity or a popular key saturates one shard while others idle.
- A shared downstream - a third-party API with a fixed rate limit, or a single auth service.
Then give the fix and its cost: "I would add read replicas to buy 5x on reads, but writes need sharding by user ID, which costs me cross-user transactions."
The strongest version names the metric to watch too: "I would alert on primary write latency and replication lag, because those degrade before they fail."