Has nothing to do with Digital Ocean, and everything to do with how the website is designed (which is often, but not always, a function of what framework was used).

Stick a properly configured nginx or Varnish in front of whatever they're running, and we'd not be having this conversation.

Even then, since the cache-control headers are not being set correctly, it would all just by-pass nginx or Varnish anyway.

Thus "properly configured". However, I actually just look, and at least now, they in fact appear to be setting etags properly, so their HTTP server is returning a 304 on all the static files being served from their domain, despite max-age being set to 0, and the rest of the static files are on CDNs.

That said, nginx caching proxy or Varnish would still be a dramatic help in front of the couchdb instance they're using for their API (since their data isn't constantly being updated, they could do this).

Making a wild-ass guess, I'd say they were running the couchdb on the same droplet as their static file server, and with no caching, the couchdb instance pegged the CPU, causing the HTTP server to fail.

I've used jmeter to load test for cheap. You can spin up a VM and hammer a site pretty good.

The problem isn't going to be that it's on DO; the problem is going to be that whatever they're using isn't proxied or optimized to handle the kind of load you get when you're on the HN front page.