

Ask HN: How do I prevent "Service Unavailable" on a Show HN? - soneca

This is all too common. A &quot;Show HN&quot; is a hit, but the server can&#x27;t stand the traffic.<p>I am planning a Show HN (hoping it is a hit) of a AWS hosted SaaS. What measures should I take to support all the traffic from HN?
======
Greatri
You could load test your website using a tool like blitz.io. Test for, say,
500 simultaneous users and see what happens :) Just don't get caught up in
premature optimization too much, I'd rather the website went down for a short
while than never hitting the front page at all.

~~~
antsar
Thanks for the blitz.io reference. I've been looking for a tool to load-test
some personal projects, and others I found didn't have a satisfactory free
tier.

------
dirktheman
AWS offers autoscaling for EC2 instances:
[http://aws.amazon.com/autoscaling/](http://aws.amazon.com/autoscaling/).
Additionally, use their Cloudfront (or CloudFlare, which offers better value
and is easier to set up) CDN. Looking forward to your launch!

------
cloudflare
You could use CloudFlare as a front end to take some of the load.

------
bmelton
Not all SaaS are equal. The answers for this question are extremely different
between Spotify and Basecamp, for example. The scaling path is rarely
identical for any two applications.

That said, there are common things that can be done, many of which have
already been mentioned.

For AWS, make sure that you have at least two EC2 instances running, and
they're configured to sit behind an elastic load balancer, then make sure that
autoscaling has been set up.

As dirktheman says, Make sure that you're sitting behind Cloudfront for
caching benefits. Also, make sure that your static files are all being hosted
appropriately on a static server (Nginx, Apache, etc) and not by the
application server.

Consider implementing memcache. This may or may not fit every applications,
but if you have some common queries that are likely to be hit during a traffic
spurt, having them resident in memory takes some of the load off of the
database, if there is one.

Assuming RDS, definitely be using Multi-AZ instances, and also consider
setting up read replicas. If your application is more likely to be read than
written to, read replicas are an easy way to ensure that the application will
still work for those writing to it (generally, paying customers) while
mitigating traffic spikes typically common to media blitzes. Also, having an
architecture that supports the easy addition of read replicas affords greater
scale-up-ability.

Above and beyond that, everything's pretty application-specific. If you wrote
the app in Rails, try to find a Rails-production-ready checklist. Same thing
if Django, Java, whatever.

Good luck.

