Requirements, Constraints & Trade-offs

The Governing Triangle

Every system design decision sits inside a triangle of forces:

                 REQUIREMENTS
              (what the system must do)
                /                \
               /                  \
              /     EVERY DESIGN   \
             /      DECISION LIVES  \
            /       IN HERE          \
     CONSTRAINTS ──────────────── TRADE-OFFS
     (hard limits: budget,        (gains in one quality
      team, deadline, tech)        cost another quality)

• Requirements define success — functional (what it does) and non-functional (how well).
• Constraints are non-negotiable walls — money, deadlines, existing tech, team skills.
• Trade-offs are what happens when requirements pull against constraints and each other.

Design is not optimization toward one ideal. It is negotiation among competing goods under fixed limits. A candidate answer with no stated trade-off has not finished reasoning.

Why Trade-offs Are Unavoidable

The fundamental qualities of distributed systems physically conflict:

Tension	Why it exists
Consistency vs availability	Network partitions force choosing which to sacrifice
Latency vs durability	Waiting for fsync + replication adds milliseconds
Performance vs cost	Faster = more machines, more memory, closer to users
Flexibility vs simplicity	More options = more states to test and operate
Freshness vs load	Recomputing always-fresh data hammers backends

No configuration maximizes all columns simultaneously. Picking which tension to feel is the design.

Worked Example

Requirement: product images load instantly worldwide; budget capped.

 OPTION A: origin server only          OPTION B: CDN in front
 - $0 extra infra                      - egress cheaper at edge, but
 - latency: 200–800ms far users          CDN fees added
 - origin saturates on spikes          - latency: 20–80ms via edge cache
 - zero new failure modes              - new concerns: invalidation,
                                         cache-control correctness

 CHOSEN: B, because perceived latency is a hard requirement
 and CDN cost < scaling origin compute for global traffic.
 The trade-off ACCEPTED: eventual consistency of image updates
 (invalidation lag seconds–minutes).

Note the shape of the reasoning: requirement → options → quantified comparison → explicit acceptance of what got worse.

Constraints Deserve Equal Billing

Teams routinely design as if only requirements matter, then collide with constraints late:

• Budget: sharding across 32 nodes sounds great until the invoice arrives.
• Team: Kafka is excellent if nobody can operate it is a trap, not a stack.
• Deadline: the six-month rewrite loses to the two-week integration.
• Existing systems: greenfield thinking applied to brownfield reality wastes quarters.

Constraints are facts. Designs that ignore them are fiction with diagrams.

Interview Framing

Interviewers inject trade-off pressure deliberately (“what if traffic 10x? budget halves?”). Strong candidates treat each prompt as re-entering the triangle — restating which requirements flex, which constraints hold, then re-negotiating openly rather than patching boxes silently.