[bilekas]

> I think a good stack to use is:

These things are relative though, also futureproofing your stack will run into issues later if you need to scale to N number of requests etc.

When you are thinking forward for optimizations, you may re-evaluate your thoughts on the right stack.

[KronisLV]

> When you are thinking forward for optimizations, you may re-evaluate your thoughts on the right stack.

Most projects never get there and even the ones that survive would be well served by a single EC2 instance.

Nothing about that stack jumps out as that problematic, maybe go with a PostgreSQL instance running in a container if need be, but the rest can scale pretty well both horizontally and vertically.

If it becomes a problem then just throw some more money at resources to fix it and if at some point the sums get so substantial that it feels bad to do that, congratulations, you’ve made it far enough to rework your architecture.

[Brian_K_White]

And in the mean time, enjoy life for 20 years.

I am perfectly glad for all the things I did not do when they were not needed.

Designing and building amphibian hovercraft monorail dumptruck racecars for all those projects that only ever needed a wheelbarrow is just a diffetent form of technical debt. It's not investment because it never pays off. It's just work that does not produce output, that you pay before instead of after.

It only takes a little bit of thought to avoid the normal idea of technical debt where past thoughtlessness costs you work today. Plain old modularity, seperation of concerns, avoiding tight coupling, and not even those religiously but just as a prefference or guiding direction, pretty much takes care of the future.