All posts

Trade-offs Are the Real Architecture

Every system choice is basically you signing up for a set of trade-offs—whether you acknowledge them or not. There’s no “best” tech stack in isolation. There’s only “best for what you’re trying to optimize.”

Take Netflix for example. They leaned heavily into microservices years ago. Sounds great—independent deployments, better scalability, teams can move fast. But that comes with a cost: operational complexity explodes. You now need service discovery, distributed tracing, fault tolerance patterns, and a solid observability stack.

Netflix has publicly shared that they run thousands of microservices powering their platform, handling hundreds of millions of users globally.
👉 https://netflixtechblog.com

That scale justifies the complexity. But for most teams, that same architecture would be overkill. They even built tools like Hystrix to deal with cascading failures—something you don’t even think about in a monolith.

Now compare that to Basecamp. They intentionally stick with a monolith built on Ruby on Rails. Their reasoning is pretty straightforward: fewer moving parts = fewer things that break.

In their own words:
👉 https://world.hey.com/dhh

A well-structured monolith can handle millions of users just fine.

And they’re not wrong. Companies like Shopify (also Rails-heavy early on) scaled massively before introducing more distributed patterns.

Trade-off:

  • Microservices → scale + team autonomy, but operational overhead
  • Monolith → simplicity + speed of development, but limits at extreme scale

Databases are another classic battleground: PostgreSQL vs MongoDB.

PostgreSQL gives you:

  • Strong ACID guarantees
  • Complex joins and transactions
  • Reliability at the core

MongoDB gives you:

  • Flexible schema
  • Easier horizontal scaling
  • Faster iteration early on

MongoDB use cases:
👉 https://www.mongodb.com/use-cases

Meanwhile, PostgreSQL consistently ranks as one of the most loved databases in Stack Overflow’s Developer Survey, largely because of its robustness.

Trade-off:

  • Structure and safety vs flexibility and speed

Frontend is no different. Meta popularized React, which today powers a huge chunk of the web. According to surveys like State of JS, React has consistently had 40%+ usage among frontend developers.

React gives you:

  • Component-driven architecture
  • Huge ecosystem
  • Flexibility in how you manage state

But that flexibility is also the problem. There are too many choices—Redux, Zustand, Context, server components, etc.

Now compare that to Vue.js.

Vue tends to be:

  • Easier to learn
  • More opinionated
  • Faster to get started

But it doesn’t always scale organizationally the same way React does in massive teams.

Trade-off:

  • Flexibility and ecosystem vs simplicity and clarity

Cloud platforms make this even more obvious. Amazon Web Services (AWS) offers over 200+ services.
👉 https://aws.amazon.com/products/

You can build almost anything.

But:

  • Pricing gets complicated fast
  • Misconfiguration is easy
  • Debugging distributed systems is hard

On the other end, platforms like Vercel optimize for developer experience. You can deploy in minutes, get global CDN, serverless functions—all without thinking too much.

But:

  • Less control
  • Potential vendor lock-in
  • Not ideal for highly customized infra

Trade-off:

  • Power and flexibility vs simplicity and speed

Even programming languages reflect this tension.

Go:

  • Simple
  • Fast compile times
  • Easy concurrency
  • Widely used in cloud infrastructure

Rust:

  • Memory safety without garbage collection
  • High performance
  • Strong compile-time guarantees

But Rust comes with a steeper learning curve. Surveys consistently show Rust as the “most loved language”, but not the most used—because it’s harder to adopt.

Trade-off:

  • Developer speed vs control and safety

The Real Point

What’s funny is people argue about these choices like there’s a universal right answer. There isn’t.

Every decision is just you saying:

  • “I care more about this… and I’m okay giving up that.”

And those priorities change over time.

A 5-person startup should not be thinking like Netflix.
A company at Netflix scale cannot behave like a startup.

The real skill isn’t picking the “best” tech. It’s being brutally honest about:

  • What you actually need
  • What you’re willing to deal with later

Because you will pay for every decision—either now in complexity, or later in limitations.

There’s no escaping trade-offs.

Only choosing them.