+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Surviving the festive peak

Cloud By Mits Engineering Team 2 min read
Surviving the festive peak

Indian consumer businesses do not have a smooth annual curve. They have a handful of days — the festive sale window, a big cricket fixture, a payday, a campaign launch — where traffic is a multiple of normal and arrives in minutes rather than hours. That shape defeats the standard advice, because autoscaling responds to load that has already arrived, and by the time capacity appears the queue has built and the first thousand customers have seen an error page.

Start by knowing the multiple rather than guessing it. Look at last year's peak against last year's ordinary day, and at the peak minute rather than the peak hour — the two differ by a lot and the minute is what breaks things. If the business is planning a campaign, ask marketing what they are actually buying and when the email lands, because that is your arrival curve and they usually know it to the hour.

Then find the constraint before the day, by testing at the expected multiple with a realistic traffic mix against realistic data volumes. It is almost never the web tier, which is the easy thing to add. It is the database connection pool, a third-party API with its own rate limit, a queue whose consumers do not scale, a report query that competes with checkout, or a cache that cannot be warmed fast enough after a restart. Each of those has a different remedy and none of them is add more servers.

Pre-scale rather than autoscale for the known window. Provision ahead of the event, warm the caches, and hold that capacity through the peak. It costs money for a day and it is insurance against the failure mode where scaling begins after the damage. Autoscaling is right for unpredictable growth; a sale starting at midnight is entirely predictable, and treating it as a surprise is a choice.

Decide in advance what you will turn off. Under real pressure, the ability to shed load deliberately is worth more than any amount of extra capacity: recommendations, personalisation, non-essential analytics, real-time dashboards, heavy search facets. Put each behind a flag before the day so the decision is a toggle rather than a deployment. A checkout that works without personalisation is a business; a personalised site that cannot take orders is not.

And plan the rest of the business around the same window. A freeze on deployments and infrastructure changes for the days on either side. Extra people rostered, including someone senior who can make a call without escalating. Support briefed on what to say if something fails. Vendors and payment providers told what volume to expect, because they have capacity limits too and are considerably more helpful when warned than when surprised.

Need help with this? Explore our Cloud Solutions & Migration services. Learn more Back to all news

Keep reading

More on Cloud