🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

💰 धडा 16 — Cost, trade-offs आणि ADRs: प्रत्येक box ला एक बिल आणि एक कारण असते

📍 तुम्ही इथे आहात: 18 पैकी धडा 16 · पुढे: lesson-17-designs-short-notify-chat

📦 या ब्रँचमध्ये काय आहे

धडे 01–15, आणि प्रत्येक box साठी शेवटचे दोन प्रश्न: याचा खर्च किती? आणि हे इथे का आहे? तुम्ही उदाहरणादाखल किमतींसह एक पहिले बिल बनवता, त्यात कोणता भाग सर्वात मोठा ते शोधता, एक trade-off table ठेवता, आणि एक ADR (Architecture Decision Record) लिहिता: context, decision, consequences, status — आणि ते लिहिणे कधी योग्य ते शिकता.

design/designs.py — PRICE, monthly_cost(...) आणि adr(...)
design/demo.py — python3 design/demo.py cost
design/test_design.py — check L16

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

आराखडा भिंतीवर लावलेला आहे. शाळेच्या मुख्याध्यापिका आत येतात आणि दोन प्रश्न विचारतात.

"दर महिन्याला याचा खर्च किती येईल?" कतरिना ओळीने ओळ बेरीज करते: servers, storage, बाहेर पाठवलेला data, requests. उदाहरणादाखल किमतींनी महिन्याला $1,216. सर्वात मोठी ओळ servers नाही. ती आहे पालकांच्या phones कडे बाहेर पाठवलेला data.

"आणि इथे Redis box का आहे?" कोणालाच आठवत नाही. ऐश्वर्या गेल्या वर्षी कार्यालय सोडून गेली. म्हणून दीपिका नियम करते: प्रत्येक मोठ्या निर्णयाला एका folder मध्ये एक पान मिळते. अडचण काय होती? आपण काय निवडले? त्याची आपल्याला काय किंमत मोजावी लागते? ते अजून खरे आहे का? पुढच्या वर्षी नवी planner अंदाज बांधण्याऐवजी ते पान दोन मिनिटांत वाचते.

🗺️ आकृती

flowchart LR
    subgraph bill["🧾 a first bill (example prices)"]
      s["servers $360"]
      st["storage $46"]
      e["egress $450 ← largest"]
      r["requests $360"]
      t["total $1,216 / month"]
    end
    bill --> tt["⚖️ trade-off table<br/>option · gain · cost · risk"]
    tt --> adr["📄 ADR 001<br/>Status · Context · Decision · Consequences"]
    adr --> repo["📁 docs/adr/ in the repo"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l16

❓ काय

पहिले cost model — बहुतेक रचना ज्या चार ओळींनी बनतात: compute (servers, containers, functions), storage (महिन्याला GB), egress (internet वर बाहेर पाठवलेले GB), requests (managed service ला दर million calls). धडा 02 मधले आकडे किमतीने गुणा आणि बेरीज करा. इथल्या किमती फक्त उदाहरणे आहेत — पैसे गुंतवण्याआधी provider चे pricing page किंवा calculator वापरा.
सर्वात मोठा भाग — एक ओळ सहसा बाकीच्यांपेक्षा खूप मोठी असते. ती शोधा, आणि रचनेचे श्रम तिथे खर्च करा. Read-heavy apps बहुतेकदा egress साठी सर्वाधिक पैसे देतात; video नक्कीच (धडा 18); chat app connections साठी पैसे देते; AI app tokens साठी पैसे देते.
रचनेबरोबर खर्च बदलतो — cache (धडा 05) database चा आकार कमी करतो; CDN egress ची किंमत बदलतो; queue (धडा 07) मुळे कमी, जास्त व्यस्त workers चालवता येतात.
Trade-off table — प्रत्येक खऱ्या निवडीसाठी एक छोटे table: पर्याय, प्रत्येकातून काय मिळते, त्याची किंमत काय (पैसे, latency, माणसे, धोका). format पेक्षा सवय जास्त महत्त्वाची: कधीही एकच पर्याय नाही. "आम्ही X निवडले" याला "Y ऐवजी" शिवाय काही अर्थ नाही.
ADR (Architecture Decision Record) — प्रत्येक निर्णयासाठी एक छोटे Markdown पान:
- Status — Proposed, Accepted, Deprecated, किंवा ADR n ने Superseded;
- Context — त्या वेळचे दबाव: आकडे, गरजा, मर्यादा;
- Decision — आपण काय करणार, एक-दोन वाक्यांत;
- Consequences — त्यातून येणारे चांगले आणि वाईट. ADRs ना क्रमांक दिले जातात, code शेजारी repo मध्ये ठेवले जातात, आणि कधीही पुन्हा लिहिले जात नाहीत — नवे ADR जुन्याची जागा घेते.
कधी लिहायचे — जेव्हा निर्णय उलटवणे कठीण असते (database, cloud, protocol), खर्चिक असते (बिलावर नवी ओळ), आश्चर्यकारक असते (नंतर कोणीतरी विचारेल "का?"), किंवा एका दिवसापेक्षा जास्त वाद झाले असतील. लहान, सहज बदलता येणाऱ्या निवडींसाठी नाही.

🤔 का

कारण ज्या रचनेचा खर्च कोणालाच परवडत नाही ती रचना नाही, आणि जी रचना कोणालाच समजावता येत नाही ती सांभाळली जात नाही. धडा 02 मधले आकडे प्रत्येक box ला किंमत देतात. ADR किमतीशेजारी कारण ठेवते, म्हणजे नंतरचा बदल तथ्यांनिशी होतो — निरुपयोगी दिसणारा पण प्रत्यक्षात p99 सांभाळणारा box delete करून नाही.

🔧 कसे (या repo मध्ये)

design/designs.py मध्ये:

PRICE = dict(server_month=60, gb_month=0.023, egress_gb=0.09, request_million=0.40) — उदाहरणादाखल किमती.
monthly_cost(servers, storage_gb, egress_gb, requests_million) प्रत्येक ओळ आणि एकूण परत करते.
adr(number, title, context, decision, consequences, status="Accepted") Markdown पान परत करते.

design/demo.py मधले cost() सूचना फलकाची किंमत काढते (6 servers, 2,000 GB, 5,000 GB egress, 900 million requests) आणि Redis cache बद्दल ADR 001 लिहिते.

🧪 करून पाहा

python3 design/demo.py cost
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from designs import monthly_cost, adr
base = dict(servers=6, storage_gb=2_000, egress_gb=5_000, requests_million=900)
for name, change in (("first bill", {}), ("double the servers", {"servers": 12}), ("photos: 10x egress", {"egress_gb": 50_000}), ("5 years of storage", {"storage_gb": 11_000})):
    c = monthly_cost(**{**base, **change}); big = max((k for k in c if k != "total"), key=c.get)
    print(f"{name:<20} total ${c['total']:>9,.2f} · biggest part: {big} ${c[big]:,.2f}")
print(adr(2, "Send urgent notices by SMS through a queue", "5M parents; SMS must not slow the post request.",
          "Post writes one job to a queue; 50 workers send in batches.", ["post answers in ~50 ms", "SMS may arrive minutes later", "workers must be idempotent"], status="Proposed"))
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

cost हे छापते:

── a first bill for the notice board (example prices)
   servers   $   360.00
   storage   $    46.00
   egress    $   450.00
   requests  $   360.00
   total     $ 1,216.00
── the decision, written down:
   # ADR 001: Cache the class feed in Redis

   Status: Accepted

   ## Context
   Reads are 100x writes; p99 must stay under 200 ms at 3x peak.

   ## Decision
   Cache-aside per class, TTL 60 s, delete on post.

   ## Consequences
   - ~80% of reads skip the database (lesson 05's curve)
   - a notice can be up to 60 s late for some readers
   - one more thing to run

तुमचा snippet हे छापतो:

first bill           total $ 1,216.00 · biggest part: egress $450.00
double the servers   total $ 1,576.00 · biggest part: servers $720.00
photos: 10x egress   total $ 5,266.00 · biggest part: egress $4,500.00
5 years of storage   total $ 1,423.00 · biggest part: egress $450.00
# ADR 002: Send urgent notices by SMS through a queue

Status: Proposed

## Context
5M parents; SMS must not slow the post request.

## Decision
Post writes one job to a queue; 50 workers send in batches.

## Consequences
- post answers in ~50 ms
- SMS may arrive minutes later
- workers must be idempotent

Tests मध्ये ✅ L16 the bill adds up and the ADR has its sections आहे.

🏁 तुम्ही आत्ताच काय सिद्ध केले

पहिले बिल महिन्याला $1,216 आहे, आणि सर्वात मोठी ओळ egress ($450) आहे, servers नाहीत. Servers दुप्पट केल्याने $360 वाढतात. पाच वर्षांचे storage (11,000 GB — धडा 02 चे ~11 TB) फक्त $207 वाढवते. पण पालकांना photos download करू दिले (10× egress) तर बिल $5,266 होते — एका product कल्पनेने सगळ्या server निर्णयांपेक्षा जास्त खर्च बदलला. म्हणूनच प्रत्येक रचनेत cost ची ओळ हवी. आणि ADR छोटे असते: status, context, decision, आणि वाईट परिणामही सांगणारे consequences ("SMS may arrive minutes later").

⚠️ नेहमीच्या चुका

फक्त servers ची किंमत काढणे आणि egress, requests, logs आणि backups विसरणे
उदाहरणादाखल किमतींवर (इथल्यासुद्धा) विश्वास ठेवणे — किमती region नुसार आणि काळानुसार बदलतात
मोठी ओळ (egress) वाढत असताना छोटी ओळ (storage, $46) optimise करणे
फक्त चांगले परिणाम सांगणारे ADRs — मग त्या नोंदी नाहीत, जाहिराती आहेत
निर्णय बदलल्यावर जुने ADR edit करणे — त्याची जागा घेणारे नवे ADR लिहा
कोणालाच न सापडणाऱ्या wiki मधले ADRs — ते repo मध्ये, ते समजावत असलेल्या code शेजारी ठेवा
प्रत्येक छोट्या निवडीसाठी ADR — 300 ADRs कोणीच वाचत नाही

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — मागच्या महिन्याचे बिल खरोखर किती आहे ते, प्रत्येक service नुसार, पाहा:

aws ce get-cost-and-usage --time-period Start=2026-08-01,End=2026-09-01 \
    --granularity MONTHLY --metrics UnblendedCost \
    --group-by Type=DIMENSION,Key=SERVICE

forecast च्या 80% ला email पाठवणारे मासिक budget:

aws budgets create-budget --account-id 111122223333 \
    --budget '{"BudgetName":"notice-board","BudgetLimit":{"Amount":"1500","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
    --notifications-with-subscribers '[{"Notification":{"NotificationType":"FORECASTED","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"planning-office@school.example"}]}]'

प्रत्येक resource ला ते रचनेच्या ज्या भागाचे आहे तो tag लावा, म्हणजे बिल आकृतीप्रमाणेच विभागता येते (tag ला cost allocation tag म्हणून activate करा):

aws resourcegroupstaggingapi tag-resources \
    --resource-arn-list arn:aws:rds:ap-south-1:111122223333:db:notices-db \
    --tags component=notices-db,app=notice-board

repo मध्ये files म्हणून, क्रमांक दिलेले ADRs:

docs/adr/
  0001-cache-the-class-feed-in-redis.md
  0002-send-urgent-notices-by-sms-through-a-queue.md
  0003-postgresql-as-the-main-store.md

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: पहिल्या तिमाहीत दर महिन्याला खरे बिल आराखड्यातल्या बिलाशी ताडून पाहा. अंदाजाच्या दुप्पट असलेली ओळ हा रचनेचा प्रश्न आहे — आणि त्याचे उत्तर बहुतेकदा एक ADR असते.

⏭️ पुढे

पद्धत पूर्ण झाली: गरजा, आकडे, API, data, blocks, failure, security, observability, cost, ADRs. आता ती सुरुवातीपासून शेवटपर्यंत वापरा. सोडवलेल्या रचना: URL shortener, notifications आणि chat.

git checkout lesson-17-designs-short-notify-chat

💰 Lesson 16 — Cost, trade-offs & ADRs: every box has a bill and a reason

📍 You are here: Lesson 16 of 18 · Next: lesson-17-designs-short-notify-chat

📦 What's in this branch

Lessons 01–15, plus the last two questions for every box: what does it cost? and why is it here? You build a first bill with example prices, find what dominates it, keep a trade-off table, and write an ADR (Architecture Decision Record): context, decision, consequences, status — and learn when one is worth writing.

design/designs.py — PRICE, monthly_cost(...) and adr(...)
design/demo.py — python3 design/demo.py cost
design/test_design.py — check L16

🧒 Explain like I'm 5

The plan is on the wall. The head of the school walks in and asks two questions.

"How much will it cost each month?" Katrina adds it up line by line: the servers, the storage, the data sent out, the requests. $1,216 a month, with example prices. The largest line is not the servers. It is the data sent out to parents' phones.

"And why is there a Redis box?" Nobody remembers. Aishwarya left the office last year. So Dipika makes a rule: every big decision gets one page in a folder. What was the problem? What did we choose? What does it cost us? Is it still true? Next year, a new planner reads the page in two minutes instead of guessing.

🗺️ Diagram

flowchart LR
    subgraph bill["🧾 a first bill (example prices)"]
      s["servers $360"]
      st["storage $46"]
      e["egress $450 ← largest"]
      r["requests $360"]
      t["total $1,216 / month"]
    end
    bill --> tt["⚖️ trade-off table<br/>option · gain · cost · risk"]
    tt --> adr["📄 ADR 001<br/>Status · Context · Decision · Consequences"]
    adr --> repo["📁 docs/adr/ in the repo"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l16

❓ What

A first cost model — the four lines that most designs are made of: compute (servers, containers, functions), storage (GB per month), egress (GB sent out to the internet), requests (per million calls to a managed service). Multiply the numbers from lesson 02 by a price, and add. Prices here are examples only — use the provider's pricing page or calculator before you commit money.
What dominates — one line is usually much bigger than the others. Find it, and spend your design effort there. Read-heavy apps often pay most for egress; video certainly does (lesson 18); a chat app pays for connections; an AI app pays for tokens.
Cost moves with the design — a cache (lesson 05) cuts database size; a CDN changes the egress price; a queue (lesson 07) lets you run fewer, busier workers.
The trade-off table — for each real choice, a small table: the options, what each one gains, what it costs (money, latency, people, risk). The habit matters more than the format: never one option alone. "We chose X" means nothing without "instead of Y".
ADR (Architecture Decision Record) — one short Markdown page per decision:
- Status — Proposed, Accepted, Deprecated, or Superseded by ADR n;
- Context — the forces: numbers, requirements, constraints, at the time;
- Decision — what we will do, in one or two sentences;
- Consequences — the good and the bad that follow. ADRs are numbered, kept in the repo next to the code, and never rewritten — a new ADR supersedes an old one.
When to write one — when a decision is hard to reverse (a database, a cloud, a protocol), costly (a new line on the bill), surprising (someone will later ask "why?"), or argued about for more than a day. Not for small, easy-to-change choices.

🤔 Why

Because a design that nobody can pay for is not a design, and a design nobody can explain is not maintained. Numbers from lesson 02 give each box a price. The ADR keeps the reason next to the price, so a later change is made with the facts — not by deleting a box that looked useless and was in fact holding up the p99.

🔧 How (in this repo)

In design/designs.py:

PRICE = dict(server_month=60, gb_month=0.023, egress_gb=0.09, request_million=0.40) — example prices.
monthly_cost(servers, storage_gb, egress_gb, requests_million) returns each line and the total.
adr(number, title, context, decision, consequences, status="Accepted") returns the Markdown page.

cost() in design/demo.py prices the notice board (6 servers, 2,000 GB, 5,000 GB egress, 900 million requests) and writes ADR 001 about the Redis cache.

🧪 Try it

python3 design/demo.py cost
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from designs import monthly_cost, adr
base = dict(servers=6, storage_gb=2_000, egress_gb=5_000, requests_million=900)
for name, change in (("first bill", {}), ("double the servers", {"servers": 12}), ("photos: 10x egress", {"egress_gb": 50_000}), ("5 years of storage", {"storage_gb": 11_000})):
    c = monthly_cost(**{**base, **change}); big = max((k for k in c if k != "total"), key=c.get)
    print(f"{name:<20} total ${c['total']:>9,.2f} · biggest part: {big} ${c[big]:,.2f}")
print(adr(2, "Send urgent notices by SMS through a queue", "5M parents; SMS must not slow the post request.",
          "Post writes one job to a queue; 50 workers send in batches.", ["post answers in ~50 ms", "SMS may arrive minutes later", "workers must be idempotent"], status="Proposed"))
EOF

✅ Verify — what you should see

cost prints:

── a first bill for the notice board (example prices)
   servers   $   360.00
   storage   $    46.00
   egress    $   450.00
   requests  $   360.00
   total     $ 1,216.00
── the decision, written down:
   # ADR 001: Cache the class feed in Redis

   Status: Accepted

   ## Context
   Reads are 100x writes; p99 must stay under 200 ms at 3x peak.

   ## Decision
   Cache-aside per class, TTL 60 s, delete on post.

   ## Consequences
   - ~80% of reads skip the database (lesson 05's curve)
   - a notice can be up to 60 s late for some readers
   - one more thing to run

Your snippet prints:

first bill           total $ 1,216.00 · biggest part: egress $450.00
double the servers   total $ 1,576.00 · biggest part: servers $720.00
photos: 10x egress   total $ 5,266.00 · biggest part: egress $4,500.00
5 years of storage   total $ 1,423.00 · biggest part: egress $450.00
# ADR 002: Send urgent notices by SMS through a queue

Status: Proposed

## Context
5M parents; SMS must not slow the post request.

## Decision
Post writes one job to a queue; 50 workers send in batches.

## Consequences
- post answers in ~50 ms
- SMS may arrive minutes later
- workers must be idempotent

The tests include ✅ L16 the bill adds up and the ADR has its sections.

🏁 What you just proved

The first bill is $1,216 a month, and the biggest line is egress ($450), not the servers. Doubling the servers adds $360. Five years of storage (11,000 GB — lesson 02's ~11 TB) adds only $207. But letting parents download photos (10× egress) makes the bill $5,266 — one product idea changed the cost more than every server decision together. That is the reason for a cost line in every design. And an ADR is short: status, context, decision, and consequences that include the bad ones ("SMS may arrive minutes later").

⚠️ Common mistakes

pricing only the servers and forgetting egress, requests, logs and backups
trusting example prices (including the ones here) — prices change by region and over time
optimising a small line (storage, $46) while the large one (egress) grows
ADRs that list only good consequences — then they are advertisements, not records
editing an old ADR when the decision changes — write a new one that supersedes it
ADRs in a wiki nobody finds — keep them in the repo, next to the code they explain
an ADR for every small choice — nobody reads 300 of them

🏭 In production

On a real account — see what the bill really is, per service, for last month:

aws ce get-cost-and-usage --time-period Start=2026-08-01,End=2026-09-01 \
    --granularity MONTHLY --metrics UnblendedCost \
    --group-by Type=DIMENSION,Key=SERVICE

A monthly budget with an email at 80% of the forecast:

aws budgets create-budget --account-id 111122223333 \
    --budget '{"BudgetName":"notice-board","BudgetLimit":{"Amount":"1500","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
    --notifications-with-subscribers '[{"Notification":{"NotificationType":"FORECASTED","ComparisonOperator":"GREATER_THAN","Threshold":80},"Subscribers":[{"SubscriptionType":"EMAIL","Address":"planning-office@school.example"}]}]'

Tag every resource with the part of the design it belongs to, so the bill can be split the same way as the diagram (activate the tag as a cost allocation tag):

aws resourcegroupstaggingapi tag-resources \
    --resource-arn-list arn:aws:rds:ap-south-1:111122223333:db:notices-db \
    --tags component=notices-db,app=notice-board

ADRs as files in the repo, numbered:

docs/adr/
  0001-cache-the-class-feed-in-redis.md
  0002-send-urgent-notices-by-sms-through-a-queue.md
  0003-postgresql-as-the-main-store.md

🏭 Why this matters in production: review the real bill against the plan's bill every month for the first quarter. A line that is twice the estimate is a design question — and the answer is often an ADR.

⏭️ Next

The method is complete: requirements, numbers, API, data, blocks, failure, security, observability, cost, ADRs. Now use it end to end. Worked designs: URL shortener, notifications and chat.

git checkout lesson-17-designs-short-notify-chat

← Previousobservability Next →designs short notify chat

This page is the lesson's README from the lesson-16-cost-and-adrs branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.