[Negitivefrags]

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.

[vemv]

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.

[manigandham]

"workers" are application level architecture decisions, not machine/server level. If you need to (which most webapps dont) then do so.