Scrolls
3 min read
On this page

Constraints & Trade-Offs

Every decision involves giving something up to get something else. There is no such thing as a free lunch — every choice carries a cost, even if that cost is invisible at first. Understanding constraints and trade-offs is how you make better decisions, whether you are planning dinner or designing a distributed system.

The Everyday Version

Time vs Money

One of the most universal trade-offs shows up every evening at dinnertime.

Option A: Cook at Home
- Cost: $8 in ingredients
- Time: 45 minutes of cooking + cleanup
- Quality: Exactly what you like
- Effort: High

Option B: Order Takeout
- Cost: $25 with delivery fee and tip
- Time: 5 minutes to order, 30 minutes to wait
- Quality: Depends on the restaurant
- Effort: Low

Option C: Meal Prep on Sunday
- Cost: $6 per meal (bulk buying)
- Time: 2 hours once, then 5 minutes to reheat
- Quality: Good but repetitive
- Effort: Front-loaded

None of these is objectively best. If you are exhausted after a long day, the extra $17 for takeout buys you rest. If money is tight, cooking is worth the time. The right answer depends on your constraints.

Speed vs Safety

Driving gives us an intuitive feel for trade-offs.

Driving faster:
+ Arrive sooner
- Higher fuel consumption
- Greater risk of accident
- More expensive tickets
- Higher insurance costs

The speed limit is not arbitrary — it represents society's
agreed-upon trade-off between getting places quickly
and keeping people alive.

Space vs Convenience

Think about your closet.

Keeping everything:
+ You might need it someday
- Hard to find what you actually need
- Closet is packed and stressful
- Costs more if you need a bigger place

Minimizing aggressively:
+ Easy to find things
+ Less clutter, less stress
- Occasionally you wish you had kept something
- Cost of re-buying items you discarded

There is a sweet spot, and it is different for everyone. The point is not which choice is right — it is recognizing that both have costs.

The Constraint Triangle

Many trade-offs follow a pattern: you can have two out of three, but not all three.

The classic project triangle:

        Fast
        /  \
       /    \
      /      \
    Good --- Cheap

Pick any two:
- Fast + Good = Expensive
- Fast + Cheap = Low quality
- Good + Cheap = Slow

This pattern shows up everywhere:

Apartment hunting:
- Close to work + Spacious = Expensive
- Close to work + Affordable = Small
- Spacious + Affordable = Long commute

Education:
- Prestigious + Affordable = Extremely competitive
- Prestigious + Easy to get in = Expensive
- Affordable + Easy to get in = Less prestigious

Connecting to Technology

Memory vs Speed

One of the oldest trade-offs in computing: you can make programs faster by using more memory, or use less memory by accepting slower execution.

Example: Looking up a customer's order history

Approach A: Store everything in memory (cache)
- Speed: Instant lookup (1 millisecond)
- Memory: Requires 50 GB of RAM
- Cost: Expensive servers

Approach B: Query the database each time
- Speed: Slower lookup (100 milliseconds)
- Memory: Minimal RAM needed
- Cost: Cheaper servers, but slower experience

Approach C: Cache the most recent orders only
- Speed: Fast for recent orders, slower for old ones
- Memory: Requires 5 GB of RAM
- Cost: Moderate — a practical middle ground

Approach C is a trade-off within a trade-off. Most real solutions live in the middle, not at the extremes.

Consistency vs Availability (The CAP Theorem)

In distributed systems, you face a fundamental trade-off when the network has problems:

Consistency: Every user sees the same data at the same time
Availability: The system always responds, even if data might be stale

When the network is working fine, you get both.
When there is a network problem, you must choose:

Option A: Stay consistent
- Refuse to serve data until all servers agree
- Users see an error page temporarily
- Example: Banking systems (you must see the real balance)

Option B: Stay available
- Serve potentially outdated data
- Users always get a response
- Example: Social media feeds (showing a post from 2 seconds
  ago instead of right now is acceptable)

Build vs Buy

A decision every organization faces repeatedly:

Build It Yourself:
+ Exactly what you need
+ Full control over changes
+ No vendor dependency
- Takes months or years
- You maintain it forever
- Bugs are your problem

Buy or Use Existing:
+ Available immediately
+ Someone else maintains it
+ Battle-tested by other users
- May not fit your needs exactly
- Vendor can change pricing or features
- You depend on someone else's roadmap

The calculation:
- If it is core to your business → lean toward building
- If it is a commodity (email, payments, hosting) → lean toward buying
- If you are unsure → start by buying, build later if needed

Latency vs Throughput

Analogy: Shipping packages

Low latency (fast delivery):
- Send each package by express courier as it arrives
- Each package arrives in 1 day
- Expensive per package

High throughput (efficient delivery):
- Wait until you have a full truckload, then ship
- Packages wait 3-5 days to fill the truck
- Much cheaper per package

In tech:
- Real-time chat needs low latency (send each message now)
- Batch data processing needs high throughput
  (process millions of records efficiently)
- You rarely get both without spending significantly more

Security vs Usability

Maximum security:
- 30-character passwords changed weekly
- Two-factor authentication on every action
- Session expires every 5 minutes
- Result: Nobody wants to use the system

Maximum usability:
- No password required
- Stay logged in forever
- One-click access to everything
- Result: Anyone can access anything

The trade-off in practice:
- Strong password + two-factor at login
- Session lasts a reasonable time (hours, not minutes)
- Extra verification only for sensitive actions
  (changing password, transferring money)

How to Think About Trade-Offs

A useful framework for any decision:

Step 1: Identify what you are trading
- What do you gain?
- What do you give up?
- What constraints are truly fixed vs negotiable?

Step 2: Understand who bears the cost
- A faster website might cost more engineering time
- A cheaper product might cost customer satisfaction
- A quicker decision might cost future flexibility

Step 3: Consider reversibility
- Reversible trade-offs are safer to experiment with
- Irreversible trade-offs deserve more analysis
- "Two-way door" decisions: just pick one and adjust
- "One-way door" decisions: think carefully

Step 4: Revisit over time
- Constraints change
- What was expensive last year might be cheap now
- What was a good trade-off at 100 users might be
  wrong at 100,000 users

Hidden Constraints

Some of the most important constraints are the ones you do not see:

Obvious constraints:
- Budget
- Deadline
- Available materials

Hidden constraints:
- Team morale (pushing too hard has a cost)
- Technical debt (shortcuts now cost more later)
- Opportunity cost (choosing A means not doing B)
- Cognitive load (too many options paralyze decisions)
- Maintenance burden (everything you build must be maintained)

Common Pitfalls

  • Ignoring trade-offs entirely. Believing you can have everything — fast, cheap, and perfect — leads to disappointment or failure.
  • Optimizing for one dimension only. Making the system as fast as possible while ignoring cost, maintainability, or usability.
  • Treating constraints as permanent. What is too expensive today may be affordable tomorrow. Revisit old assumptions.
  • Forgetting opportunity cost. Every hour spent on feature A is an hour not spent on feature B. The cost of what you did not do is real.
  • Choosing based on the wrong audience. Optimizing for developers when users are the ones affected, or vice versa.
  • Analysis paralysis. Spending so long evaluating trade-offs that you never make a decision at all.

Key Takeaways

  • Every decision is a trade-off. If you think there are no downsides, you have not looked hard enough.
  • The constraint triangle (fast, good, cheap — pick two) applies broadly, not just to projects.
  • The best solutions usually live in the middle, not at the extremes.
  • Hidden constraints like opportunity cost, team morale, and maintenance burden are just as real as budget and deadlines.
  • Reversible decisions deserve less agonizing. Irreversible ones deserve more.
  • Constraints change over time. A trade-off that made sense last year might need revisiting today.