WisarWisar
Dasturlash kitobi/15-QISM — Kasbiy konikmalar49 daqiqa

15.7-bob: System Design intervyu

15-QISM — Kasbiy ko'nikmalar · 7-mavzu

1. Kirish va motivatsiya

Yaxshi kompaniyalar (ayniqsa senior daraja) ish suhbatida system design (tizim loyihalash) savolini berishadi: "URL qisqartiruvchi (bit.ly) qanday quriladi?", "Instagram feed'ini qanday loyihalaysiz?", "millionlab foydalanuvchi uchun chat tizimi?". Bu savollar bitta to'g'ri javobga ega emas — ular sizning fikrlash usulingizni sinaydi: katta, noaniq muammoni qanday bo'laklarga bo'lasiz, qanday savol berasiz (talablar), qanday qaror qabul qilasiz (trade-off), va qanday miqyoslaysiz (millionlab foydalanuvchi). Bu — kod yozish emas (algoritm savoli — 3-QISM — alohida), balki arxitektura (9-QISM) va kommunikatsiya (g'oyani tushuntirish).

System design qiyin ko'rinadi (katta, noaniq — "qaerdan boshlayman?"), lekin u tizimli usul bilan hal qilinadi (xuddi debugging — 15.5 — metodologiya): talablarni aniqla asosiy komponentlarni chiz ma'lumotni loyihala miqyosla muhokama qil. Bu bobda aynan shu usulni va asosiy tushunchalarni (load balancer, kesh, DB, queue — ko'pini 5, 6, 9, 10 QISMda ko'rgansiz) ko'ramiz. System design — senior daraja intervyusining markazi, va u real ishda ham foydali (katta tizimni loyihalash — har kun emas, lekin muhim qaror — arxitektura).

Bu bob: system design nima va nega (intervyu maqsadi), yondashuv (qadamlar — talablar komponentlar miqyos), asosiy tushunchalar (load balancer, kesh, DB, replikatsiya, queue), miqyoslash (vertikal/gorizontal, sharding), trade-off (CAP, izchillik vs mavjudlik), misol dizayn (URL qisqartiruvchi, Twitter feed, chat, rate limiter), va intervyu strategiyasi. System Design intervyu qamrovini to'liq ochamiz.

O'xshatish: System design — bu shahar arxitektori (bitta uy emas — butun shahar). Sizga "shahar loyihala" deyilsa (system design savoli) — bir uy chizish (kod) emas, balki: aholi qancha (talablar — necha foydalanuvchi)? Yo'llar qanday (trafik — load balancer)? Suv, elektr (resurslar — DB, kesh)? O'ssa qanday kengaytirasiz (miqyos — ko'p qavat yoki ko'p bino)? Trade-off (markazlashgan vs tarqoq — CAP). Yaxshi arxitektor avval savol beradi (aholi? byudjet? — talablar), keyin katta rejani chizadi (asosiy bloklar), keyin detallashtiradi (kerakli joyda). System design ham shunday: avval talablar (savol), keyin katta rasm (komponentlar), keyin chuqurlashtirish (miqyos, trade-off). Intervyuer sizning fikrlashingizni ko'radi (qanday yondashasiz — savol, struktura, qaror) — mukammal javob emas (bitta to'g'ri javob yo'q — usul muhim).

Nega muhim?

  • Senior intervyu — system design senior daraja suhbatining markazi (algoritm + system design + kod).
  • Fikrlash usuli — katta muammoni bo'laklash, savol berish, qaror (bilim emas — usul).
  • Real ish — katta tizim arxitekturasi (muhim qaror — har kun emas, lekin kritik).
  • Kommunikatsiya — g'oyani tushuntirish (15.6 — texnik kommunikatsiya).

2. Nazariya — chuqur tushuntirish

2.1. System design nima (intervyu maqsadi)

text
  SYSTEM DESIGN — katta tizimni loyihalash (intervyu — fikrlashni sinaydi):

  SAVOL TURLARI:
   "X qanday quriladi?" (URL qisqartiruvchi, Twitter, Uber, chat)
   ochiq, noaniq (bitta to'g'ri javob YO'Q — usul muhim)

  INTERVYUER NIMA KO'RADI (mukammal javob EMAS):
   Qanday YONDASHASIZ (struktura — talablar  komponent  miqyos)
   SAVOL BERASIZmi (talablar aniqlash — taxmin emas)
   TRADE-OFF (qaror sabablari — nega bu, nega u emas)
   MIQYOS (millionlab foydalanuvchi — qanday)
   KOMMUNIKATSIYA (g'oyani tushuntirish — chiz, gapir)

  SYSTEM DESIGN ≠ ALGORITM (3-QISM):
   algoritm — aniq javob (kod — to'g'ri/noto'g'ri)
   system design — ochiq (arxitektura — trade-off, usul)

   System design — katta tizim loyihalash (ochiq — usul/fikrlash, mukammal javob emas)
   Intervyuer — yondashuv + savol + trade-off + miqyos + kommunikatsiya (bilim emas — usul)

System design nima (intervyu maqsadi) — system design savollarining mohiyati. System design — katta tizimni loyihalash (intervyu kontekstida — fikrlashni sinaydi). Savol turlari: "X qanday quriladi?" (URL qisqartiruvchi — bit.ly, Twitter feed, Uber, chat tizimi) — ochiq, noaniq savollar (bitta "to'g'ri" javob yo'q — har xil yechim mumkin — usul muhim). Intervyuer nima ko'radi (mukammal javob emas — fikrlashni): (1) qanday yondashasiz (struktura — talablar komponent miqyos — 2.2 — tizimli usulmi yoki chalkash); (2) savol berasizmi (talablar aniqlash — "necha foydalanuvchi? qanday xususiyat?" — taxmin emas — aniqlash); (3) trade-off (qaror sabablari — "SQL yoki NoSQL? — nega" — har qaror sababli); (4) miqyos (millionlab foydalanuvchi — qanday — vertikal/gorizontal, kesh, sharding); (5) kommunikatsiya (g'oyani tushuntirish — chiz (diagram), gapir — 15.6 — fikringizni yetkazish). System design ≠ algoritm (3-QISM): algoritm — aniq javob (kod — to'g'ri/noto'g'ri — optimal yechim bor); system design — ochiq (arxitektura — trade-off, ko'p yechim — usul, mukammallik emas). Ikki nuqta: (1) system design — katta tizim loyihalash (ochiq — usul/fikrlash sinaydi, mukammal javob emas — bitta to'g'ri yo'q); (2) intervyuer — yondashuv + savol + trade-off + miqyos + kommunikatsiya (bilim emas — usul). System design intervyu — fikrlash testi (qanday katta, noaniq muammoni hal qilasiz — struktura, savol, qaror). Ko'p nomzod xato qiladi — darrov detalga sho'ng'idi (kod, aniq texnologiya) — talablarsiz, strukturasiz. To'g'ri — usul (talablar katta rasm detal — 2.2). Intervyuer "to'g'ri javob"ni emas (yo'q), jarayonni ko'radi (qanday o'ylaysiz — yondashuv, savol, trade-off). Bu — senior daraja ko'nikmasi (katta tizim — arxitektura — kommunikatsiya). Mukammal javob shart emas (ochiq savol — vaqt cheklangan) — yaxshi usul (struktura, savol, qaror) muhim.

2.2. Yondashuv (qadamlar)

text
  SYSTEM DESIGN YONDASHUVI (qadamlar — tizimli usul):

  1. TALABLARNI ANIQLA (savol ber — taxmin EMAS):
   Funksional: nima qiladi? (URL qisqartir, redirect, statistika?)
   Funksional bo'lmagan: miqyos? (necha foydalanuvchi, so'rov/sek?)
   cheklovlar (latency, izchillik?)

  2. MIQYOSNI BAHOLA (taxminiy hisob):
   necha foydalanuvchi/so'rov? (1M/kun  ~12/sek o'qish)
   ma'lumot hajmi? (1M URL/kun × 100 bayt  ...)

  3. ASOSIY API (interfeys):
   shorten(url)  shortUrl | redirect(shortUrl)  url

  4. MA'LUMOT MODELI (DB):
   URL: { shortCode, longUrl, createdAt, clicks }

  5. YUQORI DARAJALI DIZAYN (komponentlar — chiz):
   Client  Load Balancer  App Server  Cache  DB

  6. MIQYOSLASH (chuqurlashtirish):
   kesh, replikatsiya, sharding 2.4-bob — bottleneck'larni hal

  7. TRADE-OFF (muhokama):
   qaror sabablari, muqobillar

   Yondashuv — talablar  miqyos baho  API  ma'lumot  dizayn  miqyos  trade-off
   Avval TALABLAR (savol ber); keyin katta rasm; keyin chuqurlashtirish (detalga sho'ng'ima)

Yondashuv (qadamlar) — system design'ning tizimli usuli. Yetti qadam (struktura — chalkash emas): (1) talablarni aniqla (savol ber — taxmin emas): funksional (nima qiladi? — URL qisqartir, redirect, statistika?), funksional bo'lmagan (miqyos? — necha foydalanuvchi, so'rov/sek?), cheklovlar (latency — tez? izchillik — darrov?); (2) miqyosni baho (taxminiy hisob — "back of envelope"): necha foydalanuvchi/so'rov? (1M/kun ~12/sek o'qish — o'rtacha), ma'lumot hajmi? (1M URL/kun × 100 bayt × 365 kun yillik); (3) asosiy API (interfeys — shorten(url) shortUrl, redirect(shortUrl) url); (4) ma'lumot modeli (DB — URL: { shortCode, longUrl, createdAt, clicks }); (5) yuqori darajali dizayn (komponentlar — chiz — diagram: Client Load Balancer App Server Cache DB — katta rasm); (6) miqyoslash (chuqurlashtirish — kesh, replikatsiya, sharding — 2.4 — bottleneck'larni hal); (7) trade-off (muhokama — qaror sabablari, muqobillar). Ikki nuqta: (1) yondashuv — talablar miqyos baho API ma'lumot dizayn miqyos trade-off (tizimli ketma-ketlik); (2) avval talablar (savol ber — taxmin qilma), keyin katta rasm (komponentlar), keyin chuqurlashtirish (detalga sho'ng'ima boshida — avval umumiy). Bu yondashuv — system design'ning "retsepti" (chalkash emas — struktura). Eng muhim — talablar (1-qadam — savol ber — "necha foydalanuvchi? qanday xususiyat?" — taxmin emas — chunki talablar dizaynni belgilaydi — 100 foydalanuvchi vs 1 milliard — butunlay boshqa dizayn). Eng keng xato — talablarsiz darrov dizaynga (detalga sho'ng'ish — "Redis ishlataman" — nega? talablar nima?). To'g'ri — talablar (aniqla) miqyos (baho) katta rasm (komponent) chuqur (miqyos). Bu struktura intervyuda ham (qanday yondashasiz — ko'rsatadi) va real ishda ham (katta tizim loyihalash usuli). Vaqt boshqaruvi — talablar (5 daq), katta rasm (10 daq), chuqur (15 daq), trade-off (5 daq) — taxminiy.

2.3. Asosiy tushunchalar (load balancer, kesh, DB)

text
  ASOSIY KOMPONENTLAR (system design qurilish bloklari):

  1. LOAD BALANCER (yuk taqsimlovchi — 10.7):
   so'rovni ko'p server'ga taqsimla (bir server tugamasin)
   gorizontal miqyos (server qo'shish — 2.4)

  2. KESH (Redis — 5.21, 13.7):
   tez-tez so'raladigan ma'lumot xotirada (DB'dan tez)
   DB yukini kamaytir (mashhur URL — keshdan)

  3. DATABASE (6-QISM):
   SQL (izchil, JOIN — relyatsion) vs NoSQL (miqyos, moslashuvchan)
   replikatsiya (nusxa — o'qish miqyos), sharding (bo'lish — 2.4)

  4. MESSAGE QUEUE (BullMQ/Kafka — 5.22, 9-QISM):
   asinxron ish (email, statistika — keyin — so'rovni bloklamasin)

  5. CDN 13.7-bob:
   statik kontent (rasm, fayl) foydalanuvchiga yaqin

  6. API GATEWAY (9-QISM):
   so'rov kirish nuqtasi (auth, rate limit, routing)

   Bloklar — load balancer (taqsim), kesh (tez), DB (saqlash), queue (asinxron), CDN
   Ko'pini bilasiz (5,6,9,10 QISM) — system design'da birlashtirib ishlatish

Asosiy tushunchalar (load balancer, kesh, DB) — system design qurilish bloklari. Asosiy komponentlar (ko'pini oldingi QISMlarda ko'rgansiz — system design'da birlashtirib ishlatish): (1) load balancer (yuk taqsimlovchi — 10.7): so'rovni ko'p server'ga taqsimlaydi (bir server hammasini ko'tarmasin — yuk teng) — gorizontal miqyos (server qo'shish — 2.4); (2) kesh (Redis — 5.21, 13.7): tez-tez so'raladigan ma'lumot xotirada (DB'dan tez — millisekund) — DB yukini kamaytiradi (mashhur ma'lumot — masalan mashhur URL — keshdan — DB'ga bormaydi); (3) database (6-QISM): SQL (izchil, JOIN — relyatsion — 6.4) vs NoSQL (miqyos, moslashuvchan — 6.2) — tanlov (trade-off — 2.5); replikatsiya (DB nusxasi — o'qish miqyosi — ko'p o'qish nusxaga), sharding (DB'ni bo'lish — 2.4); (4) message queue (BullMQ/Kafka — 5.22, 9-QISM): asinxron ish (email, statistika hisoblash — keyin — so'rovni bloklamasin — foydalanuvchi kutmaydi — 13.5: 2.8); (5) CDN 13.7-bob: statik kontent (rasm, video, fayl) foydalanuvchiga yaqin (tez — 13.7: 2.7); (6) API Gateway (9-QISM): so'rov kirish nuqtasi (auth, rate limit — 14.8, routing — markaziy). Ikki nuqta: (1) bloklar — load balancer (taqsim), kesh (tez), DB (saqlash), queue (asinxron), CDN (statik), gateway (kirish); (2) ko'pini bilasiz (5, 6, 9, 10 QISM — backend, DB, arxitektura, DevOps), system design'da birlashtirib ishlatish (har blok — muammoning bir qismi). Bu bloklar — system design'ning "lego qismlari" (har savol — ularni birlashtirish — qaysi kerak, qanday ulanadi). Misol: URL qisqartiruvchi — load balancer (ko'p so'rov) + kesh (mashhur URL — tez redirect) + DB (URL saqlash) + (statistika — queue — asinxron). System design — bu bloklarni to'g'ri birlashtirish (talab — qaysi blok — qanday). Har blokni nega ishlatishni bilish (kesh — tezlik; queue — asinxron; load balancer — miqyos) — system design'ning asosi. Bu QISMlar (5, 6, 9, 10) bu bloklarni o'rgatdi — system design — ularni katta tizimda birlashtirish.

2.4. Miqyoslash (scaling)

text
  MIQYOSLASH — tizimni ko'p foydalanuvchi/yukka moslashtirish:

  VERTIKAL vs GORIZONTAL:
   VERTIKAL (scale up): kuchliroq server (ko'proq CPU/RAM) — oson, lekin chegara
   GORIZONTAL (scale out): ko'proq server (load balancer bilan) — cheksiz, lekin murakkab
   odatda gorizontal (cheksiz miqyos — server qo'shaver)

  DATABASE MIQYOSLASH:
   REPLIKATSIYA (nusxa): o'qish nusxalari (read replica) — ko'p o'qish
   SHARDING (bo'lish): ma'lumotni serverlarga bo'l (user A-M  server1, N-Z  server2)
   o'qish/yozish ajratish (CQRS — 9-QISM)

  KESH MIQYOSLASH (yukni kamaytir):
   tez-tez so'raladigan  keshdan (DB'ga bormasin)
   kesh strategiyasi 13.7-bob

  ASINXRON (yukni keyinga):
   og'ir ish (email, hisobot)  queue  keyin (so'rovni bloklamasin)

   Miqyos — vertikal (kuchli server) vs gorizontal (ko'p server — afzal, cheksiz)
   DB — replikatsiya (o'qish), sharding (bo'lish); kesh (yuk kamaytir); queue (asinxron)

Miqyoslash (scaling) — tizimni ko'p foydalanuvchi/yukka moslashtirish (system design'ning markaziy savoli — "millionlab foydalanuvchi uchun"). Vertikal vs gorizontal: (1) vertikal (scale up — kuchliroq server — ko'proq CPU/RAM — bir kuchli mashina): oson (faqat server kuchaytir), lekin chegara (bir mashina cheklangan — eng kuchli ham yetmasligi mumkin) va qimmat; (2) gorizontal (scale out — ko'proq server — load balancer bilan taqsimlash — 2.3): cheksiz (server qo'shaver — 10, 100, 1000), lekin murakkabroq (taqsimlash, izchillik); odatda gorizontal afzal (cheksiz miqyos — katta tizim). Database miqyoslash (ko'pincha bottleneck — DB): (1) replikatsiya (nusxa — read replica — o'qish nusxalari — ko'p o'qish so'rovini nusxalardan — yozish asosiyga — o'qish miqyosi); (2) sharding (bo'lish — ma'lumotni serverlarga bo'l — masalan user A-M server1, N-Z server2 — har server qismda — yozish miqyosi); (3) o'qish/yozish ajratish (CQRS — 9-QISM). Kesh miqyoslash (yukni kamaytir): tez-tez so'raladigan keshdan (DB'ga bormasin — yuk kamayadi — 13.7). Asinxron (yukni keyinga): og'ir ish (email, hisobot — 13.5: 2.8) queue keyin (so'rovni bloklamasin — foydalanuvchi tez javob). Ikki nuqta: (1) miqyos — vertikal (kuchli server — oson, chegara) vs gorizontal (ko'p server — afzal, cheksiz); (2) DB — replikatsiya (o'qish miqyos), sharding (bo'lish — yozish miqyos), kesh (yuk kamaytir), queue (asinxron). Miqyoslash — system design'ning "millionlab foydalanuvchi" javobi (qanday ko'p yukka chidaydi). Bottleneck (tor joy — eng zaif qism — odatda DB) topish va miqyoslash (kesh — DB yukini kamaytir; replikatsiya — o'qish; sharding — yozish). Gorizontal (ko'p server — cheksiz) — zamonaviy miqyos (cloud — auto-scaling — 10.10). Misol: URL qisqartiruvchi millionlab foydalanuvchi — load balancer (ko'p app server — gorizontal) + kesh (mashhur URL — DB yuk kamaytir) + DB replikatsiya (ko'p o'qish — redirect). Miqyoslash — trade-off bilan (gorizontal — cheksiz, lekin izchillik murakkab — 2.5 CAP). Bu — system design'ning eng muhim qismi (katta yuk — qanday).

2.5. Trade-off va CAP teoremasi

text
  TRADE-OFF — har qaror SABABLI (mukammal yo'q — kompromis):

  HAR QARORDA TRADE-OFF:
   SQL vs NoSQL (izchillik vs miqyos)
   kesh (tez, lekin eskirgan bo'lishi mumkin — 13.7)
   replikatsiya (o'qish miqyos, lekin izchillik kechikishi)
   "eng yaxshi" yo'q — KONTEKSTga mos (talablarga qarab)

  CAP TEOREMASI (taqsimlangan tizim — uchtadan IKKITAsi):
   C (Consistency — izchillik): har o'qish eng yangi ma'lumot
   A (Availability — mavjudlik): har so'rov javob oladi
   P (Partition tolerance — bo'linishga chidamlilik): tarmoq uzilsa ishlaydi
   P MAJBURIY (taqsimlangan)  C yoki A tanlash:
    CP (izchil, lekin ba'zan javob yo'q — bank) | AP (doimo javob, lekin eskirgan — feed)

  ESLAB QOL:
   bank (to'lov)  izchillik (CP — noto'g'ri balans yomon)
   ijtimoiy feed  mavjudlik (AP — biroz eskirgan OK)

   Trade-off — har qaror kompromis (mukammal yo'q — kontekstga mos, sababli)
   CAP — taqsimlangan tizim C/A/P uchtadan ikkita; P majburiy  CP yoki AP

Trade-off va CAP teoremasi — system design'ning qaror falsafasi. Trade-off — har qaror sababli (mukammal yechim yo'q — har birida afzallik va kamchilik — kompromis). Har qarorda trade-off: SQL vs NoSQL (izchillik/JOIN vs miqyos/moslashuvchanlik — 6.1), kesh (tez, lekin ma'lumot eskirgan bo'lishi mumkin — 13.7), replikatsiya (o'qish miqyosi, lekin izchillik kechikishi — nusxa biroz orqada), monolit vs mikroservis (9-QISM — soddalik vs miqyos) — "eng yaxshi" yo'q — kontekstga mos (talablarga qarab — tezlik kerakmi izchillikmi). CAP teoremasi (taqsimlangan tizimning asosiy qonuni — uchtadan ikkitasini tanlash mumkin): (1) C (Consistency — izchillik): har o'qish eng yangi ma'lumotni qaytaradi (barcha nusxa bir xil); (2) A (Availability — mavjudlik): har so'rov javob oladi (tizim doimo ishlaydi); (3) P (Partition tolerance — bo'linishga chidamlilik): tarmoq uzilsa (serverlar orasida) tizim ishlaydi. P majburiy (taqsimlangan tizim — tarmoq uzilishi muqarrar) C yoki A tanlash: CP (izchil, lekin tarmoq uzilsa ba'zan javob yo'q — masalan bank — noto'g'ri balans ko'rsatishdan javob bermaslik yaxshiroq); AP (doimo javob, lekin ba'zan eskirgan ma'lumot — masalan ijtimoiy feed — biroz eski post OK, lekin doimo ishlasin). Ikki nuqta: (1) trade-off — har qaror kompromis (mukammal yo'q — kontekstga mos, sababli — "nega bu" tushuntir); (2) CAP — taqsimlangan tizim C/A/P uchtadan ikkita, P majburiy CP (izchil — bank/to'lov) yoki AP (mavjud — feed/ijtimoiy). Trade-off — system design'ning yuragi (intervyuda — har qarorga "nega?" — sababli — 2.1; real ishda — har arxitektura qarori kompromis). CAP — taqsimlangan tizim trade-off'i (izchillik vs mavjudlik — kontekstga qarab — bank izchil, feed mavjud). Mukammal tizim yo'q (har qaror — afzallik + kamchilik) — system design — to'g'ri kompromis (talabga mos). Intervyuda trade-off ko'rsatish muhim (qaror — sababli, muqobil bilan — "SQL chunki izchillik kerak, lekin NoSQL ham mumkin agar miqyos muhim bo'lsa"). Bu — yetuk fikrlash (mukammal javob emas — kompromis va sabab). CAP — klassik (intervyuda so'rashadi — izchillik vs mavjudlik).

2.6. Misol dizayn: URL qisqartiruvchi

text
  MISOL: URL QISQARTIRUVCHI (bit.ly) — yondashuv amalda:

  1. TALABLAR:
   uzun URL  qisqa kod; qisqa  redirect; statistika (clicks)
   miqyos: 100M URL, 100:1 o'qish:yozish (ko'p redirect)

  2. API:
   POST /shorten { longUrl }  { shortUrl }
   GET /{code}  redirect (301)

  3. MA'LUMOT:
   URL: { shortCode (PK), longUrl, createdAt, clicks }

  4. QISQA KOD GENERATSIYA (asosiy savol):
   counter + base62 (0-9a-zA-Z — 62 belgi) yoki hash
   7 belgi base62 = 62^7 ≈ 3.5 trillion (yetarli)

  5. DIZAYN:
  Client  Load Balancer  App Server  Cache (Redis)  DB
                                           mashhur URL keshda (tez redirect)

  6. MIQYOS:
   kesh (mashhur URL — DB yuk kamaytir); DB replikatsiya (ko'p o'qish)
   statistika  queue (asinxron — redirect'ni bloklamasin)

  7. TRADE-OFF: NoSQL (miqyos, oddiy key-value) yoki SQL (izchil)

   Misol — talablar  API  ma'lumot  kod generatsiya  dizayn  miqyos  trade-off
   Har system design savoli shu usulda (struktura — 2.2)

Misol dizayn: URL qisqartiruvchi — yondashuv amalda (2.2 — to'liq misol). URL qisqartiruvchi (bit.ly — eng keng system design savoli — sodda, lekin barcha tushunchani qamraydi): (1) talablar — uzun URL qisqa kod, qisqa redirect, statistika (clicks); miqyos — 100M URL, 100:1 o'qish:yozish (ko'p redirect, kam yaratish — o'qishga optimallashtir); (2) API — POST /shorten { longUrl } { shortUrl }, GET /{code} redirect (301); (3) ma'lumot — URL: { shortCode (primary key), longUrl, createdAt, clicks }; (4) qisqa kod generatsiya (asosiy texnik savol) — counter + base62 (0-9, a-z, A-Z — 62 belgi) yoki hash; 7 belgi base62 = 62^7 ≈ 3.5 trillion (yetarli — ko'p URL); (5) dizayn — Client Load Balancer App Server Cache (Redis) DB (mashhur URL keshda — tez redirect — ko'p o'qish keshdan); (6) miqyos — kesh (mashhur URL — DB yuk kamaytir — 2.4), DB replikatsiya (ko'p o'qish — redirect — read replica), statistika queue (asinxron — redirect'ni bloklamasin — 2.4); (7) trade-off — NoSQL (miqyos, oddiy key-value — shortCode longUrl — 6.1) yoki SQL (izchil — 2.5). Ikki nuqta: (1) misol — talablar API ma'lumot kod generatsiya dizayn miqyos trade-off (yondashuv — 2.2 — to'liq); (2) har system design savoli shu usulda (struktura — 2.2 — URL, Twitter, chat — bir xil usul, har xil detal). Bu misol — system design yondashuvining amaliy ko'rinishi (talablardan trade-off'gacha — 7 qadam). Qisqa kod generatsiya — URL qisqartiruvchining asosiy texnik savoli (base62 — 62 belgi — qisqa, ko'p kombinatsiya; counter — ketma-ket, yoki hash — tasodifiy). 100:1 o'qish:yozish — muhim talab (o'qishga optimallashtir — kesh, read replica — redirect ko'p). Kesh — kalit (mashhur URL — millionlab redirect — keshdan — DB yengil). Bu misolni o'rganish (yondashuv + tushunchalar) — boshqa system design savollariga ham (Twitter feed, Instagram, chat — bir xil usul: talablar komponent miqyos trade-off). System design — usul 2.2-bob + tushunchalar (2.3, 2.4, 2.5) + amaliyot (misol — bu). Mashq — ko'p misol yechish (URL, Twitter, Uber, chat — har birini usul bilan).

2.7. Intervyu strategiyasi va best practices

text
  SYSTEM DESIGN INTERVYU STRATEGIYASI:

  STRATEGIYA (45-60 daqiqa):
  1. TALABLAR aniqla (5-10 daq — savol ber, taxmin emas)
  2. KATTA RASM (10-15 daq — komponentlar, chiz)
  3. CHUQURLATIR (15-20 daq — bir-ikki qismni — miqyos, detal)
  4. TRADE-OFF / muhokama (5-10 daq)

  BEST PRACTICES:
   SAVOL ber (talablar — taxmin emas — 2.2)
   Ovoz chiqarib o'yla (fikrni gapir — intervyuer ko'rsin — 15.6)
   CHIZ (diagram — komponentlar — vizual)
   Sodda boshla (oddiy dizayn  keyin miqyos — over-engineer emas)
   Trade-off ayt (har qaror sababli — 2.5)
   Hamkorlik (intervyuer bilan — savol, fikr — dialog)
   Darrov detalga sho'ng'ima (avval katta rasm)

  TAYYORGARLIK:
   mashq (URL, Twitter, chat, Uber — ko'p misol)
   tushunchalar (load balancer, kesh, DB, queue — 2.3)
   "System Design Interview" kitoblar; real tizimlar (qanday ishlaydi)

   Strategiya — talablar  katta rasm  chuqur  trade-off (vaqt boshqaruvi)
   Best — savol, ovoz chiqarib, chiz, sodda boshla, trade-off, hamkorlik

Intervyu strategiyasi va best practices — system design intervyuni muvaffaqiyatli o'tish. Strategiya (45-60 daqiqa — vaqt boshqaruvi): (1) talablar aniqla (5-10 daq — savol ber, taxmin emas — 2.2); (2) katta rasm (10-15 daq — komponentlar, chiz — diagram); (3) chuqurlashtir (15-20 daq — bir-ikki qismni — miqyos, detal — intervyuer qiziqqanini); (4) trade-off/muhokama (5-10 daq). Best practices: (1) savol ber (talablar — taxmin emas — 2.2 — eng muhim); (2) ovoz chiqarib o'yla (fikrni gapir — intervyuer fikrlashingizni ko'rsin — 15.6 — jim o'ylama — fikrni yetkaz); (3) chiz (diagram — komponentlar — vizual — system design vizual); (4) sodda boshla (oddiy dizayn keyin miqyos — over-engineer emas — 15.1: 2.8 — boshida murakkab dizayn xato); (5) trade-off ayt (har qaror sababli — 2.5 — "nega bu"); (6) hamkorlik (intervyuer bilan — savol, fikr — dialog — intervyuer yo'naltirishi mumkin — tingla); (7) darrov detalga sho'ng'ima (avval katta rasm — keyin detal). Tayyorgarlik: mashq (URL, Twitter, chat, Uber — ko'p misol — usulni mustahkamlash), tushunchalar (load balancer, kesh, DB, queue — 2.3 — bilim), "System Design Interview" kitoblar (Alex Xu), real tizimlar (qanday ishlaydi — Instagram, Twitter — texnik bloglar). Ikki nuqta: (1) strategiya — talablar katta rasm chuqur trade-off (vaqt boshqaruvi — 45-60 daq); (2) best — savol, ovoz chiqarib, chiz, sodda boshla, trade-off, hamkorlik. System design intervyu — fikrlash ko'rsatish (2.1 — mukammal javob emas — usul). Eng muhim — talablar (savol ber), struktura (usul — 2.2), ovoz chiqarib (fikrni yetkaz — 15.6), trade-off (qaror sababli — 2.5). Mashq kalit (system design — usul — ko'p misol yechib mustahkamlanadi — URL, Twitter, chat — har biri usul bilan). Hamkorlik — intervyuer dushman emas (yo'naltiradi, qiziqishini aytadi — tingla, moslash). System design — senior intervyu markazi (algoritm + system design + kod + behavioral). Bu kitob (9-QISM arxitektura, 5/6/10 QISM komponentlar) system design uchun asos (tushunchalar) berdi — system design — ularni intervyu usuli bilan birlashtirish. Bu ko'nikma real ishda ham (katta tizim arxitektura qarori — usul). Tayyorgarlik (mashq + tushunchalar) + strategiya (usul + best practices) — system design intervyu muvaffaqiyati.

2.8. Estimation (back-of-envelope) va latency raqamlari

text
  ESTIMATION — taxminiy hisob (2-qadam — 2.2 — "back of envelope"):

  NEGA HISOB: talablar  RAQAM  qaror (necha server, DB, kesh)
   aniq javob EMAS (taxminiy — o'nlik tartibi to'g'ri bo'lsa bas)

  QADAMLAR (hisob):
  1. FOYDALANUVCHI: DAU (kunlik faol) — masalan 100M
  2. QPS: so'rov/kun ÷ 86,400 sek ≈ o'rtacha QPS
      peak = o'rtacha × 2-3 (eng band vaqt)
  3. STORAGE: yozuv/kun × bir yozuv hajmi × yil × 365
  4. BANDWIDTH: QPS × javob hajmi (bayt/sek)
  5. KESH: mashhur 20% ma'lumot  xotira (80/20 qoidasi)

  FOYDALI YAXLITLASH:
   1 kun ≈ 86,400 sek ≈ 10^5 (yaxlit)
   1 million so'rov/kun ≈ 12/sek; 1 milliard/kun ≈ 12,000/sek
   10^6 = million, 10^9 = milliard, 10^12 = trillion

  LATENCY RAQAMLARI (har dasturchi bilishi kerak — tartibi):
   L1 kesh:              ~1 nanosek
   RAM (asosiy xotira):  ~100 nanosek
   SSD tasodifiy o'qish: ~100 mikrosek (100,000 ns)
   tarmoq (bir DC ichida): ~500 mikrosek (round-trip)
   HDD disk qidiruv:     ~10 millisek (10,000,000 ns)
   qit'alararo tarmoq:   ~150 millisek (round-trip)

  XULOSA (tartib): RAM >> SSD >> disk; xotira/kesh — disk/tarmoqdan
  ~10^3–10^6 marta tez  shu sababli KESH 2.3-bob kritik

   Estimation — DAU  QPS (peak ×2-3)  storage  bandwidth  kesh
   Latency: RAM (ns) << SSD (mikro) << disk/tarmoq (milli) — kesh nega tez

Estimation (back-of-envelope) va latency raqamlari — taxminiy hisob (2.2 — 2-qadam — "back of envelope estimation"). Nega hisob: talablar (necha foydalanuvchi) raqam (QPS, storage) qaror (necha server, qancha DB/kesh — 2.4). Bu aniq javob emas (taxminiy — o'nlik tartibi (order of magnitude) to'g'ri bo'lsa yetadi — 11,500/sek yoki 12,000/sek — muhim emas — "o'n minglab" ekani muhim). Qadamlar: (1) foydalanuvchi — DAU (Daily Active Users — kunlik faol foydalanuvchi — masalan 100M); (2) QPS (Queries Per Second — so'rov/sek) — so'rov/kun ÷ 86,400 ≈ o'rtacha QPS, peak = o'rtacha × 2-3 (eng band vaqt — kechqurun/hafta oxiri — dizayn peak'ga bardosh berishi kerak); (3) storage (saqlash) — yozuv/kun × bir yozuv hajmi × yil × 365 (masalan 100M tweet/kun × 300 bayt × 5 yil ≈ 55 TB); (4) bandwidth (o'tkazuvchanlik) — QPS × javob hajmi (bayt/sek — tarmoq yuki); (5) kesh — mashhur 20% ma'lumot 80% so'rovni beradi (80/20 qoidasi — Pareto) shu 20%ni keshga (xotira hajmi hisobla). Foydali yaxlitlash: 1 kun ≈ 86,400 sek ≈ 10^5 (yaxlit — hisob osonlashadi); 1 million so'rov/kun ≈ 12/sek; 1 milliard/kun ≈ 12,000/sek; 10^6 = million, 10^9 = milliard, 10^12 = trillion (kattaliklarni yaxlit tut). Latency raqamlari ("Latency Numbers Every Programmer Should Know" — mashhur ro'yxat — tartibini bilish kerak): L1 kesh ~1 ns, RAM ~100 ns, SSD tasodifiy o'qish ~100 mikrosek, tarmoq (bir data-center ichida round-trip) ~500 mikrosek, HDD disk qidiruv ~10 millisek, qit'alararo tarmoq (masalan AQShYevropa round-trip) ~150 millisek. Xulosa (tartib muhim, aniq raqam emas): RAM diskdan ~10^5 marta, SSD'dan ~10^3 marta tez; xotira/kesh disk/tarmoqdan minglab-millionlab marta tez — aynan shu sababli kesh 2.3-bob system design'da kritik (DB diskka boradi — sekin; kesh RAM'da — tez). Ikki nuqta: (1) estimation — DAU QPS (peak ×2-3) storage bandwidth kesh (80/20); (2) latency — RAM (ns) << SSD (mikrosek) << disk/tarmoq (millisek) — kesh nega tez (RAM), qit'alararo so'rov nega qochiladi (CDN — 2.3 — foydalanuvchiga yaqin). Intervyuda estimation — quruq raqam emas (aniq bo'lishi shart emas), balki kattalik hissi (100 foydalanuvchi vs 1 milliard — butunlay boshqa dizayn — 2.1). Baland ovoz hisobla ("100M DAU, har biri 10 so'rov/kun 1 mlrd/kun ~12,000/sek o'rtacha peak ~30,000/sek bir server 1000/sek qoldirsa 30+ server kerak — 2.4"). Bu hisob dizaynni asoslaydi (nega load balancer, nega kesh, nega sharding — raqam ko'rsatadi). Latency raqamlari — chuqurlashtirishda kerak (nega disk o'qishni keshga aylantirish 10^5 marta tez; nega bir data-center'da ushlab turish qit'alararodan yaxshi — 2.9 CDN). Aniq raqamlarni yodlash shart emas — tartibni (ns/mikro/milli farqi) his qilish muhim.

2.9. Mashhur savollar katalogi (yondashuv bilan)

text
  MASHHUR SYSTEM DESIGN SAVOLLARI (har biriga asosiy savol + kalit):

  URL QISQARTIRUVCHI (bit.ly) — 2.6:
   asosiy: qisqa kod generatsiya (base62), o'qish >> yozish
   kalit: kesh + read replica; 100:1 o'qish/yozish

  TWITTER/INSTAGRAM FEED — Misol 4:
   asosiy: feed generatsiya (fan-out — push vs pull)
   kalit: hybrid (oddiy push, mashhur pull); feed kesh

  CHAT (WhatsApp) — Misol 1:
   asosiy: real-time yetkazish (WebSocket), online holat, offline xabar
   kalit: WebSocket ulanish + gateway; xabar navbati (offline user)
   izchillik: xabar tartibi, "yetkazildi/o'qildi" belgi

  RATE LIMITER 14.8-bob — API cheklash:
   asosiy: so'rov sanash (foydalanuvchi/IP bo'yicha) — chegara oshsa rad
   kalit: token bucket / sliding window; Redis (taqsimlangan hisoblagich)

  NOTIFICATION (bildirishnoma) tizimi:
   asosiy: ko'p kanal (push/SMS/email), millionlab, ishonchli yetkazish
   kalit: queue (fan-out) + kanal ishchilari (worker); qayta urinish

  YOUTUBE/NETFLIX (video) — striming:
   asosiy: video saqlash + tarqatish (katta fayl), transkodlash
   kalit: CDN (video segment), blob storage, adaptiv bitrate

  UBER/YETKAZIB BERISH — joylashuv:
   asosiy: haydovchi-yo'lovchi mos (yaqin), real-time joylashuv
   kalit: geo-indeks (geohash/quadtree), joylashuv yangilash oqimi

   Har savolda ASOSIY savol boshqa (feed, real-time, geo, video) — usul BIR XIL
   Talablar  API  ma'lumot  asosiy savol  miqyos  trade-off (2.2 — hamma uchun)

Mashhur savollar katalogi (yondashuv bilan) — eng ko'p so'raladigan system design savollari, har biriga asosiy savol (tizimning yuragi — markaziy texnik qaror) va kalit (asosiy komponent). Yondashuv 2.2-bob barchasi uchun bir xil (talablar API ma'lumot asosiy savol miqyos trade-off) — faqat asosiy savol har birida boshqa. (1) URL qisqartiruvchi (bit.ly — 2.6): asosiy — qisqa kod generatsiya (base62), o'qish >> yozish; kalit — kesh + read replica (100:1 o'qish/yozish — o'qishga optimallashtir). (2) Twitter/Instagram feed (Misol 4): asosiy — feed generatsiya (fan-out — push vs pull); kalit — hybrid (oddiy user push — oldindan feed'ga tarqat, mashhur user pull — so'raganda), feed kesh. (3) Chat (WhatsApp) (Misol 1): asosiy — real-time yetkazish (WebSocket — doimiy ulanish — 12-QISM), online holat (presence), offline xabar (foydalanuvchi ulanmagan — saqlab qo'y, ulanganda yetkaz); kalit — WebSocket ulanishlar + connection gateway (qaysi user qaysi serverda), xabar navbati; izchillik — xabar tartibi (yozilgan tartibda), "yetkazildi/o'qildi" belgisi. (4) Rate limiter (14.8 — API cheklash): asosiy — so'rov sanash (foydalanuvchi yoki IP bo'yicha — chegara — masalan 100 so'rov/daqiqa — oshsa 429 rad); kalit — token bucket yoki sliding window algoritmi, Redis (taqsimlangan hisoblagich — ko'p server bitta chegarani ko'rishi kerak — markaziy hisob — 2.3). (5) Notification tizimi (bildirishnoma): asosiy — ko'p kanal (push/SMS/email), millionlab foydalanuvchi, ishonchli yetkazish; kalit — queue (fan-out — bir hodisa ko'p qabul qiluvchi — 2.3) + kanal ishchilari (worker — har kanal alohida), qayta urinish (retry — yetkazilmasa — 13.5). (6) YouTube/Netflix (video striming): asosiy — video saqlash + tarqatish (katta fayl — GB), transkodlash (har qurilma/tezlik uchun format); kalit — CDN (video segmentlarini foydalanuvchiga yaqin — 2.3), blob storage (S3 kabi — katta fayl), adaptiv bitrate (tarmoq tezligiga qarab sifat). (7) Uber/yetkazib berish (joylashuv): asosiy — haydovchi-yo'lovchi mos (eng yaqin), real-time joylashuv; kalit — geo-indeks (geohash yoki quadtree — "yaqindagilar" so'rovi tez), joylashuv yangilash oqimi (haydovchilar doimo joylashuv yuboradi — yuqori yozish). Ikki nuqta: (1) har savolda asosiy savol boshqa (feed generatsiya, real-time yetkazish, geo-mos, video tarqatish) — lekin usul bir xil 2.2-bob; (2) talablar API ma'lumot asosiy savol miqyos trade-off — hamma savol uchun (2.2 — universal). Sir — har savolning asosiy savolini (yuragini) topish (URL — kod generatsiya; Twitter — feed; chat — real-time; Uber — geo; YouTube — CDN/storage) — qolgani standart (talablar, API, DB, miqyos — o'rganilgan usul — 2.2-2.7). Bu katalog — tayyorgarlik uchun (2.7 — mashq): har savolni usul bilan yech, asosiy savolni ajrat. Ko'p savol bir xil bloklardan (2.3 — load balancer, kesh, DB, queue, CDN) — faqat asosiy savol va urg'u (feed — kesh; video — CDN; rate limiter — Redis hisoblagich; chat — WebSocket) o'zgaradi. Intervyuda — savolni eshitib, asosiy savolni aniqla (bu tizimning yuragi nima), keyin usul bilan qur 2.2-bob.

2.10. Junior vs senior kutilma

text
  KUTILMA — daraja bo'yicha (system design intervyuda nima baholanadi):

  JUNIOR / MID (kichik-o'rta):
   asosiy tushunchalar (load balancer, kesh, DB — 2.3) biladimi
   usulni qo'llaydimi (talablar  komponent — 2.2)
   yordamsiz oddiy dizayn qura oladimi (bitta ishlaydigan yechim)
   kutilma: to'g'ri bloklar, oqilona dizayn (mukammal miqyos shart emas)

  SENIOR:
   TRADE-OFF chuqur (nega bu, muqobil, kompromis — 2.5)
   BOTTLENECK topadi, MIQYOS chuqur (kesh/sharding/replika — 2.4)
   estimation (raqam bilan asoslash — 2.8)
   CAP, izchillik, xatoga bardosh (failure — nima buzilsa)
   mustaqil yo'naltiradi (intervyuer kam yordam)

  STAFF+ (yuqori):
   noaniqlikni boshqaradi (talab aniq emas — o'zi tuzadi)
   tizimlararo ta'sir (evolyutsiya, migratsiya, tashkiliy)
   bir necha muqobil arxitektura + qat'iy tanlov sababi

   Junior — bloklar + usul + ishlaydigan dizayn
   Senior — trade-off + bottleneck + estimation + failure + mustaqillik

Junior vs senior kutilma — system design intervyuda daraja bo'yicha nima baholanadi (bir xil savol — har xil chuqurlik kutiladi). Junior/mid (kichik-o'rta daraja): (1) asosiy tushunchalarni biladimi (load balancer, kesh, DB — 2.3 — nima ekanini, nega kerakligini); (2) usulni qo'llaydimi (talablar komponent — 2.2 — chalkash emas); (3) yordam bilan oddiy dizayn qura oladimi (bitta ishlaydigan yechim — mukammal miqyos shart emas); kutilma — to'g'ri bloklarni tanlash, oqilona dizayn (chuqur miqyos/trade-off ikkilamchi). Senior: (1) trade-off chuqur (nega bu qaror, muqobil nima, kompromis — 2.5 — "SQL chunki..., lekin NoSQL agar..."); (2) bottleneck topadi va miqyos chuqur (kesh/sharding/replika — 2.4 — qaysi qism sinadi, qanday hal); (3) estimation (raqam bilan asoslash — 2.8 — "30,000 QPS 30 server"); (4) CAP, izchillik, failure (nima buzilsa — server o'lsa, tarmoq uzilsa — bardosh — 2.5); (5) mustaqil yo'naltiradi (intervyuer kam yordam beradi — nomzod o'zi boshqaradi). Staff+ (yuqori senior): (1) noaniqlikni boshqaradi (talab aniq emas — o'zi tuzadi, taxminlarni aytadi); (2) tizimlararo ta'sir (evolyutsiya — kelajakda qanday o'zgaradi, migratsiya — eskidan yangiga, tashkiliy — jamoalar qanday bo'linadi); (3) bir necha muqobil arxitektura + qat'iy tanlov sababi. Ikki nuqta: (1) junior — bloklar + usul + ishlaydigan dizayn (asos); (2) senior — trade-off + bottleneck + estimation + failure + mustaqillik (chuqurlik). Muhim — bir xil savol ("URL qisqartiruvchi qur") junior va senior'ga beriladi, lekin chuqurlik kutilmasi farqli (junior — ishlaydigan dizayn; senior — miqyos, trade-off, failure, raqam). O'z darajangizni bil (junior bo'lsangiz — asosga urg'u, usul + bloklar; senior bo'lsangiz — chuqur trade-off, estimation, failure). Va bir daraja yuqori ko'rsating (junior senior kabi trade-off aytsa — plus; senior staff kabi evolyutsiya o'ylasa — plus). Intervyuer darajaga qarab baholaydi — junior'dan chuqur sharding kutilmaydi (asos bas), senior'dan esa kutiladi (chuqurlik shart). Bu kutilmani bilish — kuchni to'g'ri joyga yo'naltirish (junior — usul mashqi; senior — trade-off/miqyos/failure chuqurligi).

3. Sintaksis — system design ma'lumotnoma

text
YONDASHUV 2.2-bob:  talablar  miqyos baho  API  ma'lumot  dizayn  miqyos  trade-off
KOMPONENT 2.3-bob:  load balancer (taqsim) | kesh (tez) | DB | queue (asinxron) | CDN
MIQYOS 2.4-bob:     vertikal (kuchli) vs gorizontal (ko'p server); replikatsiya, sharding
CAP 2.5-bob:        C (izchil) / A (mavjud) / P (chidamli) — uchtadan ikkita; CP yoki AP
TRADE-OFF 2.5-bob:  har qaror sababli (SQL vs NoSQL, kesh, replikatsiya — kontekstga)
STRATEGIYA 2.7-bob: talablar (5-10)  katta rasm (10-15)  chuqur (15-20)  trade-off
ESTIMATION 2.8-bob: DAU  QPS (peak ×2-3)  storage  bandwidth  kesh (80/20)
LATENCY 2.8-bob:    RAM (ns) << SSD (mikro) << disk/tarmoq (milli); kesh nega tez
SAVOLLAR 2.9-bob:   URL(kod) | feed(fan-out) | chat(WebSocket) | Uber(geo) | video(CDN)
DARAJA 2.10-bob:    junior (bloklar+usul) | senior (trade-off+bottleneck+estimation)

4. Batafsil misollar

Har misol: Maqsad + tahlil + "Bu nima ko'rsatadi".

Misol 1 — Talablarni aniqlash (2.2)

Maqsad: System design savolini talablar bilan boshlashni ko'rsatish. Bu eng muhim, eng ko'p o'tkazib yuboriladigan qadam.

text
SAVOL: "Chat ilovasi (WhatsApp) qanday quriladi?"

 YOMON (darrov dizaynga):
 "WebSocket ishlataman, MongoDB'da xabar saqlayman..." (talablarsiz!)
 qanday chat? 1:1? guruh? necha foydalanuvchi? — noaniq

 YAXSHI (talablar — savol ber):
INTERVYUERGA SAVOLLAR:
1. FUNKSIONAL:
    1:1 chat? Guruh chat? Ikkalasi?
    Online holati (last seen)? O'qildi belgisi?
    Media (rasm/video)? Faqat matn?
    Xabar tarixi (saqlash)? Qancha?

2. MIQYOS (funksional bo'lmagan):
    Necha foydalanuvchi? (1M? 100M?)
    Xabar/kun? (50M?)
    Latency (real-time — millisekund)?

3. CHEKLOVLAR:
    Xabar yetkazib berish kafolati? Tartib?
    Izchillik (darrov ko'rinsin)?

 Talablar ANIQ  endi dizayn (1:1 + guruh, 50M foydalanuvchi, real-time)

Bu nima ko'rsatadi: Bu — talablarni aniqlash (eng muhim, eng ko'p o'tkazib yuboriladigan qadam — 2.2). Savol: "Chat ilovasi qanday quriladi?" — ochiq, noaniq (qanday chat? kim uchun? — 2.1). Yomon yo'l (darrov dizaynga): "WebSocket ishlataman, MongoDB'da xabar..." — talablarsiz (qanday chat — 1:1? guruh? media? — noaniq; necha foydalanuvchi — 1000? 1 milliard? — butunlay boshqa dizayn) — intervyuer ko'radi: nomzod taxmin qiladi (talablar aniqlamaydi — yomon usul). Yaxshi yo'l (talablar — savol ber): intervyuerga savollar: (1) funksional (1:1 yoki guruh? online holati? media? tarix?) — nima qiladi; (2) miqyos (necha foydalanuvchi? xabar/kun? latency?) — qancha katta; (3) cheklovlar (yetkazib berish kafolati? izchillik?). Talablar aniqlangach dizayn (1:1 + guruh, 50M foydalanuvchi, real-time — endi aniq dizayn — bu talablarga mos). Nega bu eng muhim: talablar dizaynni belgilaydi (1000 foydalanuvchi vs 1 milliard — butunlay boshqa dizayn — kesh, sharding kerakmi; faqat matn vs media — CDN kerakmi) — talablarsiz dizayn noto'g'ri (taxminga — intervyuer "men 1:1 demoqchi edim, siz guruh qildingiz"). Va talablar — fikrlash ko'rsatadi (2.1 — savol berasizmi — aniqlashga urinasizmi yoki taxmin qilasizmi — senior savol beradi, junior taxmin qiladi). Eng keng intervyu xatosi — talablarsiz darrov dizaynga (sho'ng'ish) — eng yomon belgi (intervyuer "talab nima?" — siz bilmaysiz — taxminga qurdingiz). To'g'ri — avval savol (talablar — 5-10 daqiqa — 2.7). Bu kommunikatsiya (15.6 — savol berish) va usul (2.2 — talablar birinchi). System design — talablardan boshlanadi (har savolda — "qanday X? kim uchun? qancha?"). Talablar aniqlash — system design'ning birinchi va eng muhim qadami.

Misol 2 — Miqyoslash tahlili (2.4)

Maqsad: Tizimni millionlab foydalanuvchiga qanday miqyoslashni ko'rsatish. Bu "katta yuk" savolining javobi.

text
SAVOL: "URL qisqartiruvchi 1 milliard redirect/kun — qanday miqyos?"

TAHLIL (bottleneck  yechim):

1. HISOB:
    1 mlrd/kun ÷ 86400 sek ≈ 11,500 redirect/sek (o'rtacha)
    peak (eng yuqori) ≈ 2-3x  ~30,000/sek

2. BOTTLENECK 1 — App server:
    bir server ~1000/sek  30 server kerak
    YECHIM: Load Balancer + gorizontal (30+ server — 2.4)

3. BOTTLENECK 2 — DB (har redirect DB so'rov):
    30,000 DB so'rov/sek — DB tugaydi
    YECHIM 1: KESH (Redis — mashhur URL — 90% keshdan  DB 3000/sek)
    YECHIM 2: DB replikatsiya (read replica — ko'p o'qish)

4. BOTTLENECK 3 — DB hajmi (100 mlrd URL):
    YECHIM: sharding (shortCode bo'yicha — server'larga bo'l — 2.4)

5. STATISTIKA (clicks) — har redirect'da yozish:
    YECHIM: queue (asinxron — redirect'ni bloklamasin — keyin hisobla)

NATIJA: LB + gorizontal + kesh + replikatsiya + sharding + queue

Bu nima ko'rsatadi: Bu — miqyoslash tahlili (millionlab foydalanuvchi — 2.4). Savol: URL qisqartiruvchi 1 milliard redirect/kun — qanday miqyos? Tahlil (bottleneck yechim — tizimli): (1) hisob (taxminiy — "back of envelope") — 1 mlrd/kun ÷ 86400 sek ≈ 11,500 redirect/sek (o'rtacha), peak ~30,000/sek (eng yuqori vaqt — 2-3x); (2) bottleneck 1 — app server (bir server ~1000/sek 30 server kerak) yechim: load balancer + gorizontal (30+ server — 2.4); (3) bottleneck 2 — DB (har redirect DB so'rov 30,000 so'rov/sek — DB tugaydi — eng zaif joy) yechim 1: kesh (Redis — mashhur URL — 90% keshdan DB faqat 3000/sek — yuk 10x kamaydi — 2.3), yechim 2: DB replikatsiya (read replica — ko'p o'qish); (4) bottleneck 3 — DB hajmi (100 mlrd URL — bir DB sig'maydi) yechim: sharding (shortCode bo'yicha serverlarga bo'l — 2.4); (5) statistika (har redirect'da clicks yozish — yana DB yuk) yechim: queue (asinxron — redirect'ni bloklamasin — keyin hisobla — 2.4). Natija: LB + gorizontal + kesh + replikatsiya + sharding + queue — har bottleneck'ga mos yechim. Nega bu yaxshi: tizimli (bottleneck top yechim keyingi bottleneck — 15.5 debug kabi — sabab yechim), hisob bilan (30,000/sek — taxminiy hisob — real raqamlar — qancha server, qancha yuk), va har qism (app, DB, hajm, statistika) — alohida bottleneck va yechim. Bottleneck (tor joy — eng zaif qism) topish — miqyoslashning kaliti (odatda DB — 2.4 — kesh/replikatsiya/sharding bilan hal). Kesh eng katta ta'sir (90% keshdan DB yuk 10x kamaydi — mashhur URL ko'p so'raladi — 13.7). Hisob (back of envelope — 30,000/sek) — intervyuda muhim (taxminiy raqam — qancha server/yuk — aniq qaror). Bu miqyoslash usuli (bottleneck hisob yechim) — har system design savolida (katta yuk — qanday — bottleneck top, hal qil). Intervyuda — "millionlab foydalanuvchi" javobi (bu tahlil — LB, kesh, replikatsiya, sharding, queue — har biri sababli).

Misol 3 — Trade-off muhokamasi (2.5)

Maqsad: Qaror trade-off'ini sababli ko'rsatish (SQL vs NoSQL). Bu yetuk fikrlashni (mukammal yo'q — kompromis) ko'rsatadi.

text
QAROR: URL qisqartiruvchi DB — SQL yoki NoSQL?

 YOMON (sababsiz):
 "NoSQL ishlataman" (nega? — noaniq)

 YAXSHI (trade-off — sababli):
"Bu holatda men NoSQL'ni tanlardim, sabablari:

SQL (PostgreSQL):
 Izchillik (ACID), JOIN, transaksiya
 Gorizontal miqyos murakkab (sharding qo'lda)
 mos: murakkab bog'lanishlar, izchillik kritik (bank)

NoSQL (DynamoDB/Cassandra):
 Gorizontal miqyos oson (sharding o'rnatilgan)
 Key-value mos (shortCode  longUrl — oddiy)
 JOIN yo'q, izchillik kuchsizroq (eventual)
 mos: oddiy ma'lumot, katta miqyos

QAROR: URL — oddiy key-value (shortCode  longUrl), katta miqyos,
murakkab JOIN yo'q  NoSQL mos. Izchillik kritik emas (URL eskirgan
bo'lsa ham OK — eventual consistency yetadi)."

 Trade-off — har variant afzal/kamchilik  kontekstga qaror (sababli)

Bu nima ko'rsatadi: Bu — trade-off muhokamasi (qaror sababli — 2.5). Qaror: URL qisqartiruvchi DB — SQL yoki NoSQL? Yomon yo'l (sababsiz): "NoSQL ishlataman" (nega? — noaniq — intervyuer ko'radi: nomzod bilmaydi nega — yodlagan javob). Yaxshi yo'l (trade-off — sababli): har variantni tahlil — SQL (PostgreSQL — 6.6): afzal (izchillik — ACID, JOIN, transaksiya), kamchilik (gorizontal miqyos murakkab — sharding qo'lda), mos: murakkab bog'lanishlar, izchillik kritik (bank); NoSQL (DynamoDB/Cassandra — 6.2): afzal (gorizontal miqyos oson — sharding o'rnatilgan, key-value mos — shortCode longUrl — oddiy), kamchilik (JOIN yo'q, izchillik kuchsizroq — eventual), mos: oddiy ma'lumot, katta miqyos; qaror: URL — oddiy key-value (shortCode longUrl — murakkab JOIN yo'q), katta miqyos NoSQL mos; va izchillik kritik emas (URL biroz eskirgan bo'lsa ham OK — eventual consistency yetadi — 2.5 CAP — AP). Nega bu yaxshi: (1) har variantni tahlil (afzal/kamchilik — 2.5 — har qaror kompromis); (2) kontekstga qaror (URL — oddiy, katta miqyos NoSQL — talabga mos); (3) sababli (nega NoSQL — key-value, miqyos; nega izchillik kritik emas — URL eskirsa OK). Bu yetuk fikrlash (2.5 — mukammal yo'q — kompromis, kontekst). Intervyuer trade-off ko'rsatishni qadrlaydi (qaror — sababli, muqobil bilan — "NoSQL chunki..., lekin SQL ham mumkin agar...") — bu senior fikrlash (bir javob emas — kompromis va sabab). Yomon — yodlagan javob ("NoSQL zamonaviy") — sababsiz (nega bu holatda — bilmaydi). To'g'ri — har holatga tahlil (URL — bu sabablar; bank — boshqa qaror — izchillik SQL). Trade-off — system design'ning yuragi (2.5 — har qaror sababli). Har qarorda (DB, kesh, monolit vs mikroservis) — trade-off ko'rsat (afzal/kamchilik kontekst qaror). Bu — yetuk arxitektura fikrlash (mukammal yechim yo'q — to'g'ri kompromis, sababli). Intervyuda va real ishda (har arxitektura qarori — trade-off).

Misol 4 — To'liq dizayn oqimi (Twitter feed — 2.2-2.6)

Maqsad: To'liq system design'ni boshidan oxiriga ko'rsatish (Twitter feed). Bu butun usulning yig'indisi.

text
SAVOL: "Twitter feed (timeline) qanday quriladi?"

1. TALABLAR 2.2-bob:
    tweet post; followers'ning feed'i; 300M foydalanuvchi
    o'qish >> yozish (ko'p feed ko'rish, kam tweet)

2. API:
    POST /tweet { text }; GET /feed  tweet[]

3. MA'LUMOT:
    Tweet { id, userId, text, createdAt }
    Follow { followerId, followeeId }

4. ASOSIY SAVOL — feed qanday generatsiya?
   YONDASHUV A — PULL (so'raganda hisobla):
    feed so'raganda: following'larning tweet'larini ol, sarala
     sekin (har feed — ko'p so'rov);  yozish oson
   YONDASHUV B — PUSH (fan-out — yozganda tarqat):
    tweet yozilganda  barcha follower feed'iga qo'sh (oldindan)
     feed o'qish tez (tayyor);  mashhur user (1M follower) — qimmat

   QAROR (HYBRID): oddiy user — push; mashhur user — pull (trade-off — 2.5)

5. MIQYOS 2.4-bob:
    kesh (feed — Redis); DB replikatsiya; queue (fan-out asinxron)
    CDN (media)

6. TRADE-OFF: push (tez o'qish, qimmat yozish) vs pull (oson, sekin)  hybrid

 To'liq oqim — talablar  API  ma'lumot  asosiy savol  miqyos  trade-off

Bu nima ko'rsatadi: Bu — to'liq system design oqimi (Twitter feed — butun usul — 2.2-2.6). Savol: Twitter feed qanday? Oqim (yondashuv — 2.2): (1) talablar — tweet post, followers feed, 300M foydalanuvchi, o'qish >> yozish (ko'p feed ko'rish, kam tweet — o'qishga optimallashtir — muhim); (2) API — POST /tweet, GET /feed; (3) ma'lumot — Tweet, Follow (kim kimni kuzatadi); (4) asosiy savol — feed qanday generatsiya (Twitter'ning yuragi): yondashuv A — pull (so'raganda hisobla — following'larning tweet'larini ol, sarala — sekin har feed, lekin yozish oson), yondashuv B — push (fan-out — tweet yozilganda barcha follower feed'iga oldindan qo'sh — feed o'qish tez, lekin mashhur user — 1M follower — qimmat — har tweet 1M yozish), qaror — hybrid (oddiy user push, mashhur user pull — trade-off — 2.5); (5) miqyos 2.4-bob — kesh (feed — Redis), DB replikatsiya, queue (fan-out asinxron — 2.4), CDN (media); (6) trade-off — push (tez o'qish, qimmat yozish) vs pull (oson, sekin) hybrid. Nega bu to'liq misol: butun usulni ko'rsatadi (talablar API ma'lumot asosiy savol miqyos trade-off — 2.2 yondashuv — barcha qadam). Asosiy savol (feed generatsiya — push vs pull) — Twitter'ning markaziy texnik qarori (klassik dizayn savoli — qaysi yondashuv, nega — trade-off). Hybrid (oddiy push, mashhur pull) — real Twitter yechimi (trade-off — 2.5 — mukammal yo'q — kompromis). Fan-out (push — tweet barcha follower feed) — asinxron (queue — 2.4 — yozish bloklamasin). O'qish >> yozish (talab — 1-qadam) butun dizaynni belgilaydi (o'qishga optimallashtir — push — feed tayyor — tez o'qish). Bu misol — system design usulining yig'indisi (URL — Misol 6/1/2; Twitter — bu — har biri bir xil usul, har xil asosiy savol). Mashq 2.7-bob — ko'p shunday misol (URL, Twitter, chat, Uber — usul bilan). Intervyuda — bu oqim (talablardan trade-off'gacha — struktura, savol, qaror, trade-off — fikrlash ko'rsatadi — 2.1). System design — usul 2.2-bob + tushunchalar (2.3-2.5) + amaliyot (bu misol — har biri mashq).

Misol 5 — Intervyu strategiyasi amalda (2.7)

Maqsad: System design intervyuda vaqt va yondashuvni boshqarishni ko'rsatish. Bu intervyu muvaffaqiyatining kaliti.

text
INTERVYU (45 daqiqa) — VAQT BOSHQARUVI:

[0-8 daq] TALABLAR (savol ber — 2.2):
 "Avval talablarni aniqlab olay. Bu chat 1:1mi, guruhmi? ..."
 intervyuer bilan aniqla (taxmin emas)

[8-20 daq] KATTA RASM (chiz — 2.2):
 "Asosiy komponentlarni chizay: Client  Gateway  ..."
 ovoz chiqarib 15.6-bob: "Bu yerda WebSocket, chunki real-time kerak..."

[20-38 daq] CHUQURLATIR (intervyuer yo'naltirsin):
 "Qaysi qismni chuqurroq ko'rsam? Xabar saqlash? Miqyos?"
 tanlangan qismni detallashtir (DB sxema, miqyos — 2.4)

[38-45 daq] TRADE-OFF + savollar:
 "Trade-off: men X tanladim, chunki...; muqobil Y bo'lardi..."
 "Yaxshilash: monitoring, xavfsizlik (14-QISM) qo'shardim"

XATOLAR (qochish):
 talablarsiz dizaynga (Misol 1)
 jim o'ylash (ovoz chiqar — intervyuer ko'rsin)
 over-engineer (sodda boshla — keyin miqyos)
 bir qismda qotib qolish (vaqt boshqar)

 Strategiya — vaqt boshqaruvi (talablarkatta rasmchuqurtrade-off); ovoz chiqar

Bu nima ko'rsatadi: Bu — intervyu strategiyasi amalda (vaqt va yondashuv boshqaruvi — 2.7). Intervyu (45 daqiqa — vaqt boshqaruvi muhim — cheklangan): [0-8 daq] talablar (savol ber — 2.2 — "avval talablarni aniqlab olay — 1:1mi guruhmi?" — intervyuer bilan aniqla — Misol 1); [8-20 daq] katta rasm (chiz — komponentlar — "Client Gateway ..." — diagram, va ovoz chiqarib — 15.6 — "WebSocket, chunki real-time kerak" — fikrni gapir — intervyuer ko'rsin); [20-38 daq] chuqurlashtir (intervyuer yo'naltirsin — "qaysi qismni chuqurroq? — xabar saqlash? miqyos?" — hamkorlik — 2.7 — intervyuer qiziqqanini detallashtir); [38-45 daq] trade-off + savollar ("men X tanladim chunki...; muqobil Y" — 2.5; "yaxshilash — monitoring, xavfsizlik — 14-QISM"). Xatolar (qochish): talablarsiz dizaynga (Misol 1 — eng yomon), jim o'ylash (ovoz chiqar — intervyuer fikrlashni ko'rsin — 15.6 — jim — intervyuer bilmaydi nima o'ylayapsiz), over-engineer (sodda boshla keyin miqyos — 15.1: 2.8 — boshida murakkab — xato), bir qismda qotib qolish (vaqt boshqar — bir detalda 30 daqiqa — qolgani yo'q — vaqt taqsimla). Nega bu muhim: system design intervyu — vaqt cheklangan (45-60 daq), va vaqt boshqaruvi kalit (talablar — 8 daq, katta rasm — 12, chuqur — 18, trade-off — 7 — taqsimla — biror qismda qotib qolma). Ovoz chiqarib 15.6-bob — eng muhim (intervyuer fikrlashingizni ko'radi — 2.1 — jim o'ylasangiz — ko'rmaydi — gapir: "bu yerda kesh, chunki..."). Hamkorlik 2.7-bob — intervyuer yo'naltiradi (qaysi qism — qiziqishi — tingla, moslash — dialog). Sodda boshla (over-engineer emas — oddiy dizayn keyin miqyos — 15.1: 2.8). Bu strategiya — system design intervyu muvaffaqiyati (usul — 2.2 + vaqt boshqaruvi + ovoz chiqarib + hamkorlik). System design — fikrlash ko'rsatish 2.1-bob — strategiya (vaqt, ovoz, struktura) buni ko'rsatadi. Mashq 2.7-bob bilan strategiya tabiiy bo'ladi (ko'p intervyu mashqi — vaqt, struktura, ovoz — odat). Bu — intervyu ko'nikmasi (texnik bilim + intervyu strategiyasi — birga muvaffaqiyat).

Misol 6 — Chat (WhatsApp) chuqur dizayn (2.9)

Maqsad: Real-time tizim dizaynini ko'rsatish (chat — WebSocket, offline xabar, connection gateway). Bu URL/feed'dan farqli asosiy savol — real-time yetkazish.

text
SAVOL: "1:1 chat (WhatsApp) qanday quriladi — 50M foydalanuvchi?"

1. TALABLAR (Misol 1): 1:1, real-time, online holat, offline xabar, "o'qildi"
2. HISOB 2.8-bob: 50M DAU × 40 xabar/kun ≈ 2 mlrd/kun ≈ 23,000/sek (peak ~50,000)

3. ASOSIY SAVOL — real-time yetkazish (A  B tez):
    doimiy ulanish kerak  WEBSOCKET (12-QISM — HTTP poll emas)
    muammo: A serverX'da, B serverY'da ulangan — qanday topish?

4. DIZAYN:
   A (WebSocket) ┐                        ┌ (WebSocket) B
                 ├ Chat Server X          ├ Chat Server Y
                 │                         │        
                 │   [Connection Registry: userserver — Redis]
                 │                         │
                 └ [Message Queue]  yetkazish  Chat Server Y  B
                          
                   [Message DB — xabar tarixi/offline]

5. OQIM: A xabar yozadi  Chat Server X  registry'dan B qayerda (server Y)
    B online: to'g'ri Y'ga yetkaz (WebSocket push)
    B offline: DB'ga saqla  B ulanganda yetkaz (offline xabar)

6. MIQYOS: ko'p chat server (gorizontal); registry (Redis); xabar DB sharding (userId)
7. TRADE-OFF: xabar tartibi (per-chat ketma-ket ID); "o'qildi" (qo'shimcha yozish yuki)

Bu nima ko'rsatadi: Bu — chat (real-time) chuqur dizayni (2.9 — asosiy savol boshqa: real-time yetkazish). Talablar (Misol 1): 1:1, real-time, online holat (presence), offline xabar, "o'qildi" belgisi. Hisob 2.8-bob: 50M DAU × ~40 xabar/kun ≈ 2 mlrd/kun ≈ 23,000/sek o'rtacha, peak ~50,000/sek — bu raqam ko'p chat server kerakligini asoslaydi. Asosiy savol — real-time yetkazish (A B tez): doimiy ulanish kerak WebSocket (12-QISM — HTTP so'rov-javob emas — server o'zi push qiladi — real-time); asosiy muammo — A serverX'da, B serverY'da ulangan (ko'p server — gorizontal) — B qayerda ulanganini qanday topish? Yechim — connection registry (Redis — userId serverId — kim qaysi serverda ulangan). Oqim: A xabar yozadi Chat Server X registry'dan B qayerda (server Y) B online bo'lsa to'g'ri Y'ga yetkaz (WebSocket push — Y B'ga uzatadi), B offline bo'lsa DB'ga saqla B ulanganda yetkaz (offline xabar — kutib turadi). Miqyos: ko'p chat server (gorizontal — 23,000+ ulanish), registry (Redis — tez qidiruv), xabar DB sharding (userId bo'yicha — 2.4). Trade-off: xabar tartibi (per-chat ketma-ket ID — xabarlar to'g'ri tartibda ko'rinsin), "o'qildi" belgisi (qo'shimcha yozish yuki — har o'qishda yangilanish — 2.5 — foyda vs xarajat). Nega bu boshqacha misol: URL/feed — so'rov-javob (client so'raydi, server javob beradi), lekin chat — server push (server o'zi xabar yuboradi — real-time — WebSocket kerak — 12-QISM). Asosiy savol (B qayerda ulangan — registry) — chat'ning yuragi (ko'p server + real-time push). Offline xabar (foydalanuvchi ulanmagan — saqlab qo'y) — muhim detal (WhatsApp real). Bu misol — 2.9 katalogidagi chat savolining chuqur yechimi (asosiy savol — real-time — WebSocket + registry + offline). Har system design savolining asosiy savolini top 2.9-bob — chat uchun real-time yetkazish (boshqa savollardan farqli — bu tizimning yuragi).

Misol 7 — Rate limiter dizayni (2.9, 14.8)

Maqsad: Kichik, aniq system design savolini ko'rsatish (rate limiter — algoritm + taqsimlangan hisoblagich). Bu tez-tez beriladigan, chuqur emas, lekin trade-off boy savol.

text
SAVOL: "API rate limiter qur — foydalanuvchi 100 so'rov/daqiqa"

1. TALABLAR: foydalanuvchi (yoki IP) bo'yicha cheklash; oshsa 429 rad;
   taqsimlangan (ko'p API server — bitta chegara ko'rishi kerak)

2. ALGORITM (asosiy savol — trade-off):
    FIXED WINDOW (sobit oyna): daqiqa hisoblagich, oshsa rad
      chegara chetida burst (oxirgi 30s + keyingi 30s = 2× ruxsat)
    SLIDING WINDOW (suriluvchi oyna): oxirgi 60s aniq hisob — silliq
    TOKEN BUCKET: token to'ldiriladi (tezlik), so'rov token yeydi
      burst'ga ruxsat (to'plangan token), silliq — keng ishlatiladi

3. TAQSIMLANGAN (asosiy muammo):
    ko'p API server — har biri o'z hisobini yuritsa  chegara ×N (xato)
    YECHIM: markaziy hisoblagich  REDIS (INCR + TTL — atomik)
       key = "rate:{userId}:{daqiqa}", INCR, > 100 bo'lsa rad

4. JOYLASHUV: API Gateway'da (2.3 — kirishda tekshir — 14.8)
5. TRADE-OFF: aniqlik vs tezlik (Redis so'rovi latency); fail-open vs fail-closed
   (Redis o'lsa — hammani rad qilaymi yoki o'tkazamizmi?)

Bu nima ko'rsatadi: Bu — rate limiter dizayni (2.9, 14.8 — kichik, aniq savol — trade-off boy). Talablar: foydalanuvchi (yoki IP) bo'yicha cheklash (100 so'rov/daqiqa), oshsa 429 Too Many Requests rad, taqsimlangan (ko'p API server — bitta umumiy chegarani ko'rishi kerak — muhim). Asosiy savol — algoritm (trade-off): (1) fixed window (sobit oyna — har daqiqa hisoblagich, oshsa rad) — sodda, lekin chegara chetida burst muammosi (oxirgi 30s da 100 + keyingi daqiqa boshidagi 30s da 100 = 12 soniyada 200 — chegara buzilgan kabi); (2) sliding window (suriluvchi oyna — oxirgi 60 soniyani aniq hisobla) — silliqroq, aniqroq; (3) token bucket (token to'plami — belgilangan tezlikda token to'ldiriladi, har so'rov bir token yeydi — token tugasa rad) — burst'ga ruxsat beradi (to'plangan token), silliq — eng keng ishlatiladi. Taqsimlangan (asosiy muammo): ko'p API server bo'lsa, har biri o'z hisobini yuritsa real chegara ×N (xato — 5 server 500 so'rov ruxsat) yechim: markaziy hisoblagich Redis (INCR + TTL — atomik operatsiya — 2.3 — barcha server bitta Redis'ni ko'radi): key = "rate:{userId}:{daqiqa}", INCR qil, 100'dan oshsa rad. Joylashuv: API Gateway'da (2.3 — kirishda tekshir — app'ga yetib bormasin — 14.8). Trade-off: aniqlik vs tezlik (Redis so'rovi har request'ga latency qo'shadi), fail-open vs fail-closed (Redis o'lsa — hammani rad qilaymizmi (fail-closed — xavfsiz, lekin xizmat to'xtaydi) yoki o'tkazamizmi (fail-open — xizmat ishlaydi, lekin cheklash yo'q) — muhim qaror). Nega bu yaxshi misol: (1) kichik, aniq (chuqur miqyos emas — algoritm + taqsimlangan hisob — 30 daqiqada to'liq); (2) trade-off boy (algoritm tanlovi — fixed/sliding/token; fail-open/closed — 2.5 — sababli qaror); (3) taqsimlangan tizim muammosi (ko'p server markaziy Redis — 2.3). Bu savol tez-tez beriladi (aniq, o'lchanadigan — junior ham, senior ham) — asosiy savol algoritm (trade-off) va taqsimlangan hisob (Redis). Rate limiter — 14.8 (xavfsizlik/barqarorlik) va system design 2.9-bob kesishmasi — API himoyasi (DDoS, suiiste'mol — 14-QISM). Bu misol 2.9 katalogidagi rate limiter'ning to'liq yechimi (algoritm + Redis + gateway + trade-off).

5. To'g'ri va noto'g'ri holatlar

1) Boshlash

text
 darrov dizaynga (talablarsiz — Misol 1)
 talablar (savol ber — 2.2)

2) Qaror

text
 sababsiz ("NoSQL ishlataman")
 trade-off (sababli — Misol 3)

3) Fikrlash

text
 jim o'ylash (intervyuer ko'rmaydi)
 ovoz chiqarib (gapir — 15.6, Misol 5)

4) Dizayn

text
 over-engineer (boshida murakkab)
 sodda boshla  keyin miqyos (2.7)

5) Miqyos

text
 "kesh ishlataman" (nega? qaerda?)
 bottleneck top  yechim (Misol 2)

6) Vaqt

text
 bir qismda qotib qolish (vaqt tugaydi)
 vaqt boshqar (talablarrasmchuqur — Misol 5)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Talablarsiz dizayn

Sababi: darrov sho'ng'ish 2.2-bob. Yechimi: avval savol (talablar — Misol 1).

Xato 2 — Sababsiz qaror

Sababi: trade-off yo'q 2.5-bob. Yechimi: afzal/kamchilik kontekst (Misol 3).

Xato 3 — Jim o'ylash

Sababi: fikrni gapirmaslik 2.7-bob. Yechimi: ovoz chiqarib (Misol 5).

Xato 4 — Over-engineering

Sababi: boshida murakkab 2.7-bob. Yechimi: sodda boshla miqyos.

Xato 5 — Bottleneck e'tibordan chetda

Sababi: miqyos taxminiy 2.4-bob. Yechimi: bottleneck top yechim (Misol 2).

Xato 6 — Vaqt boshqaruvi yo'q

Sababi: bir qismda qotish 2.7-bob. Yechimi: vaqt taqsimla (Misol 5).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

  • Arxitektura (9-QISM): SOLID, design patterns, mikroservis, CQRS.
  • Backend (5-QISM): queue (BullMQ), Redis (kesh).
  • DB (6-QISM): SQL/NoSQL, replikatsiya, sharding.
  • DevOps (10-QISM): load balancer (Nginx), scaling (K8s), auto-scaling.
  • Caching 13.7-bob: kesh strategiyasi, CDN.
  • Rate limiting 14.8-bob: rate limiter dizayni (token bucket, Redis — Misol 7).
  • Real-time (12-QISM): WebSocket (chat — real-time push — Misol 6).
  • Message queue (5.22, 9-QISM): Kafka/BullMQ (fan-out, asinxron — 2.3).
  • Kommunikatsiya 15.6-bob: g'oyani tushuntirish (ovoz chiqarib).
  • Algoritm (3-QISM): alohida (system design ≠ algoritm).

8. Eng yaxshi amaliyotlar (best practices)

  • Talablar birinchi (savol ber — Misol 1).
  • Tizimli yondashuv (talablarrasmchuqurtrade-off — 2.2).
  • Ovoz chiqarib (fikrni gapir — 15.6, Misol 5).
  • Chiz (diagram — komponentlar — 2.2).
  • Sodda boshla (over-engineer emas — keyin miqyos — 2.7).
  • Trade-off ayt (har qaror sababli — Misol 3).
  • Bottleneck top (miqyos — yechim — Misol 2).
  • Vaqt boshqar (taqsimla — Misol 5).
  • Hamkorlik (intervyuer bilan — dialog — 2.7).
  • Raqam bilan asosla (estimation — QPS, storage — 2.8).
  • Asosiy savolni top (har tizimning yuragi — 2.9).
  • Failure o'yla (nima buzilsa — server/tarmoq — senior — 2.10).
  • Mashq (URL, Twitter, chat — ko'p misol — 2.7).

9. Amaliy loyiha: "System Design Mashqi"

System design yondashuvini mustahkamlash.

Maqsad

Bir necha system design savolini (URL, chat, Instagram) usul bilan yech — talablardan trade-off'gacha.

Talablar (requirements)

  1. Talablar: har savolda avval aniqla (Misol 1).
  2. Estimation: QPS + storage taxminiy hisob 2.8-bob.
  3. API + ma'lumot: interfeys + DB modeli 2.2-bob.
  4. Katta rasm: komponentlar chiz 2.2-bob.
  5. Asosiy savol: har tizimning yuragi (URL kod, Twitter feed, chat real-time — 2.9).
  6. Miqyos: bottleneck yechim (Misol 2).
  7. Trade-off: qaror sababli (Misol 3).
  8. Tushunchalar: load balancer/kesh/DB/queue/CDN 2.3-bob.
  9. CAP: izchillik vs mavjudlik 2.5-bob.
  10. Vaqt: strategiya (Misol 5).
  11. Mashq: kamida 3 savol (URL, chat, rate limiter yoki +1 — 2.9).

Maslahatlar (hint)

  • Talablar birinchi (Xato 1).
  • Trade-off sababli (Xato 2).
  • Ovoz chiqarib (Xato 3).
  • Bottleneck (Xato 5).
  • Vaqt boshqar (Xato 6).

"Tayyor" mezonlari (acceptance criteria)

  • Talablar aniqlangan.
  • Estimation (QPS/storage — raqam).
  • Komponentlar (chiz).
  • Asosiy savol yechilgan.
  • Miqyos (bottleneck yechim).
  • Trade-off (sababli).
  • 3+ savol mashq.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda System Design intervyuni chuqur o'rgandik:

  • System design (intervyu maqsadi — 2.1); yondashuv (talablarmiqyostrade-off — 2.2); tushunchalar (load balancer/kesh/DB/queue/CDN — 2.3); miqyos (vertikal/gorizontal, replika/sharding — 2.4); trade-off/CAP (izchillik vs mavjudlik — 2.5); misol (URL — 2.6); strategiya (vaqt boshqaruvi — 2.7); estimation (QPS/storage/latency raqamlari — 2.8); mashhur savollar (chat/feed/Uber/video/rate limiter — 2.9); daraja kutilmasi (junior vs senior — 2.10).
  • Misollar: talablar aniqlash (1), miqyoslash tahlili (2), trade-off (3), Twitter feed to'liq oqim (4), intervyu strategiyasi (5), chat/WebSocket chuqur (6), rate limiter (7).

Endi siz system design savoliga tizimli yondasha olasiz: talablar (savol ber) estimation (QPS/storage — 2.8) komponentlar (chiz) asosiy savolni top 2.9-bob miqyos (bottleneck yechim) trade-off (sababli) failure (nima buzilsa). Bu — senior intervyu va katta tizim arxitekturasi ko'nikmasi.

Keyingi bob — 15.8-bob: Portfolio, GitHub va open source. 15-QISMni yakunlaymiz: professional ko'rinishingiz — portfolio (loyihalarni ko'rsatish), GitHub (profil, kod), open source'ga hissa (jamoaga qo'shilish, obro'), va karyera (rezyume, networking). Bu — texnik mahoratdan tashqari professional taqdimot — ishga tayyor bo'lishning yakuniy qadami.

Foydalanilgan rasmiy/ishonchli manbalar

  • "System Design Interview – An Insider's Guide" (Alex Xu, 1 va 2-jild) — yondashuv, mashhur savollar (URL, chat, rate limiter, notification, YouTube)
  • "Designing Data-Intensive Applications" (Martin Kleppmann) — miqyos, replikatsiya/sharding, trade-off, CAP, izchillik
  • "System Design Primer" (github.com/donnemartin/system-design-primer) — keng ochiq qo'llanma, "back-of-envelope" hisob
  • "Latency Numbers Every Programmer Should Know" (Jeff Dean/Peter Norvig) — latency tartiblari (2.8)
  • Grokking the System Design Interview (Educative) — yondashuv freymvork, savollar katalogi
  • High Scalability blog va real tizim arxitekturalari (Twitter timeline, Instagram feed — muhandislik bloglari)

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
15.7-bob: System Design intervyu — Wisar