Black Friday falls on November 27 this year, and for many businesses the weeks around it decide the quarter. But peaks are not only a retail phenomenon. A product launch, a television mention, a grant announcement, an enrollment window or a well-timed press story can send a site ten times its normal traffic with a few hours' notice. The difference between a peak that becomes a good story and one that becomes an incident is almost entirely preparation, and the preparation is the same whether the peak is planned or not. This is how we get a site ready.
Know your numbers
Preparation starts with two figures: what normal looks like, and what the peak might look like. Normal comes from your analytics and our monitoring: requests per minute, page views per day, the pages that carry most of the load, and the response time at a typical busy hour. The peak is an estimate. Last year's figure, if you have one, multiplied by your growth. A campaign plan with expected reach. A conservative guess with a margin on top. We would rather prepare for three times the estimate than discover the estimate was low.
Knowing the numbers also tells you where the load will land. A campaign that drives people to one landing page and a checkout is a very different shape from a news story that sends them to the home page and the search box. Each shape has different bottlenecks, and each is prepared differently.
Caching does most of the work
A page that is the same for everyone should be built once and served many times. Drupal's caching layers, combined with a cache at the edge, mean that the vast majority of requests during a peak never reach PHP or the database at all. A site that is well cached can absorb a large multiple of its normal traffic with no change to its infrastructure, because most visitors are being served a copy that was rendered milliseconds ago.
The preparation work is making sure the important pages actually cache. A single personalized element, a badge that shows the visitor's name, a cart count rendered on the server, can make a whole page uncacheable. We audit the pages on the campaign path and move anything visitor-specific to a small component that loads separately, so the page itself stays shared. This is ordinary performance work; a peak simply makes its value visible.
Capacity for the part that cannot cache
Some requests are unique by nature: a search, a form submission, adding to a cart, checking out, logging in. These reach the application every time, and they are where capacity matters. On our managed platform, capacity is a setting rather than a purchase: PHP workers, memory and database resources are defined per environment and can be raised for the peak and lowered afterward. We measure headroom in the weeks before, and if the estimate calls for more, we schedule the increase for the day before the campaign, not the morning of.
Third-party services deserve the same attention. A payment provider, a stock service, an email sender or a shipping rate lookup that slows down under load will slow your checkout regardless of how fast your site is. We check their limits, confirm their own peak plans, and make sure that if one of them stalls, your site degrades gracefully rather than hanging.
Rehearse with a load test
Estimates are guesses until they are tested. A load test sends synthetic traffic at a staging environment that mirrors production, at the volume and shape of the expected peak, and records what happens. It finds the uncacheable page, the slow query and the third-party timeout while there is still time to fix them. It also produces a number: the traffic at which response times start to climb. Knowing that number turns the peak from a hope into a plan.
Freeze the things that do not need to change
The days before a peak are not the time to ship new features. We agree a change freeze with each client: from a set date until the peak has passed, only content changes and security fixes go live, and anything else waits. Deployments that do happen go out in the morning, with a rollback path confirmed. Campaign content is loaded and previewed in advance, scheduled to publish at the right moment, and checked on the actual devices people will use.
Regulatory preparation belongs in the same window. EU price reduction rules require that a discounted price be compared against the lowest price of the previous thirty days, which for a November 27 campaign means the reference prices are set by October 28. That is a content and commerce question, but it has a date, and it belongs in the plan.
Watch it live, and know what you would do
During the peak we watch the same dashboards we always watch, more closely. Response times, error rates, queue lengths, database load, and the business signals that matter for the campaign: orders per minute, form submissions, conversion. We agree in advance what we would do if a threshold is crossed: add capacity, disable a non-essential feature, switch a page to a static version, extend a cache lifetime. Having the list written down means decisions during the peak are quick and calm.
Afterward
When the peak has passed, we write down what happened: the actual traffic against the estimate, the headroom that remained, anything that surprised us, and what to change before the next one. Capacity goes back to normal levels. The freeze lifts. And the numbers become the starting point for next year's plan, which is how each peak gets easier than the last.
If you have a campaign or a season coming up and would like to be sure your site is ready for it, talk to us now rather than in November. Six weeks is comfortable. Two is possible. The morning of is when we would rather be watching dashboards than fixing things.