If you’re preparing for a System Design interview or leading a new project, stop trying to build the "perfect" system. It doesn't exist. Instead, focus on these three tension points where one "win" usually means a "loss" somewhere else.
1. The Data Triangle (CAP Theorem)
You’ve heard of CAP, but here is how to explain it simply: You can only pick two at any given time during a network failure.
Consistency: Everyone sees the same data at the same time.
Availability: The system is always up, even if the data is slightly old.
Partition Tolerance: The system keeps working even when communication between nodes breaks.
The Real-World Choice: Is your app a Bank (Consistency is non-negotiable) or a Social Feed (Availability matters more than seeing a "like" 2 seconds late)?
2. The Performance Triangle (L-T-P)
When a system feels "slow," you need to know which lever to pull:
Latency: how long a single request takes (The "Speed" lever).
Throughput: how many requests you can handle per second (The "Volume" lever).
Precision: how accurate/fresh the result is (The "Quality" lever).
The Trade-off: You can have high throughput, but your latency might spike. You can have low latency, but you might have to serve "stale" (less precise) cached data.
3. The Engineering Triangle (Cost-Speed-Scale)
This is where the business meets the code:
Cost: How much are we spending on AWS/Infra?
Development Speed: How fast can we ship the feature?
Scale: Can this handle $1$ million users tomorrow?
The Senior Move: A Junior engineer tries to optimize all three. A Senior engineer asks: "Do we really need to scale to $1M$ users today if it triples our cloud bill and delays our launch by 4 months?"
Why this matters:
System design isn't about knowing what a Load Balancer is; it’s about knowing why you chose a specific one for your specific triangle.
Next time you're in a design review, ask: "Which corner of the triangle are we sacrificing?" That’s when the real engineering starts.
Top comments (0)