A video conferencing product grows from 10 million to 300 million daily participants in ten weeks. No feature request changed. Which part of the architecture is under threat first, and why?

What is being tested

Whether you can separate requirements from constraints, and recognise that hypergrowth is almost never a functional-requirements event.

The reasoning

Nothing about what the product does changed. What changed is a single number — concurrent participants — and that number was an input to almost every structural decision made previously: how much data-centre capacity to pre-provision, how many media relay points to run and where, how much headroom to keep before a region saturates, how many vendors to depend on for edge capacity, and how quickly new capacity can be brought online.

Each of those decisions was correct at the old number. None of them are wrong in a way you could have caught by re-reading the specification, because the specification never mentioned them.

This is the practical meaning of "requirements become constraints". The requirement "people can join a meeting" is stable. The constraint "up to N concurrent participants, joining within 2 seconds, from anywhere" is what the architecture was actually built against, and it silently expired.

What actually breaks, in order

1. Capacity that cannot be added fast enough. Physical capacity — servers, transit, peering — has a lead time measured in weeks. Software autoscaling does not help when the underlying fleet is finite.
2. Concentration risk. A dependency that was fine at 5% of capacity becomes a systemic single point at 90%.
3. Assumptions embedded in defaults. Connection pool sizes, shard counts, partition counts, ID ranges, rate limits — all set from an obsolete volume figure and all invisible until they bind.
4. Operational processes. Anything that required a human step at the old volume becomes the bottleneck at the new one.

The lesson for design reviews

Write the volume assumption next to every capacity decision, so it is obvious which decisions are invalidated when the number moves. "We run three regions because peak concurrent is X" ages far better than "we run three regions".

A weaker answer

Blaming the language or the database engine. Those are occasionally the binding constraint, but they are never the first thing to bind during a step-change in demand, and reaching for them signals that you are pattern-matching on scaling folklore rather than reasoning about the system.