A merch drop that stays up: infrastructure that survives a viral tweet

You tweeted: "drop is live." Within 15 minutes, 30,000 people had clicked the link. At 18 minutes, the page was down. By 25 minutes, you were in the builder's support DMs explaining what happened while your audience roasted you in the replies.

Viral drops are almost always a mix of timing + a warmed-up audience + a bit of luck. But the infrastructure that survives the spike isn't luck — it's a decision made in advance. This article is about the decisions that separate a drop that sells out from a drop that becomes a meme.

Why generic builders go down

First things first: you didn't do anything wrong by picking a platform. Wix, Webflow, Shopify, course-creator page builders — they all work great for normal traffic. The problem is specific to the viral spike.

Three things tend to break at the same time when a tweet takes off:

1. The origin server saturates. A builder hosts many stores on the same cluster. When yours spikes, you're competing with your neighbors for infrastructure. The platform's response: "we're investigating" — but the drop doesn't wait.

2. The payment provider starts declining. Stripe, PayPal, Hotmart, Pix gateways (Pix is Brazil's instant payment system) — they all have rate limits. A drop with 30k people in 5 minutes trips anti-fraud rules and the gateway starts declining valid transactions. You don't see it — you just see a high CTR and low conversion.

3. The builder's CDN doesn't cache aggressively. The page makes 2-3 dynamic calls (updated price, current stock, regional banner) that have to hit the server on every visit. At 1,000 simultaneous visits, a queue forms and everything slows down.

The combination of all three is what produces the "is it down?" in your DMs.

The 3 factors that kill a page under a spike

In order of impact:

1. Cache. If every visit has to go all the way to the server to render, you're vulnerable. A drop page should be almost 100% static — pre-rendered and served from a CDN. Anything that needs to be dynamic (stock, price) goes through a separate call, in a layer that can scale independently.

2. Payment provider. You need to understand your gateway's TPS (transactions per second) limit. Stripe allows ~100 TPS on a standard account; Pix has per-bank limits. For big drops, you need to request a limit increase in advance or queue the checkout.

3. DNS and propagation. If you bought your domain last week and set up DNS the day before, brace yourself: it can take up to 48h to propagate globally. On drop day, part of your audience will resolve to the old IP and nothing will work for them. Get it sorted at least 1 week ahead.

What changes with 10k people at once

To make it concrete, some real numbers:

• At 1k visits/min, any decent infrastructure holds up. Don't worry about it.
• At 5k visits/min, generic builders start to degrade. Latency climbs from 200ms to 2s. Conversion drops because mobile times out.
• At 10k visits/min, generic builders go down completely. You need an architecture designed for scale.
• At 30k+ visits/min, even a well-designed architecture will struggle if you haven't set up a queue in the checkout layer.

Most creators overestimate or underestimate this number. They underestimate it when the channel grows very fast. They overestimate it when they trust "paid ads get a 2% CTR." Use the engagement history of your previous drops as a baseline — multiply by 3 if you ran paid ads, by 5 if a bigger influencer mentioned you, by 10 if it went viral organically.

Minimum infrastructure checklist

For a drop page that needs to survive a spike, the absolute minimum:

1. A static page served from a CDN. Vercel, Cloudflare Pages, Netlify — any of them can handle a viral spike because the page itself sits in edge cache. The click-through traffic never touches your server.

2. Separate, cached dynamic calls. Current stock/price via an API with a 10-30s cache (not real-time). You give up pinpoint precision in exchange for not going down.

3. A checkout queue. If you're using Hotmart/Kiwify/Stripe, you don't need to do anything — they have an internal queue. If you run your own checkout, consider queuing (Cloudflare Queues, Redis Streams, or services like Shopify Hydrogen).

4. Real-time monitoring. During the drop you need to see: latency, error rate, conversion rate, requests per second. Datadog, Vercel Analytics, or even Cloudflare Analytics' free tier will do. Without it, you're guessing.

5. A graceful degradation plan. If something goes down, what do you switch off first? The regional banner? Product recommendations? Comments? Decide beforehand — during the drop you won't have the headspace to decide.

6. A domain fallback. Keep a backup subdomain (drop.yourname.com) pointing to different infrastructure. If the main domain goes down, you tweet the backup in 30 seconds.

7. Load testing ahead of time. Run a simulator (k6, Loader.io) generating 5x the traffic you expect, 1 week before. If the page holds up, you sleep well. If not, you have time to fix it.

Hosting: Vercel vs Netlify vs Cloudflare

Real talk:

• Vercel — best DX, native Next.js integration, global edge functions. Expensive under spikes (billed per function invocation). Recommended if your stack is Next and you want simplicity.
• Cloudflare Pages + Workers — cheaper under spikes, global edge functions with a more predictable billing model. Steeper learning curve. Recommended if you expect very high traffic on a recurring basis.
• Netlify — the middle ground. Good for purely static projects. Function pricing is less friendly under spikes.

For an occasional drop (1-2 per quarter), Vercel is the lowest-friction path. For a creator who drops every week, Cloudflare starts to make financial sense.

Mitigation plan if something goes down

A viral drop will have an incident. It's not "if," it's "when." What separates drama from an incident:

1. A static "back in 5 minutes" page ready to deploy in 30 seconds. Almost no creator has this. It costs 1 hour of prep work and saves the launch.
2. Prepared communication — tweet, story, and Discord message written in advance. "I'm on it, back in 10 minutes with an update." Audiences forgive mistakes; they don't forgive silence.
3. A backup checkout — a link to Hotmart/Kiwify/an external store you can send manually if the main checkout goes down. It's not elegant, but it converts.
4. A designated triage person — it can't be just you monitoring everything. Assign someone on the team to answer DMs and Twitter while you decide what to do technically.

TL;DR

A drop page needs to be almost static (pre-rendered, served from a CDN), with cached dynamic calls and checkout on a robust platform. Generic builders handle normal traffic but degrade under a viral spike. The costs that matter aren't just hosting — they're the cost of not having the infrastructure: a drop that goes down becomes a meme, the audience burns out, the brand gets forgotten.

If you have an important drop coming up and want to make sure the infrastructure holds, tell us about it. We evaluate it within 24h and reply with a specific plan. Ideally, give us at least 2 weeks' notice — not 2 days.

Frequently asked questions

Why does a drop page built on a generic site builder go down under a traffic spike?

Generic builders render the page on the server on every visit, so each person who arrives becomes server work. Under normal traffic nobody notices; in a viral spike the render queue overflows and the page degrades. A drop page has to be prerendered and served from a CDN, where the click never touches your server.

What is the minimum infrastructure for a drop page to survive a spike?

Seven items: a static page served from a CDN; dynamic calls split out and cached for 10 to 30 seconds; a checkout queue (Hotmart, Kiwify and Stripe already have one built in); real-time monitoring of latency, errors and conversion; a graceful degradation plan defined before the drop; a fallback subdomain pointing to different infrastructure; and a load test at 5x the expected traffic one week before.

Vercel, Netlify or Cloudflare for a drop page?

For occasional drops (1 or 2 per quarter), Vercel is the lowest-friction path, especially if the stack is already Next.js. For a creator who drops every week, Cloudflare Pages + Workers starts to make financial sense because billing is more predictable under spikes. Netlify sits in the middle, good for purely static projects.

How far ahead should I prepare the infrastructure for a drop?

At least 2 weeks ahead, not 2 days. That lead time is what lets you run a load test with room to fix whatever shows up, have the maintenance page ready to deploy in 30 seconds, and write the incident message before you need it.