# How to Survive a Traffic Spike When Your Architecture Wasn't Built for It
Handling a traffic spike startup teams are never fully prepared for - that is the story of nearly every scaling incident I have seen. The company gets featured in a major publication, a tweet goes viral, a big customer runs an email campaign, and suddenly the system that handles 1,000 requests per hour is being asked to handle 50,000.
I got a call at 11pm on a Tuesday from a founder whose product had just been featured in a major tech newsletter. Their site was down. Completely. The team was in a panic. Forty thousand new visitors had shown up in 90 minutes and the server had simply fallen over.
Over the next six hours, we implemented emergency stabilization measures that got the site back up and handling the remaining traffic. Two days later, once the immediate crisis was past, we did a proper scaling review.
This article is both the emergency playbook and the preparation guide - what to do when you are in the middle of a traffic spike, and how to make sure you are not in crisis mode the next time it happens.
The Emergency Playbook: First 30 Minutes
If your product is down or severely degraded due to traffic, these are the actions that typically provide the fastest relief.
Identify the bottleneck. Traffic spikes kill systems in specific ways. Usually it is one of three things: the web servers are overloaded, the database is overloaded, or a third-party service you depend on is overwhelmed by the sudden call volume. You need to identify which one is the problem before you can fix it.
Most cloud providers have monitoring dashboards that show CPU, memory, and network utilization in near-real-time. If web server CPU is at 100%, the problem is compute. If database CPU is at 100% or connections are maxed out, the problem is the database. If the servers are fine but requests are failing, check your external service status pages.
Scale the compute layer. If the web servers are the bottleneck, adding more server capacity is the fastest mitigation. Every major cloud provider (AWS, GCP, Azure, Render, Fly.io) allows you to increase server capacity in minutes. If you are on auto-scaling, increase the maximum instance count. If you are on fixed capacity, scale up the instance size or add instances manually.
This does not fix root causes, but it buys time. A traffic spike is usually temporary. If you can get through the peak, you can do proper optimization afterward.
Enable any caching that is not already running. If your application has caching capabilities that are disabled or only partially configured, enabling them during a traffic spike can dramatically reduce database load. Even unsophisticated caching - caching the most-requested pages or API responses for 60 seconds - can cut database load by 60-80% if your traffic pattern involves many users requesting the same data.
Enable a static fallback if your product has one. If you have a static version of your homepage or a landing page that does not require database calls, routing traffic there during the spike keeps something available for new visitors while you stabilize the dynamic parts of the application.
Communicate. While the technical response is underway, put up a status page or social media post acknowledging the issue. Users who see that the team is aware and working on it are more forgiving than users who encounter silence. This is not just PR - it reduces support ticket volume that would otherwise consume team attention during the incident.
The Next Two Hours: Triage and Targeted Mitigation
Once you have stabilized the immediate crisis, you have time for more targeted interventions.
Database connection pooling. If the database was the bottleneck, connection pooling is often the fastest meaningful fix. Most applications open a new database connection for each request. Under high load, this exhausts the maximum number of database connections. Connection pooling reuses existing connections, dramatically increasing the number of concurrent requests your database can serve.
Tools like PgBouncer (for PostgreSQL) can be set up in an hour and typically provide a 3-5x improvement in how many concurrent connections your database can handle without increasing database size.
Disable or rate-limit expensive features. Under spike conditions, some features that work fine under normal load are significantly more expensive than others. Search functionality that does complex full-text queries, report generation that aggregates large datasets, and features that require multiple sequential database calls are often the highest cost-per-request operations.
Temporarily disabling or rate-limiting these features - returning an "unavailable" message during peak load - allows your infrastructure to handle more of the simple, inexpensive requests that most users actually need.
Increase database instance size temporarily. If database CPU is pegged at 100% and adding more connections is not helping, upgrading the database instance size (more CPU, more memory) is often the fastest relief. This costs more money per month but is reversible - you can scale back down after the spike passes. Most cloud databases can be resized in 5-10 minutes.
The Post-Spike Architectural Review
The actual incident is the worst time to think clearly about architecture. Do it three days later, after sleep has been restored. The questions to answer:
What was the actual bottleneck? Not what you guessed during the crisis - what do the monitoring data and logs show was actually the limiting factor?
What would a 10x traffic spike look like? If the incident was a 5x spike, design for a 10x spike as your baseline capacity. This gives you a safety margin.
Where are your single points of failure? If your architecture requires any single component to be available for the product to function - a single database server, a single API service, a single caching layer - each of those is a failure point that a traffic spike can expose.
What can you cache? The most effective scaling improvement for most startups is adding caching for data that many users read but that changes infrequently. Profile pages, product listings, configuration data - these are often read thousands of times per hour but updated rarely. Caching them reduces database load dramatically.
Can your application run on multiple servers simultaneously? If your app stores session state locally, uses in-memory caches that are not shared, or does anything that assumes a single server, it cannot scale horizontally - which means adding more servers does not help. Making applications stateless (storing state in Redis or a database rather than on the server) is a prerequisite for horizontal scaling.
Preparation Is the Real Answer
No emergency response makes up for preparation. The startups that handle traffic spikes gracefully are the ones that thought about scaling before the spike happened, not during it.
The specific preparations that have the highest return on investment:
Load testing. Run an artificial load test against your staging environment that simulates 5x your expected peak traffic. This will show you exactly where the system breaks before it breaks in production with real users watching. Tools like k6, Locust, and Artillery make this accessible to any engineering team.
Auto-scaling configuration. Major cloud providers support auto-scaling - automatically adding server capacity when CPU or traffic exceeds a threshold. Configuring this correctly takes a few hours and provides automatic relief when spikes happen, without requiring anyone to manually intervene.
Database read replicas. Setting up a read replica - a copy of your database that handles read traffic - doubles your database capacity for most applications (which are read-heavy) and provides redundancy if the primary database fails.
Status page. Set up a status page (Statuspage.io or BetterUptime) before you need it. Having a public place to communicate during incidents is invaluable, and setting it up during a crisis adds unnecessary complexity to an already difficult situation.
Runbook documentation. Write down the specific steps your team should take during a traffic spike before it happens. Include the commands, the dashboards to check, the escalation contacts. A written runbook used in a crisis is worth ten times its weight in engineering hours spent improvising under pressure.
The traffic spike you have not prepared for will always come at the worst possible time - Friday evening, product launch day, after a major press hit. The preparation you do in calm periods is what determines whether it is a memorable growth moment or an embarrassing outage.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr