A single server and a database is enough here

Ten years ago a system design conversation was short. A server, a monolith, Postgres, maybe a load balancer in front. For most products that was the entire architecture, and it held.

Now the same conversation opens with API gateways and doesn’t stop: Kubernetes, service meshes, Kafka, Redis, three databases because each one is good at one thing, gRPC, GraphQL, Elasticsearch, Terraform, Prometheus, tracing, sharding, replication, autoscaling.

The awkward part is that none of it is junk. Every one of those tools exists because someone hit a real wall: more users, more data, more teams, more regions, more nines of uptime.

So the problem isn’t the tools. It’s that we reach for them before asking anything about the problem.

What scale are we actually designing for? Where is the bottleneck today, not in the imagined future? What genuinely needs strong consistency? What can be cached? What breaks when this service goes down? And the question that almost never comes up in a design review: can this team operate what we’re about to build, at 3am, on call, a year from now?

The strongest engineers I’ve worked with know distributed systems cold. That’s exactly why they’re comfortable saying “a single server and a database is enough here” without feeling like they’re underselling themselves.