Every engineer wants to build the perfect system—infinitely scalable, always available, blazing fast, completely consistent, effortlessly maintainable, and cheap to operate.

This system does not exist. It cannot exist.

System design is fundamentally the art of choosing which imperfections to accept. Every architectural decision involves trading one desirable property for another. Faster often means more expensive. More consistent often means less available. Simpler often means less flexible.

The skill of system design is not finding the magical solution that avoids all tradeoffs—it's understanding tradeoffs deeply enough to choose wisely for your specific context.

This page teaches you how to think about, evaluate, and communicate the tradeoffs that define every system you'll ever design.

Tradeoffs in system design aren't a failure of imagination—they're a consequence of physics, economics, and mathematics. Understanding why tradeoffs exist helps you accept them and navigate them wisely.

The tradeoff mindset:

Once you accept that tradeoffs are inevitable, your approach to design changes. Instead of seeking the "best" solution, you seek the "most appropriate" solution. Instead of asking "What's the right answer?", you ask "What are we optimizing for, and what are we willing to sacrifice?"

This shift—from absolutist thinking to tradeoff thinking—is perhaps the most important mental transition in becoming a system designer.

While there are countless specific tradeoffs, they cluster into recognizable categories. Understanding these categories gives you a framework for analyzing any architectural decision.

Tradeoffs are not binary:

Note that these aren't simple either/or choices. Real systems exist on a spectrum. You might choose to be "mostly consistent with occasional staleness" or "high availability with eventual consistency after 5 seconds." The art is in finding the right point on the spectrum for your requirements.

This is the most famous tradeoff in distributed systems, codified in the CAP Theorem. Let's understand it deeply.

CAP Theorem states: In a distributed system, when a network partition occurs, you must choose between:

• Consistency (C): Every read receives the most recent write or an error
• Availability (A): Every request receives a response (no errors, no timeouts)

You cannot have both during a partition. Network partitions (P) are not optional—they happen. So you're really choosing between CP (consistency over availability) and AP (availability over consistency).

Beyond CAP—PACELC:

The PACELC theorem extends CAP: If there is a Partition, choose Availability or Consistency. Else (normal operation), choose Latency or Consistency.

This captures that even without partitions, there's a tradeoff. Synchronous replication (consistent) adds latency. Asynchronous replication (fast) risks stale reads.

Example: Google Spanner chooses consistency at the cost of latency, using atomic clocks to enable globally consistent reads. Amazon DynamoDB defaults to eventual consistency for lower latency, with optional strong consistency at higher latency cost.

Latency (how fast) and throughput (how many) are often in tension. Optimizing for one can hurt the other.

Latency: Time from request start to response received. Usually measured in milliseconds. Matters for user experience and real-time systems.

Throughput: Number of requests processed per unit time. Usually measured in requests per second (RPS) or transactions per second (TPS). Matters for capacity and cost efficiency.

Practical example — Message Queues:

Consider a message queue like Kafka:

• Low latency configuration: Small batch sizes, immediate flush, minimal buffering → Each message is processed quickly, but you can't handle as many messages per second.

• High throughput configuration: Large batches, buffered writes, background compression → You process millions of messages per second, but each individual message waits longer.

Which to choose depends on use case:

• User-facing notifications: Optimize for latency (users want to see notifications immediately)
• Log aggregation: Optimize for throughput (slightly delayed logs are fine; volume is massive)

This is often the most uncomfortable tradeoff for engineers—we want the best performance, but budgets are real constraints. Understanding this tradeoff is essential for practical system design.

The economic reality:

Every system has a cost/performance curve. Initially, more spending brings proportional performance gains. But eventually, you hit diminishing returns—each additional dollar buys less improvement.

Finding the sweet spot:

1. Define "good enough" — What's the minimum acceptable performance for your use case?
2. Measure current state — Where are you on the curve?
3. Identify the knee — Where do returns start diminishing sharply?
4. Optimize for value — Aim for the knee of the curve, not the theoretical maximum.

Hidden costs to consider:

• Engineering time to build and maintain complex high-performance systems
• Operational burden of more moving pieces
• Opportunity cost—money spent on performance is money not spent elsewhere

This tradeoff is often underappreciated but has profound long-term impact. Simple systems are easier to understand, maintain, and debug—but less capable of handling diverse requirements. Flexible systems can handle almost anything—but become difficult to understand and maintain.

The monolith vs microservices example:

Monoliths are simpler: one codebase, one deployment, no network calls between components. But they're less flexible: harder to scale components independently, all teams work in one repo, one technology stack.

Microservices are more flexible: independent scaling, polyglot development, small focused teams. But they're more complex: distributed transactions, network failures, operational overhead, complex debugging.

When to choose:

• Lean toward simplicity when requirements are stable, team is small, speed of development matters most, and you're uncertain about future needs.

• Lean toward flexibility when requirements are diverse, teams are large and need independence, you have proven scaling needs, and you can afford the operational investment.

The common mistake: Building for flexibility before you need it. Many systems become unnecessarily complex because architects anticipated needs that never materialized. Start simple; add flexibility when demonstrated needs arise.

Understanding tradeoffs conceptually is one thing; evaluating them for specific decisions is another. Here's a practical framework for making tradeoff decisions.

Practical application:

Let's say you're deciding between:

• Option A: Simple single-region deployment (lower latency for nearby users, cheaper, simpler)
• Option B: Multi-region deployment (resilient to regional failures, global low latency)

Apply the framework:

1. Requirements: Is 99.99% uptime required? If yes, single-region likely can't achieve it—disaster eliminates the option.
2. Impact: How many users are far from your single region? If 60% of users are in other continents, the latency impact is severe.
3. Context: What's your budget? Multi-region can double costs. What's your ops team size? Multi-region adds operational complexity.
4. Evolution: Are you expanding internationally? If yes, building multi-region now avoids migration later.

The "right" answer depends entirely on these factors. There's no universal correct choice.

Understanding tradeoffs is only half the battle. Communicating them to stakeholders—peers, managers, product teams—is equally important. Many good designs fail because they weren't communicated effectively.

The tradeoff table:

A useful communication tool is a simple table comparing options:

This format makes tradeoffs visible and facilitates productive discussion.

Even experienced engineers make tradeoff mistakes. Knowing the common patterns helps you avoid them.

Tradeoff thinking is the core intellectual skill of system design. Let's consolidate what we've learned:

What's next:

We've defined system design, distinguished it from coding, and explored the art of tradeoffs. Now we're ready for the final piece of Module 1's foundation: understanding system design as problem-solving at scale. The next page explores how scale transforms simple problems into complex systems challenges—and how to think about problems at the scale of millions of users.