Handling Black Friday traffic

The Problem Statement

Interviewer: "Your e-commerce platform normally handles 500 requests per second. Black Friday is in two weeks, and you expect a 20-50x traffic spike at midnight. How do you prepare the system to stay up, and what do you do when it starts to buckle under load?"

This question tests three things: whether you think about preparation (not just reactive scaling), whether you understand graceful degradation (not just "add more servers"), and whether you have an operational mindset (runbooks, war rooms, rollback plans) in addition to an architectural one.

Most candidates jump straight to "horizontal scaling" and stop there. That answer misses 80% of the problem. The hard part of Black Friday is not adding servers. It is warming caches that are cold after scaling, pre-testing at realistic load, deciding what to degrade when things get rough, and having a minute-by-minute playbook so your on-call team is not improvising at 2 AM.

I like this question because it tests production readiness. Anyone can design a system on a whiteboard. Fewer people can explain how to prepare that system for a predictable but extreme event. The interviewer is looking for operational maturity: the candidate who says "I would also freeze deployments 48 hours before" instantly stands out.

Clarifying the Scenario

You: "Great question. Let me scope this before I lay out an approach."

You: "When you say 20-50x spike, is that sustained for hours, or a sharp peak at midnight that tapers off? The preparation strategy changes."

Interviewer: "Sharp peak at midnight, then sustained at about 10x for the next 6-8 hours."

You: "Got it. And is this a monolithic application or microservices?"

Interviewer: "Microservices. About 15 services, with a product catalog, cart, checkout, payment, and inventory as the critical path."

You: "Should I assume we are on a cloud provider with autoscaling capabilities, or bare metal?"

Interviewer: "Cloud. AWS or GCP. Autoscaling is available."

You: "Last thing: what is the acceptable degradation? Are we OK showing stale catalog data if it keeps checkout working?"

Interviewer: "Yes. Checkout must not go down. Everything else can degrade."

You: "OK. I will structure this in three phases: what we do in the two weeks before the event, what we do in the hours leading up to midnight, and what we do when load hits and things start to break."

My Approach

I break this into five parts:

1. Capacity planning and load testing: Establishing baseline metrics and testing at target load
2. Pre-warming: Preparing caches, connection pools, autoscaling groups, and DNS before the spike hits
3. Proactive and reactive autoscaling: Scaling up before midnight, letting autoscaling handle the tail
4. Graceful degradation: What to turn off, in what order, to protect the critical checkout path
5. The pre-event runbook: The operational playbook that keeps the on-call team coordinated

The key insight most people miss: the biggest Black Friday failures are not caused by too many requests. They are caused by cold caches, cold connection pools, and cold autoscaling. You add 20 new servers at midnight, and every one of them has empty caches. They all stampede the database. The database falls over. More servers made it worse, not better.

My mental model: think of Black Friday preparation like a restaurant expecting a 500-person wedding reception. You do not just add more tables. You prep the food (pre-warm caches), you hire extra staff and brief them the day before (pre-scale and runbook), you decide which menu items to cut if the kitchen gets overwhelmed (graceful degradation), and you have the manager's phone number ready in case the oven breaks (escalation plan).

Here are the numbers I would sketch in an interview:

The Architecture

Here is the full system under Black Friday load, showing the traffic path from user to database and the protection mechanisms at each layer:

Walk through the critical path: a user clicks "Buy Now" during Black Friday.

1. The request hits the CDN. Static assets (images, CSS, JS) are served from edge. Only the dynamic checkout API call reaches the origin.
2. The WAF checks rate limits. Bot traffic and DDoS are filtered. Legitimate requests pass to the load balancer.
3. The ALB routes to a pre-warmed API gateway instance. The instance already has warm connections to downstream services.
4. The checkout service writes the order to the primary database, decrements inventory atomically, and enqueues the confirmation email to SQS. It does NOT wait for the email to send.
5. The payment service calls the external payment gateway with aggressive timeouts (5 seconds). If the gateway is slow, the circuit breaker opens after 3 failures and returns a "try again" message instead of hanging.

The design principle: offload everything non-critical to async processing. Checkout writes the order and returns immediately. Email, analytics, inventory sync, and fraud checks happen via the queue. This keeps checkout latency under 2 seconds even at 50x load.

Pre-Warming and Proactive Scaling

This is the section most candidates miss entirely. Autoscaling is reactive: it detects high CPU, then adds servers, then those servers boot, then they start serving traffic. That cycle takes 3-5 minutes minimum. During a Black Friday spike, 3 minutes of overwhelmed servers means thousands of failed requests and abandoned carts.

The fix is proactive scaling: add the capacity before the load arrives.

Here is what each pre-warming step does and why it matters:

Cache warming (T-2h): Run a script that fetches the top 10,000 products, the homepage, the most common category pages, and the current deals page. This populates Redis and the CDN cache. Without this, the first 10,000 users each trigger a cache miss that hits the database. That stampede alone can kill the database before autoscaling even kicks in.

Connection pool warming (T-30m): New application instances start with empty connection pools. The first requests trigger connection establishment: TCP handshake, TLS negotiation, database authentication. Under high concurrency, hundreds of simultaneous connection attempts overwhelm the database's connection handler. Pre-warming sends synthetic requests to each new instance to establish connections before real traffic arrives.