The four levers: latency, throughput, consistency, availability

Most system design discussions eventually reduce to tradeoffs between these four properties. Knowing them by name — and knowing they trade off against each other — is what lets you explain why you're choosing something instead of just asserting it.

The four

• Latency — how long a single request takes. What a user actually feels.
• Throughput — how many requests the system handles per unit time. What capacity planning is about.
• Consistency — whether every read sees the latest write, everywhere, immediately. Strong consistency is expensive; many real systems deliberately relax it.
• Availability — whether the system keeps responding at all, even when parts of it fail.

Where they conflict

The classic tension is consistency versus availability under a network partition (the "CP vs AP" framing from the CAP theorem) — you can't guarantee both when parts of a distributed system can't talk to each other. A payments ledger usually leans consistent (an incorrect balance is worse than a slow response); a social media like-counter usually leans available (a stale count for a few seconds is fine, downtime isn't).

Latency and throughput trade off too — batching requests improves throughput but adds latency to any individual request, which is exactly why some systems offer both a "fast path" and a "batch path" for the same operation.

Using this in an interview

When you make a design choice, name which of these four you're prioritizing and which you're accepting a cost on. "I'm choosing eventual consistency here because availability matters more for this feature" is a complete, defensible sentence — and it's the sentence system design interviews are listening for.