Peak Seasons Aren’t Just November: A UK Capacity-Planning Routine for App Teams

Every UK app team has a peak-season story. Sometimes it is a retail launch. Sometimes it is a bank holiday weekend when everyone tries to book, check in, claim or buy at once. Sometimes it is payday, a heatwave, a train strike or a sporting event that sends a completely unplanned crowd through the app.

The common thread is that the spike was not in the analytics. Or it was there, but buried under an average. Capacity planning is not about predicting one big day. It is about building a routine that finds the awkward peaks, tests them honestly and turns the aftermath into better decisions for the 2026 roadmap.

Your analytics has a calendar blind spot

Most dashboards are good at showing what happened. They are less good at showing what almost happened, or what would have happened if the app had stayed up. A crash can make a spike look like a quiet day because users never completed the journey. A queue can hide demand. A failed payment can turn a busy period into a support ticket instead of a transaction.

Start by building a spike calendar, not a single peak day. Include paydays, bank holidays, school half-terms, summer staycations, major sporting fixtures, retail promotions, weather triggers and any local events that matter to your users. Add the dates when your own marketing or partner campaigns go live. Then mark which ones are read-heavy, write-heavy or payment-heavy. A queue of people checking opening times is a different problem from a queue of people trying to buy.

Load test the shape, not just the number

A load test that says 'we handled 10,000 users' is not very useful if it does not match the shape of the real spike. Test the ramp, the mix of journeys, the ratio of logged-in to anonymous users, the third-party calls and the retry behaviour. If your app talks to a payment provider, an identity service or a stock system, load those dependencies too, or at least simulate their latency and failure modes.

Run one test against the expected peak and one against a nasty version of it: a slower database, a flaky third-party API, a burst of retries. The second test is often where the real lessons are. It also gives you a baseline for the post-spike review, so you can compare what you planned with what actually happened.

Queues are a feature, not a failure

When demand outruns capacity, a queue can be kinder than a crash. But only if it is designed. Decide where the queue sits, how users are told, how long they might wait and what they can do in the meantime. A queue that silently spins is worse than a clear message that says 'we are busy, here is your place'.

Use admission control and backpressure to protect the core service. Make background jobs asynchronous where possible. Add idempotency so a retry does not create a duplicate order. Set fair rate limits and make sure your support team knows what a queue message means. If you are running a promotion, tell users what to expect before they tap.

Graceful degradation with a business brain

Not every feature deserves the same protection. During a spike, you might keep login, basket and payment alive while turning off recommendations, reviews or a live activity feed. That is a business decision as much as an engineering one. Write it down in advance: what can be read-only, what can be delayed, what can be cached, what can be switched off and who gets to make the call.

Feature flags are your friend here, but only if they are tested. A flag that has never been used under load is a rumour, not a control. Include the degraded modes in your load tests and make sure the status page, in-app messaging and support scripts match what users will actually see.

Cloud-cost guardrails

Autoscaling can save a launch and ruin a monthly budget if nobody sets limits. Put budgets and anomaly alerts in place before the peak. Set maximum instance counts, review warm pools and reserved capacity, and know which workloads are allowed to scale first. Model the cost per order or per booking at peak, not just the average. A spike that works technically but destroys unit economics is still a problem.

Also watch the quiet costs: logging, image processing, third-party API calls and data transfer. They often scale with traffic in ways teams forget. A cost guardrail is not about being stingy. It is about making the trade-off visible while you still have time to choose.

The post-spike review that earns its keep

After the bank holiday or payday rush, resist the urge to close the incident and move on. Run a short review with product, engineering, support and finance. What was the timeline? Which SLOs were breached? Where did users drop out? What did support hear? What did the load test miss? What did the cloud bill do?

Turn the answers into a small number of roadmap actions: a queue improvement, a caching change, a support macro, a cost cap, a new load test scenario or a clearer degraded-mode plan. The point is not to produce a long document. The point is to make the next spike less exciting.

Put the routine on the roadmap

Capacity planning should not be a once-a-year panic. Put a quarterly drill in the calendar, give it an owner and keep the spike calendar alive as campaigns and events are confirmed. The UK app market is full of odd little peaks that never make it into the board deck. The teams that plan for them are the ones whose apps feel calm when everyone else is refreshing.