There's a prevailing wisdom in software development that you should always build for the future. Influenced by the giants of the tech world, teams often start new projects by asking, "How will this scale to millions of users?" This leads them down a path of intricate, distributed systems, adopting what one developer has aptly called FAANG architecture by default. The result is often a complex web of microservices, orchestrators, and cloud products designed to handle a theoretical future load, while the actual business may still be searching for its first hundred customers.

The Allure of Building for a Billion Users

This approach, while seemingly forward-thinking, puts the cart miles before the horse. It solves a problem the business doesn't have yet, and in doing so, introduces a host of very real, immediate problems: exorbitant costs, slow development velocity, and a high degree of complexity that makes iteration and pivots incredibly difficult. The alternative, as argued in the original post and echoed throughout the developer community, is to delay paying the cost of a distributed architecture for as long as possible by embracing a simpler, more pragmatic starting point: the well-structured monolith.

The Community Weighs In on Over-Engineering

The call for simpler architecture resonated deeply within the engineering community. In a spirited discussion on Hacker News, developers and consultants shared their experiences, confirming that the obsession with scalability is not just a theoretical concern but a widespread practical problem causing tangible harm.

When Your CV Drives the Architecture

One of the most prominent themes to emerge was the concept of "CV-driven development." The article posits that engineers want a "fashionable CV" that will land them their next job, and today, that means experience with AWS, Kubernetes, and microservices. Many in the community agreed, noting that this personal incentive often overrides the actual needs of the project. As one commenter put it, "the defacto purpose of startups (and projects at random companies) may actually be work experience and rehearsal for the day the founders and friends get to interview at an actual FAANG." This creates a culture where proposing a simple, $100/month server solution, no matter how appropriate, is seen as less valuable than designing a complex, "web-scale" system. Another user lamented how it's "weirdly harder to sell people on something simple than on something complex. They assume the simple solution must be missing something important."

The Surprising Power of a Single Beefy Server

Another strong current in the conversation was a reminder of a fundamental truth: modern computers are incredibly fast. Many developers have lost touch with just how much a simple, traditional architecture can handle. One user shared a compelling historical anecdote about working for large porn companies before the cloud era, who successfully served hundreds of thousands of concurrent video streams using a straightforward setup of haproxy, nginx, PHP servers, and a single primary MySQL database with a read replica.

This sentiment was repeated in various forms, with many developers sharing stories of running successful SaaS products for years on just a few bare-metal servers. The consensus is that teams massively underestimate what a monolith on modern hardware can do, often reaching for complex distributed systems when they could have handled their load for years on a much simpler and cheaper setup.

The Myth of "Not Managing Infrastructure"

A common justification for using complex cloud services is the claim that it means teams "don't have to manage infrastructure." However, numerous community members quickly debunked this idea. Instead of managing servers, teams find themselves managing an even more complex layer of abstraction. As one developer challenged, "I would invite them to deal with a multi-environment terraform setup and tell me again about what they don't have to manage." The work doesn't disappear; it just shifts to configuring, monitoring, and debugging a fleet of cloud services, which can be far more opaque and frustrating than managing a traditional server.

While some pointed out valid reasons to prefer the cloud, such as the heavy lifting it does for compliance standards like HIPAA or SOC2, the overarching feeling was that for most use cases, the complexity and cost far outweigh the benefits.

Community-Sourced Wisdom and Resources

The discussion wasn't just theoretical; it also yielded practical advice for teams looking to embrace simplicity.

• Rethink Your Hosting: For teams that don't need the specific tooling of a major cloud provider, bare-metal server providers like Hetzner were frequently recommended for offering immense computing power at a fraction of the cost.
• Simple and Powerful Tooling: For deployment, many advocated for simple but robust combinations like using Docker Compose behind Caddy as a reverse proxy. This provides containerization benefits without the massive overhead of a full Kubernetes orchestration.
• Distinguish Scalability from Resiliency: An important clarification was that while a single server can be powerful, multiple servers are often used for resiliency (failover) rather than pure scalability. It's crucial to know which problem you're actually solving.

What's Next for System Design?

This widespread discussion reveals a growing fatigue with the "complexity by default" mindset. It suggests a potential shift back towards pragmatism, where the elegance of a solution is judged by its simplicity and fitness for the current problem, not by how many buzzwords it can fit on a diagram.

However, key questions remain. How do teams develop the wisdom to know when it's truly time to move away from the monolith? And how can the industry as a whole create incentives that reward engineers for building simple, cost-effective solutions, rather than just resume-padding, complex ones? Perhaps the next conversation should focus less on whether to start simple and more on how to gracefully evolve from that simple beginning when success genuinely demands it.

Sources

Origin Article: Why is everything so scalable?
Discussion: https://news.ycombinator.com/item?id=45525168