Nah, don't let that discourage you. You can probably start with a Postgres backend that will serve as your db, full text search, data warehouse, and even job queue. Load balancers in front of your stack are available from aws, etc. and are easy to set up. The rest, like a caching redis server, actual job queue, etc. you can add as you go if it becomes needed. Some language stacks let you run async operations and queues in the server itself which may be enough. There is no need for containers or complicated deployment processes. If you're on the JVM, for example, just create an uberjar and run that. Focus on things that actually bring value to your business and use the simplest, most minimal solution everywhere else. Don't give up on your idea because you feel overwhelmed. Good luck.

You've described the exact approach I've used for my B2B SaaS.

Initially we had a web server (two actually, to achieve zero-downtime deploys) and a database.

A few months later, we introduced Redis for caching. This was much earlier than I expected we'd need to - these days as soon as a web app gets traction, it starts attracting scammers, spammers, and manipulators who put unexpected load on your system.

Just this week, we've finally added a worker server to run long running tasks. Until this week, Java's brilliant Executors were handling this for us in a background thread.

A Java uberjar, deployed to AWS's Elastic Beanstalk, is an approach I'd highly recommend for anyone wanting to get version 1 of their web app deployed.

Was about to write this exact reply. A single database and web server goes surprisingly far.

If you have a reasonable idea of what you are doing.

Even if you don't, throwing some more hardware at it can still get you pretty far with a decent ROI in the early stages.

thanks for the advice - yes I'm on the JVM w/ spring boot.

I suppose I may be overcomplicating things with trying to do it "the right way" right out of the gate. I guess the "perfect is the enemy of done" saying comes into play here.

Experiment with abstracting the shit out of RabbitMQ to solve any business logic problem. I'm in a different CS field than web development but whenever I've had to implement something business related it almost always was just highly abstract message brokering with React hacked together UI. I learned UI from reading lecture notes on 'Human Computer Interface' design from the plenty of university courses around offering this subject http://www.cs.cmu.edu/~bam/uicourse/05863fall17/schedule.htm...

For learning web app APIs all I did was search Google Scholar for 'API design' and read whatever was available. Joshua Bloch has a good paper on API design. As for scaling, containers, concurrency ect look at Elixir w/Phoenix framework instead, or Erlang w/Yaws and just run it on a cheap FreeBSD comanaged box or deploy Phoenix to Heroku. BEAM will take care of the scaling. There's books around https://pragprog.com/book/lhelph/functional-web-development-...