Hacker News new | ask | show | jobs
by vemv 3816 days ago
Dividing your architecture into separate components is not only needed for operating at scale (the "nice" problem to have), but for having high availability (or even decent performance) at all.

Depending on one's business, HA/performance may not matter that much, but personally my startup is having a 'proper' design from day 1 - downtime is not acceptable for my business model.

3 comments

Dividing your architecture into separate components will probably cause you more downtime and have much worse performance.

Less servers and components mean less things to break.

Grab a dedicated server and host your shit on it (have a DB replica because losing data sucks, but that is easy). You will be able to run like that for much longer than you probably suspect and the chance of downtime will be massively reduced.

Why? Because a single server has a very low chance of having anything going wrong.

Not only that, but there is a lot of overhead in performance when you split everything up into components. You will be surprised how many requests you can handle on a single inexpensive dedicated server when you haven't put too much effort into "architecture".

When you actually find yourself running out of headroom on that setup you will know much more about your application and it's requirements then you did at the start, so you will have a better idea of what to split out, and a better understanding of what parts of your app need more performance anyway.

Workers are a must for any minimally sophisticated web application. You cannot degrade HTTP response time (and whole app server performance) just because you are performing work synchronously before the request finishes.

Similarly, if the work you are performing has any value for your business, it must be retryable, and the queued items must be safely stored (i.e. don't use a single Redis server - use something distributed like SQS instead).

All of that calls for a 'proper' architecture. I'm not talking microservices or anything fancy - just a webapp/worker/db separation and the like. Which is exactly what dedicated server (or DigitalOcean) users tend to lack at early stages.

"workers" are application level architecture decisions, not machine/server level. If you need to (which most webapps dont) then do so.
I'm not disagreeing that in some cases it's true. But as someone who provides infrastructure for a great many businesses including startups, most everyone changes their tune when their server goes down.
That's entirely true. But maybe those startups which 'changed their tune' didn't have to worry about servers for N months, focusing in e.g. market fit and growth hacking instead. Lean Startup mode.

Personally I'm pretty confident about market-fit and expected growth even before the launch day of my startup.

But that's not the case, most times!

Mind me asking what you're doing?
A sophisticated crowdfunding-based service for a particular niche.