Zoom told investors that daily meeting participants rose from about 10 million in December 2019 to a peak above 300 million in April 2020. You own the browser client for a product facing that shape of growth. An interviewer asks what must already exist in the client architecture before the surge and what cannot be added during it. How do you answer?

What the interviewer is testing

Whether you know that the client is the one tier you cannot scale, patch or redeploy on demand. Server capacity is a purchasing and autoscaling problem with a lead time of hours. The code running in a user's tab was shipped weeks ago, and in a product with sessions measured in hours it will not reload during the event.

A candidate who answers with autoscaling groups has heard the word "surge" and not the word "client".

The clarifying questions that change the answer

• Is a session a page load or a multi-hour connection? A meeting client is the latter, so a deploy reaches almost nobody during the incident window.
• What share of users are on the browser client versus a native app? Native adds an app-store review delay and a much longer version tail.
• Does a remote configuration channel already exist in the shipped client, and what does it do when that service is overloaded? This is the question that separates a plan from a wish.
• What does one rung of degradation save per session, in server cost and in client CPU? Without that number the degradation ladder is unprioritised.

A strong answer's arc

What must already be in the shipped bundle:

• A remote configuration channel that fails safe. Cached last-good values on the client, a compiled-in default, and a short timeout. The first thing to buckle under 30x load is the service every client calls at start-up; if the flag system fails closed, it takes the product down with it.
• A degradation ladder that is already implemented and already exercised. Cap the number of video tiles rendered, drop to audio, lower render resolution, stop non-essential polling. Each rung flippable by config, each one shipped and tested, because you cannot write a rung during the surge.
• A telemetry sample rate that is itself a flag. At 30x volume a 100% real-user-monitoring sample becomes its own incident. Being able to drop to 1% without a release is what keeps you able to see.
• No fixed-interval polling. 300 million participants on a 30-second poll is roughly 10 million requests per second of pure heartbeat. Polling must be event-driven and must stop on document.hidden.
• Immutable hashed assets on a CDN, so the bundle itself is never part of the capacity problem, and a chunk retention policy so clients on last month's build can still resolve their lazy imports.

What cannot be added during: anything needing a client release, and in particular a new flag, because the flag only exists in the bundle nobody has.

Common weak answers

• "Autoscale the backend and add a queue." True, necessary, and not the question asked.
• "Ship a fix." Your users are mid-session on last month's bundle; the fix reaches them next week.
• "Add more CDN capacity." Static assets are rarely the constraint, and saying so suggests the candidate has not separated delivery from compute.
• "Use a service worker to force an update." Workable for page-load products and useless mid-session, and it introduces a cache you then have to reason about during an incident.

What a strong answer adds

Two things a senior candidate raises unprompted.

The degradation ladder is a product decision made in advance. Nobody approves turning video off at 2 a.m. The product owner agrees in writing, before the event, which rung is acceptable at which signal. Otherwise the mechanism exists and does not get used.

Check the noun in the capacity model. Zoom's April 2020 blog post initially described the figure as daily users and the company later corrected it to daily meeting participants — a person in five meetings is counted five times. A model built on the wrong noun is wrong by the average meetings per user. Capacity planning fails on definitions more often than on arithmetic.