Every system design decision comes down to trade-offs between a handful of properties. This post walks through the foundational ones — quality attributes, the CAP theorem, PACELC, and the consistency spectrum — using one running example: you open Swiggy on a Friday night and order biryani.
Uber works almost identically (rider + driver instead of eater + delivery partner), so the same lens applies there too.
Part 1 — Quality Attributes
Scenario: Friday 8:30 PM. You order biryani on Swiggy.
| Attribute | One-line meaning | Swiggy moment |
|---|---|---|
| Scalability | Handle more load | 10k users at 3PM → 5M at dinner. Add servers. |
| Latency | Speed of your one request | Tap search → results in <1 sec |
| Throughput | Total volume for everyone | 2M searches/sec across India |
| Availability | Is it up? | App must not go down at peak |
| Reliability | Is the answer correct? | Don't show "delivered" when food's still cooking |
| Durability | Data survives crashes | Your paid order never gets lost |
| Consistency | Everyone sees same latest data | "Sold out" shows to all instantly (or not) |
| Fault tolerance | Keeps working when a part dies | 1 of 500 servers crashes → you notice nothing |
| Maintainability | Easy to change code | Ship features weekly, safely |
| Observability | Can see inside | Order stuck? Trace exactly where |
The ONE big idea
You can't max all of them. They fight. Pick 2–3 that matter, sacrifice the rest.
Proof — same Swiggy, opposite choices:
- 💳 Payment → wins: consistency, durability, reliability. sacrifices: latency (2-sec wait is fine)
- 🔍 Search/browse → wins: latency, availability. sacrifices: consistency (stale for 5 sec is fine)
Same company. Opposite rankings. That ranking = the architecture decision.
One quick distinction that trips people up:
- Reliability / Consistency / Availability = what the user feels
- Observability / Maintainability = what the engineer needs behind the scenes
Don't mix the two camps.
Part 2 — CAP Theorem
Setup: Swiggy runs on many servers in different cities. Sometimes the network between them breaks — a server in Delhi can't talk to a server in Bengaluru. That break is called a partition.
Three things you want:
| Letter | Means |
|---|---|
| C — Consistency | Everyone sees the same latest data |
| A — Availability | Every request gets an answer |
| P — Partition tolerance | System survives the network break |
The rule: During a partition, you can only keep 2 of 3. And since network breaks will happen, P is not optional. So the real choice is just: C or A?
The choice, on Swiggy
Delhi and Bengaluru servers can't talk. You place an order. What does Swiggy do?
- Pick C (refuse): "Sorry, try again later." → Correct, but you got blocked. This is a CP system.
- Pick A (accept): "Order placed!" → but Delhi doesn't know yet, data is briefly out of sync. This is an AP system.
You can't have both during the break. Correctness OR uptime.
Which does Swiggy pick? Depends on the feature
- 💳 Payment → CP. Better to block than double-charge. Refuse and stay correct.
- 🔍 Browse restaurants → AP. Better to show slightly stale list than an error page. Stay up.
The classic trap: "CA system"
A CA system means "no partition tolerance" — that only works on a single machine. Any real distributed system will face network breaks, so P is forced on you. You're always really choosing C or A. "CA distributed" is a contradiction.
The clean way to hold it: P is forced, C-or-A is the actual choice.
Part 3 — PACELC
The gap in CAP: CAP only tells you what happens during a network break. But breaks are rare. What about normal times, when everything's healthy? CAP says nothing. PACELC fixes that.
Read it like a sentence:
Partition? → choose A or C
Else (normal times)? → choose L or C
(L = Latency)
| Situation | The choice |
|---|---|
| P — network broken | Availability or Consistency (this is just CAP) |
| E — normal, healthy | Latency or Consistency (this is the NEW part) |
Why is there even a choice when the network is fine?
Because to be strongly consistent, servers must coordinate — "wait, let me check with Delhi and Mumbai before I answer." That checking takes time = latency.
So even with a perfect network:
- Want everyone to see the exact same data? → coordinate → slower (pay latency)
- OK with slightly stale? → skip coordination → faster
This trade-off is happening all the time, not just during failures. That's PACELC's whole point.
On Swiggy
- 💳 Payment → PC / EC → consistent always, even if it's a bit slow. Both cases pick C.
- 🔍 Browse → PA / EL → during break: stay available. Normal times: stay fast. Both cases avoid the cost of C.
Read it as two letters: PA/EL = "in Partition pick A, Else pick L." Speed and uptime over correctness.
Part 4 — The Consistency Spectrum (the dial)
"Consistent vs eventual" isn't a switch — it's a dial. Here it is, strongest (slowest) → weakest (fastest):
| Level | Plain meaning | Swiggy example |
|---|---|---|
| Strong | Every read = newest write, always | Wallet balance — never wrong |
| Bounded staleness | Can lag, but only by X seconds max | Order status, max 5 sec behind |
| Session | You always see your own writes in order | Your cart — you added it, you see it |
| Consistent prefix | Never see things out of order, just maybe old | Order timeline: placed→cooking→out, never scrambled |
| Eventual | Catches up eventually, no promise on order | "Trending near you" list |
Top = safest + slowest. Bottom = fastest + loosest. You turn the dial per feature.
Azure tie-in
Cosmos DB literally exposes these as 5 settable levels — Strong, Bounded Staleness, Session, Consistent Prefix, Eventual. Session is the default. This isn't theory — it's a dropdown you configure. Wallet → Strong. User cart → Session. Trending list → Eventual.
Wrapping up
The whole of foundations comes down to one habit: name the 2–3 attributes that matter for the feature in front of you, then choose what to sacrifice — during failures (CAP), during normal operation (PACELC), and at the exact level of consistency you actually need (the spectrum). Same system, different features, opposite choices. That ranking act is the architecture.
Top comments (0)