Ask HN: How do you prepare for “HN Hug of death”? | Hacker News Reader

Ask HN: How do you prepare for “HN Hug of death”?

6 points_44810 comments

When a "Show HN" post is created by an app developer, the obvious effect of that is a massive load on the backend server of the app, bringing down the server. I have read posts here on HN, where developers who were unprepared for this spike in server load experienced, what is now well known as, the "HN hug of death".

So how do you prepare for avoiding this fate before creating a "Show HN" post?

View on HN

For the frontend: put a CDN in front of it, add caching.

In my experience, most folks just want to see what the fuss is about, not so much make an account and start using the app. So as long as your post-login experience can take a few users simultaneously, you should be fine.

Caching/make the homepage static if possible. I had a project some years ago that had an elastic search backend, adding redis for caching allowed it to run without problems with up to 1000 concurrent users (position 1-10 on HN if I remember right). As someone below pointed out, the majority would want to have a look, not create accounts.

I use zola a static site generator and deploy the pages (for free) to cloudflare pages.

So there's no impact on my servers.

For a product you will get a lot of people from HN reading the landing page but relatively few registrations.

Autoscaling, available on most popular clouds/hosts

I should have added, "for a side-project, and on the cheap" :)

Make as much of the app static as possible. Run as much of the logic in the browser as possible.

Once you've isolated the "must be on the server" stuff, put an intelligent rate limit on it, add auto-scaling with upper limits, and prepare a page to be shown when the server goes down.

Highly dependent on your stack but there are plenty of free tiers for most serverless services. E.g. if you're willing to write everything in JS/TS then Vercel is a great option. (Kind of relevant to your post about adapting architecture to cost)

The problem with serverless is that the failure mode for traffic spikes is either "shockingly high bill" or "stops serving requests".

For high, sustained load, a running server is always cheaper, the cost is predictable, and the failure mode is usually "serving requests much more slowly".

AWS lambda seems dirt cheap, or am I mistaken?

It's not that hard to accidentally have a huge bill if you get overloaded with requests.

Reply on news.ycombinator.com