show hn hit the front page and my 1 vcpu box served 502s for two hours Traffic Spike

Two hours of 502s during your one moment of attention is the expensive part, not the $6.

Before the next post, load test it and find the breaking number instead of discovering it live. oha -z 30s -c 100 https://yoursite takes ten minutes to run and tells you exactly where the cliff is.

Then decouple: static marketing page on any CDN host, app behind auth on the box. Once those are separate a traffic spike physically cannot reach your database.

Your box did not fall over at 40 req/s. It fell over at 40 req/s of uncached, server-rendered HTML with a Postgres sharing its 1 GB of RAM. 40 req/s of static HTML out of nginx is nothing — that same box would do a few thousand.

The one change with the best ratio, by a mile: put the landing page behind a CDN with a real cache header.

Cache-Control: public, max-age=60, stale-while-revalidate=86400

A front page spike is 95% strangers hitting one URL. Cache that URL at the edge and your origin sees the other 5%.

Second change: cap the DB pool at something the machine can survive. max: 10, not 100. A bigger pool never makes a small box faster, it just moves where it collapses and makes the collapse unrecoverable.

Honest take: going down a bit is not the disaster it feels like at the time. People screenshot the error, it becomes part of the story, some of them come back. What actually costs you is not having an email capture on the page that stayed up. A static fallback with one input field beats a perfect app returning 502.

Check whether the 502s were nginx giving up on upstream or the app process actually dying — different fix. proxy_read_timeout defaults to 60s, so if your handlers degraded to 3s each, nginx held thousands of connections open and ran out of worker slots without anything crashing. Your logs and dmesg will settle it in a minute.

Scale up before you post and scale back after. A $6 box is $6 for a reason. Four gigs for one week is single-digit dollars. There is no prize for surviving your launch on the smallest instance available.

Serverless would have absorbed this without any capacity planning at all. Worth considering before the next one.