Zoom's daily meeting participants rose from roughly 10 million in December 2019 to about 300 million by April 2020. Consider a conferencing product in that position whose team responds by autoscaling the signalling tier - the services that handle joining a meeting - fourfold. What happens over the following weeks, and which constraint was actually binding?

What happens, step by step

Week one: joins get faster and meetings get worse. The signalling tier was never the bottleneck; it handles a burst of short requests at the start of a meeting. Scaling it removes queueing at join time, so more participants reach the media path per minute. The dashboards the team watches improve.

Week two: complaints are about quality, not availability. Audio drops, video freezes, the meeting "works" but is unusable. Error rates stay flat because none of this produces an error. The media relay is the binding constraint, and it fails by degrading rather than by refusing.

Week three: the team finds the cost line. Media relaying consumes egress bandwidth per participant per second, continuously, for the duration of the meeting. Signalling consumes a few requests per participant per meeting. The two scale on completely different axes, and the one the team scaled was the cheap one.

Why the media path is the real constraint

Signalling load is proportional to meeting starts; media load is proportional to participant-minutes. A tenfold rise in participants with longer meetings can be a thirtyfold rise in participant-minutes. Those minutes land on relay capacity, which is bounded by three things that autoscaling does not fix quickly: egress bandwidth at each point of presence, physical server capacity in the regions where participants actually are, and the number of concurrent streams one relay process can mix or forward.

Bandwidth is the hard floor. A selective-forwarding relay sending one video stream of a few hundred kilobits per second to each of twenty participants moves several megabits per second for one meeting. Multiply by concurrent meetings and the number is a contracted capacity at a facility, not a scaling group. You cannot autoscale a transit contract, and the lead time is weeks to months.

What the user sees

Not an error page. Packet loss, so the codec drops to a lower bitrate and the picture softens; jitter, so audio stutters; and relays reached over a longer path because the nearest one is full, so one-way latency crosses the threshold where people start talking over each other. Every one of these is invisible to availability monitoring, which is why the team's own metrics said the scaling had worked.

What stops it

Admission control on the resource that is actually scarce. Cap concurrent participants per relay and per region, and reject or redirect at join time rather than degrading everyone already in a meeting. A meeting that cannot start is a worse experience for one person; a relay at 110% is a worse experience for everyone on it.

Capability-graded degradation, decided in advance. Drop the highest video layer first, then video for non-speakers, then video entirely, and never audio. That ordering is a business decision and it must exist before the week it is needed.

Capacity planning in participant-minutes and egress gigabits, with lead time attached to each. Compute can be bought in minutes, bandwidth in weeks, hardware in regions in months. A capacity plan that does not record the lead time of each constraint is a list, not a plan.

When this is the wrong diagnosis

When the load is dominated by joins rather than by duration: a webinar product where 50,000 people join inside 60 seconds and most leave within two minutes. There the thundering herd at the join path is the whole problem, and the right answers are the opposite ones — pre-warmed capacity, token bucket pacing on joins, and a staggered join window. Which tier binds is a property of the traffic shape, not of the product category.