I glanced at the two links you shared and I wouldn't call those architectures boring, in fact they're quite involved. "I personally can't even answer with confidence what a single reasonably fat server can handle" - this is too ambiguous of a question anyway, since it depends on the workload. HN still runs on a single server, for instance.

The good news is you should stop worrying about this stuff, and just build. You'll eventually run into bottlenecks and can address them then. That's how best learning happens anyways. Premature optimization is fun and intellectually stimulating, but rarely gets you closer to delivering value.

My rules of thumb for starting out:

  - Start with a monolith (microservices are great for certain problems, but it's very unlikely you'll have those problems in the beginning, and they add quite a bit of complexity)

  - Use a relational DB (same caveats as above for NoSQL, RDBMS can handle search well enough early on as well)

  - Use managed services as much as possible (cloud > managing your own hardware, RDS > managing your Postgres instance, etc). They typically have sensible defaults, provide greater security/scalability/availability, and let you focus on the product.

  - The fewer independent moving parts in your architecture and infrastructure, the better. Let the complexity add over time, as needed.