What breaks in a mobile app between 1,000 and 100,000 users

01Traffic arrives in spikes you created

Push notifications produce the sharpest load pattern most backends ever see. Sending to a large audience means a substantial fraction of recipients open the app within a minute or two, all hitting the same endpoints simultaneously.

This routinely takes down backends that handle steady-state load comfortably. The fix is to stagger sends rather than to scale for the peak; a campaign delivered over fifteen minutes produces a fraction of the peak load with no meaningful difference to users.

The same applies to any scheduled behaviour in the app. A refresh timer on a fixed schedule synchronises every client; adding jitter turns a spike into a plateau and is a one-line change.

02The device long tail arrives

At small scale your users are on devices similar to your team's. At a hundred thousand, you have users on five-year-old hardware, on OS versions you stopped testing, with full storage and poor connectivity.

This is where crash reports diversify suddenly - low-memory terminations, storage write failures, and timeouts that never appeared in testing. None are new bugs; they were always there and lacked the population to surface.

Segment your monitoring by device tier and OS version from the start. An aggregate crash rate that stays flat while the worst segment triples is a common and misleading picture.

• Add jitter to every client-side timer and scheduled refresh.
• Stagger push campaigns rather than provisioning for the resulting spike.
• Test on a low-memory device and with storage nearly full; both produce failures nothing else reveals.
• Set client timeouts deliberately and handle them, because a slow network is far more common than a failing one.
• Monitor by OS version and device tier, not only in aggregate.

03Old versions become a real constraint

By this scale you have a meaningful population on versions from a year ago, and their assumptions are frozen. An API change safe for current clients can break them, and you will not find out until support tickets arrive from users you cannot easily identify.

Track active users by app version continuously. That number decides whether you can change an endpoint, and it is the input to any deprecation decision.

This is when a forced-upgrade mechanism stops being theoretical. Without one, your oldest supported version is whatever your least-updated user has.

04Where the cost lands

Infrastructure cost per user usually falls with scale; support cost per user does not, and mobile support is expensive because reproduction is hard.

Investing in diagnostic capability - session context on errors, the ability to see what a specific user's app did - pays for itself quickly here. Without it, every ticket is a guess, and the volume of guesses grows with your user base.