System Design — Chuqur Intervyu Savollari

Full-stack dasturchi uchun System Design (tizim dizayni) bo'yicha chuqur, to'liq intervyu tayyorgarligi. Bu bo'lim Middle va Senior darajalar uchun kritik: kod yozishni bilish yetarli emas — siz katta yuklamaga bardosh beruvchi tizimni loyihalay olishingizni ko'rsatishingiz kerak.

Ikki qismdan iborat: (A) Tushunchalar (20 savol) va (B) To'liq dizayn masalalari (6 masala, bosqichma-bosqich).

Qanday foydalanish

• Belgilash: Middle · Senior.
• Tushuncha savollari tuzilishi: Ta'rif Mexanizm Misol Trade-off Follow-up.
• Dizayn masalalari tuzilishi: 1. Talablar 2. Hajm baholash 3. API dizayn 4. DB sxemasi 5. Yuqori darajali arxitektura 6. Chuqurlashtirish.
• Diagrammalar text ASCII ko'rinishida — ularni oq taxtada (whiteboard) chizishga o'rganing.
• System design intervyusida aniq javob yo'q — muhimi fikrlash jarayoni, trade-off'larni ko'rsatish va talablarni oydinlashtirish.

System design intervyuga 4-qadam framework

System design intervyusi ochiq savoldan boshlanadi ("Twitter'ni loyihalang"). Panika qilmang — quyidagi 4-qadam frameworkni doim ishlating. U sizni tartibli va ishonchli ko'rsatadi.

┌──────────────────────────────────────────────────────────────┐
│  1-QADAM: TALABLARNI OYDINLASHTIRISH (5-10 daqiqa)            │
│     • Funksional talablar (nima qiladi?)                     │
│     • Nofunksional talablar (tez? ishonchli? mavjud?)        │
│     • Doirani cheklash (scope) — hammasini emas, asosiyni    │
├──────────────────────────────────────────────────────────────┤
│  2-QADAM: HAJMNI BAHOLASH (back-of-envelope)                │
│     • DAU/MAU, QPS (o'qish/yozish), storage, bandwidth      │
│     • Read:Write nisbati — arxitekturani belgilaydi          │
├──────────────────────────────────────────────────────────────┤
│  3-QADAM: YUQORI DARAJALI DIZAYN                            │
│     • API dizayn  DB sxema  arxitektura bloklari (boxes)   │
│     • Ma'lumot oqimini chizing (client  server  DB)       │
├──────────────────────────────────────────────────────────────┤
│  4-QADAM: CHUQURLASHTIRISH & SCALING                        │
│     • Bottleneck'larni toping, SPOF'ni yo'qoting            │
│     • Cache, replication, sharding, queue qo'shing          │
│     • Trade-off'larni ochiq ayting (CAP, consistency)       │
└──────────────────────────────────────────────────────────────┘

Oltin qoida: kodga sakramang, darhol chizmang. Avval savol bering. "Nechta foydalanuvchi? O'qish ko'pmi yozish ko'pmi? Kechikish (latency) qancha bo'lishi kerak?" — bu savollar sizni Junior'dan ajratib turadi.

A QISM — TUSHUNCHALAR

1. Scalability: vertical vs horizontal

S: Scalability (masshtablanuvchanlik) nima? Vertical va horizontal scaling farqini tushuntiring. (Middle)

J:

Ta'rif. Scalability — tizimning ortib borayotgan yuklamaga (ko'proq foydalanuvchi, so'rov, ma'lumot) unumdorlikni yo'qotmasdan moslasha olish qobiliyati. Ikki yo'l bor: vertical (bitta mashinani kuchaytirish) va horizontal (ko'proq mashina qo'shish).

Mexanizm.

• Vertical scaling (scale up). Bitta serverga ko'proq resurs qo'shasiz: CPU, RAM, SSD. Oddiy — kod o'zgarmaydi. Lekin cheklangan: bitta mashina qancha kuchli bo'lishining fizik chegarasi bor va bu bitta SPOF (single point of failure).
• Horizontal scaling (scale out). Ko'p oddiy serverlarni parallel qo'shasiz va yuklamani load balancer taqsimlaydi. Deyarli cheksiz kengayadi, lekin murakkabroq: kod stateless bo'lishi, ma'lumot bo'linishi (sharding), koordinatsiya kerak.

VERTICAL (scale up)          HORIZONTAL (scale out)
   ┌────────┐                 ┌──┐ ┌──┐ ┌──┐ ┌──┐
   │ 64 CPU │                 │S1│ │S2│ │S3│ │S4│
   │ 512 GB │  <── kuchaytir  └──┘ └──┘ └──┘ └──┘
   └────────┘                     ▲ Load Balancer ▲
   1 mashina                      N ta oddiy mashina

Trade-off. Vertical — sodda, lekin ceiling (shift) bor + SPOF. Horizontal — cheksiz, lekin taqsimlangan tizim murakkabligi: tarmoq xatolari, ma'lumot izchilligi (consistency), stateless dizayn talab qilinadi. Amalda katta tizimlar ikkalasini birlashtiradi: har bir node kuchli + ko'p node.

Follow-up. "Ilovani horizontal scale qilish uchun nima zarur?" — U stateless bo'lishi kerak: session'ni serverda emas, tashqarida (Redis, JWT) saqlash. Aks holda foydalanuvchi ikkinchi so'rovda boshqa serverga tushib, session'ini yo'qotadi.

2. Load balancing

S: Load balancer nima va qanday algoritmlar bilan yuklamani taqsimlaydi? (Middle)

J:

Ta'rif. Load balancer (LB) — kiruvchi so'rovlarni bir nechta backend server o'rtasida taqsimlovchi komponent. Maqsad: yuklamani teng bo'lish, mavjudlikni (availability) oshirish va biror server ishdan chiqsa, so'rovni sog'lom serverga yo'naltirish.

Mexanizm. Asosiy algoritmlar:

• Round Robin — so'rovlarni navbat bilan har serverga beradi. Oddiy, lekin serverlar quvvati har xil bo'lsa adolatsiz.
• Weighted Round Robin — kuchliroq serverga ko'proq og'irlik (weight) beriladi.
• Least Connections — eng kam faol ulanishi bor serverga yuboradi. Uzoq so'rovlar uchun yaxshi.
• IP Hash / Consistent Hash — mijoz IP hash'iga qarab har doim bir serverga (sticky session).

LB ikki qatlamda ishlaydi: L4 (transport, TCP/UDP — tez, mazmunni ko'rmaydi) va L7 (application, HTTP — path/header ko'ra yo'naltiradi, sekinroq lekin aqlli). LB health check (heartbeat) yuboradi: sog'lom bo'lmagan node'ni pooldan chiqaradi.

                 ┌──────────────┐
   Clients ────► │ Load Balancer│  (health check har 5s)
                 └──────┬───────┘
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       ┌────┐       ┌────┐       ┌────┐
       │ S1 │       │ S2 │       │ S3 │  (ishdan chiqdi  pooldan chiqadi)
       └────┘       └────┘       └────┘

Trade-off. LB o'zi SPOF bo'lishi mumkin. Yechim: LB'ni ham juftlab qo'yish (active-passive yoki active-active) + floating IP / DNS failover. Sticky session horizontal scaling'ni buzadi (session bir serverga bog'lanadi) — buning o'rniga session'ni tashqi store'da saqlang.

Follow-up. "L4 va L7 LB qachon ishlatasiz?" — L4 sof tezlik va TCP darajasidagi taqsimlash uchun; L7 esa content-based routing kerak bo'lganda (masalan /api backend, /img static server, yoki A/B test, TLS termination).

3. Caching va cache invalidation

S: Caching nima? Cache invalidation strategiyalari va ularning trade-off'larini tushuntiring. (Senior)

J:

Ta'rif. Cache — tez-tez so'raladigan ma'lumotni tezroq qatlamda (RAM, Redis, CDN) saqlash, asosiy manba (DB, tashqi API) yukini kamaytirish va kechikishni pasaytirish uchun. "Kompyuter fanida eng qiyin ikki narsa: cache invalidation va nomlash" degan mashhur gap bejiz emas.

Mexanizm. Cache joylashuvi: brauzer CDN reverse proxy application cache (Redis/Memcached) DB. Yozish strategiyalari:

• Cache-aside (lazy loading). Ilova avval cache'dan qidiradi; yo'q bo'lsa (miss) DB'dan oladi va cache'ga yozadi. Eng keng tarqalgan. Kamchilik: birinchi so'rov sekin, cache eskirishi mumkin.
• Write-through. Har yozish cache va DB'ga bir vaqtda boradi. Cache doim yangi, lekin yozish sekinroq.
• Write-back (write-behind). Avval cache'ga, keyin asinxron DB'ga. Tez, lekin cache o'lsa ma'lumot yo'qoladi.

Invalidation (eskirgan ma'lumotni yangilash):

• TTL (time to live) — har yozuvga muddat qo'yiladi, tugagach o'chadi. Sodda, lekin muddat ichida stale (eskirgan) bo'lishi mumkin.
• Write-invalidate — DB yangilanganda tegishli cache kaliti o'chiriladi/yangilanadi.
• Event-based — DB o'zgarishi (CDC / pub-sub) cache'ni tozalaydi.

CACHE-ASIDE oqimi:
  1. read(key)  Cache
        ├─ HIT   qaytar (tez, ~1ms)
        └─ MISS  DB'dan o'qi  cache'ga yoz  qaytar (~50ms)

Trade-off. Cache **izchillik (consistency)**ni murakkablashtiradi: cache va DB bir zumda mos kelmasligi mumkin (stale read). TTL past bo'lsa — DB yuki ortadi; baland bo'lsa — eskirgan ma'lumot ko'proq. Asosiy muammolar: cache stampede (bir vaqtda ko'p miss DB'ni uradi), thundering herd. Yechim: lock/single-flight, jitter'li TTL, stale-while-revalidate.

Follow-up. "Cache stampede nima va qanday oldini olasiz?" — Mashhur kalit muddati tugagan zahoti minglab so'rov bir vaqtda DB'ni uradi. Yechim: (1) faqat bitta so'rov DB'ga borsin (mutex/lock), qolganlari kutsin; (2) eskirgan qiymatni ko'rsatib, orqa fonda yangilash (stale-while-revalidate); (3) TTL'ga tasodifiy jitter qo'shish.

4. Redis va uning use case'lari

S: Redis nima uchun ishlatiladi? Asosiy foydalanish holatlarini ayting. (Middle)

J:

Ta'rif. Redis — xotirada (in-memory) ishlaydigan, kalit-qiymat (key-value) ma'lumotlar strukturasi serveri. Juda tez (sub-millisekund), single-threaded (asosiy komandalar uchun), atomik operatsiyalarni qo'llab-quvvatlaydi.

Mexanizm. Redis oddiy string emas, boy data structurelarni saqlaydi: String, Hash, List, Set, Sorted Set (ZSet), Stream, HyperLogLog, Bitmap. Shu tufayli u ko'p vazifani bajaradi:

• Cache — eng ko'p ishlatiladigan holat (cache-aside).
• Session store — stateless serverlar uchun umumiy session.
• Rate limiting — INCR + EXPIRE bilan sanagich.
• Leaderboard — Sorted Set (ZSet) bilan reyting.
• Message queue / pub-sub — List (LPUSH/BRPOP) yoki Stream.
• Distributed lock — SET key val NX PX 30000 (Redlock).

Redis foydalanish xaritasi:
  String   cache, counter
  Hash     obyekt (user profile)
  List     queue, timeline
  Set      unique (ko'rilganlar, teglar)
  ZSet     leaderboard, rate limit oynasi
  Stream   event log, Kafka'ga o'xshash

Trade-off. Redis xotirada ishlaydi — RAM qimmat, ma'lumot hajmi cheklangan. Persistence bor (RDB snapshot, AOF log), lekin write-back xarakteri tufayli ma'lumot yo'qolishi mumkin (o'chishdan oldingi soniyalar). Single-threaded — bitta og'ir komanda (masalan KEYS *) hammani bloklaydi. Production'da KEYS o'rniga SCAN ishlating.

Follow-up. "Redis'ni qanday scale qilasiz?" — O'qish uchun replicalar (master-replica), yozish/hajm uchun Redis Cluster (sharding, 16384 hash slot). Yuqori mavjudlik uchun Redis Sentinel (avtomatik failover).

5. CDN (Content Delivery Network)

S: CDN nima va u qanday ishlaydi? Nima uchun kerak? (Middle)

J:

Ta'rif. CDN — dunyo bo'ylab tarqalgan edge server'lar tarmog'i bo'lib, static kontentni (rasm, video, CSS, JS, fayl) foydalanuvchiga geografik yaqin joydan yetkazadi. Maqsad: kechikishni kamaytirish va origin (asosiy) server yukini yengillashtirish.

Mexanizm. Foydalanuvchi so'rovi eng yaqin edgega (PoP — point of presence) boradi. Agar kontent u yerda cachelangan bo'lsa (cache hit) — darhol qaytadi. Yo'q bo'lsa (miss) — CDN origin'dan tortib oladi, edge'da saqlaydi va qaytaradi. TTL yoki Cache-Control header muddatni belgilaydi. Yangilash uchun cache purge/invalidation yoki fayl nomiga versiya (app.a1b2c3.js — cache busting).

   Toshkentdagi user ──► Edge (Frankfurt, ~40ms)
                              ├─ HIT  qaytar
                              └─ MISS  Origin (Virginia, ~180ms)  edge'ga saqla
   CDN'siz: har so'rov Virginia'ga  sekin + origin yuki katta

Trade-off. CDN static/kam o'zgaruvchi kontent uchun ideal, dinamik/shaxsiy ma'lumot uchun emas. Cache invalidation qiyin — yangilangan fayl edge'larda eskirgan qolishi mumkin (shu sabab cache busting ishlatiladi). Qo'shimcha xarajat va murakkablik.

Follow-up. "Dinamik kontentni CDN'da qanday tezlashtiradi?" — Dynamic content acceleration: to'liq cache qilmasa ham, CDN edge'dan origin'gacha optimallashtirilgan tarmoq yo'li (persistent connection, TLS termination edge'da) orqali kechikishni kamaytiradi. Edge compute (Cloudflare Workers, Lambda@Edge) esa mantiqni edge'da bajaradi.

6. SQL vs NoSQL

S: SQL va NoSQL ma'lumotlar bazasi o'rtasidagi farq nima? Qachon qaysi birini tanlaysiz? (Middle)

J:

Ta'rif. SQL (relatsion) — ma'lumotni jadval, satr, ustunlarda saqlaydi, qat'iy sxema (schema) va ACHID (ACID) kafolatlari bilan (PostgreSQL, MySQL). NoSQL — jadval bo'lmagan modellar: document (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra), graph (Neo4j). Ko'pincha moslashuvchan sxema va horizontal scaling'ga urg'u beradi.

Mexanizm.

• SQL — normallashtirilgan (normalized) ma'lumot, JOIN bilan bog'lash, kuchli ACID tranzaksiyalar, murakkab so'rovlar. Vertical scaling'ga moyil (garchi sharding ham mumkin).
• NoSQL — denormallashtirilgan (ma'lumot takrorlanadi), JOIN yo'q yoki cheklangan, ko'pincha BASE (eventual consistency), tabiiy horizontal scaling (sharding built-in). Yuqori yozish/hajm uchun optimallashtirilgan.

SQL (relatsion)              NoSQL (document)
users                        {
 id | name | city             "id": 1, "name": "Ali",
JOIN orders ON user_id        "orders": [ {...}, {...} ]   ichida
                             }
Normalized, JOIN kerak        Denormalized, JOIN yo'q

Trade-off. SQL — kuchli izchillik va murakkab so'rov, lekin scale qilish qiyinroq va sxema qattiq. NoSQL — oson scale va moslashuvchan, lekin izchillik zaifroq (eventual) va murakkab so'rov/JOIN qiyin. Noto'g'ri tushuncha: "NoSQL har doim tezroq" — yo'q, u faqat ma'lum access patternlar uchun tezroq.

Follow-up. "Bank tizimi uchun qaysi birini tanlaysiz va nega?" — SQL — chunki pul o'tkazmalari qat'iy ACID talab qiladi (atomiklik: pul bir hisobdan chiqib, ikkinchisiga tushishi kafolatli). Eventual consistency bu yerda qabul qilib bo'lmas. NoSQL esa katalog, feed, log kabi holatlar uchun.

7. Database replication

S: Database replication nima? Master-replica va uning muammolarini tushuntiring. (Senior)

J:

Ta'rif. Replication — ma'lumotni bir nechta DB nusxasida saqlash. Maqsad: yuqori mavjudlik (biri o'lsa, boshqasi ishlaydi), o'qishni scale qilish (read replicas) va geografik yaqinlik.

Mexanizm.

• Master-Replica (leader-follower). Barcha yozish master'ga boradi; u o'zgarishlarni replicalarga (asinxron yoki sinxron) uzatadi. O'qish replicalardan taqsimlanadi. O'qish ko'p bo'lgan tizimlar uchun ideal (read-heavy).
• Master-Master (multi-leader). Bir nechta node yoza oladi. Yozishni scale qiladi, lekin conflict (ikki node bir yozuvni o'zgartirsa) muammosi paydo bo'ladi.
• Sinxron vs asinxron. Sinxron — master replicani kutadi (izchil, lekin sekin). Asinxron — kutmaydi (tez, lekin replication lag va ma'lumot yo'qolishi mumkin).

            ┌────────┐  yozish
   Client ─►│ MASTER │◄─────────
            └───┬────┘
     replikatsiya│ (async)
        ┌───────┼───────┐
        ▼       ▼       ▼
   ┌────────┐┌────────┐┌────────┐
   │Replica1││Replica2││Replica3│  ◄── o'qish taqsimlanadi
   └────────┘└────────┘└────────┘

Trade-off. Replication lag — asinxron replica master'dan ortda qoladi. Foydalanuvchi ma'lumot yozadi, keyin o'qiydi, lekin replica hali yangilanmagan "read-your-writes" buziladi (u o'z o'zgarishini ko'rmaydi). Yechim: muhim o'qishni master'dan qilish yoki "sticky" session. Master o'lsa — failover kerak (replicani promote qilish), bu ma'lumot yo'qolishi/split-brain xavfini tug'diradi.

Follow-up. "Master o'lsa nima bo'ladi?" — Failover: monitoring (Sentinel/orchestrator) master o'lganini aniqlaydi va eng yangi replicani yangi master qilib promote qiladi. Xatar: split-brain (ikkita node o'zini master deb bilsa). Yechim: quorum/consensus (Raft), fencing.

8. Sharding va partitioning

S: Sharding va partitioning nima? Sharding strategiyalarini va muammolarini tushuntiring. (Senior)

J:

Ta'rif. Partitioning — katta jadvalni kichik bo'laklarga (partition) bo'lish. Sharding — bu bo'laklarni turli mashinalarga taqsimlash (horizontal partitioning). Maqsad: bitta DB ko'tara olmaydigan hajm/yozishni ko'p node'ga bo'lish.

Mexanizm. Sharding strategiyalari:

• Range-based — kalit oralig'iga ko'ra (A-M shard1, N-Z shard2). Oddiy, lekin hot spot (bir shard band bo'lib qolishi) xavfi.
• Hash-based — hash(key) % N shard. Teng taqsimlaydi, lekin node qo'shilsa hamma qayta joylashadi (buni consistent hashing hal qiladi).
• Directory-based — alohida lookup jadval kalit shard mapping saqlaydi. Moslashuvchan, lekin lookup SPOF bo'lishi mumkin.

Users jadvali (100M satr)  4 shard'ga hash bo'yicha:
  shard0: user_id % 4 == 0
  shard1: user_id % 4 == 1
  shard2: user_id % 4 == 2
  shard3: user_id % 4 == 3
  Har shard alohida DB server'da (mustaqil scale)

Trade-off. Sharding katta murakkablik keltiradi: cross-shard JOIN va tranzaksiya juda qiyin (bir necha shard'ni qamrab olgan so'rov sekin). Rebalancing (node qo'shish) og'ir. Shard keyni noto'g'ri tanlash nomutanosib yuklama (celebrity problem). Shu sabab: sharding'ga faqat oxirgi chora sifatida boring — avval read replica, cache, vertical scaling.

Follow-up. "Yaxshi shard key qanday bo'ladi?" — Yuqori cardinality (ko'p noyob qiymat), teng taqsimlanish (hot spot yo'q), va ko'pchilik so'rovlarda ishlatiladigan (shard'lararo so'rovni kamaytirish). Masalan user_id yaxshi, country yomon (ba'zi davlatlar juda katta).

9. CAP teoremasi

S: CAP teoremasi nima? Uni real tizim misolida tushuntiring. (Senior)

J:

Ta'rif. CAP teoremasi: taqsimlangan tizim bir vaqtda uch kafolatning faqat ikkitasini to'liq berishi mumkin:

• C — Consistency — har o'qish eng so'nggi yozilgan qiymatni qaytaradi (yoki xato).
• A — Availability — har so'rov javob oladi (eng yangi bo'lmasa ham).
• P — Partition tolerance — tarmoq bo'linsa (node'lar bir-birini ko'rmasa) ham tizim ishlaydi.

Mexanizm. Real taqsimlangan tizimda tarmoq bo'linishi (P) muqarrar — kabellar uziladi, node'lar yo'qoladi. Shuning uchun amalda tanlov P doim bor, siz C yoki A o'rtasida tanlaysiz:

• CP (consistency ustuvor) — bo'linish paytida izchillikni saqlash uchun ba'zi so'rovlarni rad etadi (unavailable). Misol: bank, MongoDB (default), HBase, Zookeeper.
• AP (availability ustuvor) — bo'linish paytida ham javob beradi, lekin ma'lumot eskirgan (eventual) bo'lishi mumkin. Misol: Cassandra, DynamoDB, DNS.

        Tarmoq BO'LINDI (partition)
   Node A  ───  Node B
     │              │
   CP: "izchil bo'lmasam, javob bermayman" (rad etadi)
   AP: "javob beraman, lekin eskirgan bo'lishi mumkin"

Trade-off. CAP juda soddalashtirilgan — u faqat partition paytini tavsiflaydi. Amalda PACELC aniqroq: agar Partition bo'lsa (P) — A yoki C; Else (E) normal holatda — Latency (L) yoki Consistency (C). Ko'p tizim normal holatda ham latency uchun izchillikni qurbon qiladi.

Follow-up. "Instagram like tugmasi uchun CP yoki AP?" — AP — foydalanuvchi bir soniya eskirgan like sonini ko'rsa, hech narsa buzilmaydi; muhimi tizim doim javob bersin. Bank balansi esa CP.

10. Consistency: strong vs eventual

S: Strong consistency va eventual consistency farqi nima? Consistency modellarini tushuntiring. (Senior)

J:

Ta'rif. Consistency model — taqsimlangan tizimda yozilgandan keyin o'qish qanday qiymat qaytarishini belgilaydigan kelishuv.

• Strong consistency — yozilgandan so'ng darhol har qanday o'qish yangi qiymatni ko'radi. Barcha node bir xil ko'rinadi.
• Eventual consistency — yozuv tarqalayotgan vaqtda ba'zi o'qishlar eskirgan qiymatni qaytarishi mumkin, lekin oxir-oqibat (yangi yozuv bo'lmasa) hammasi mos keladi.

Mexanizm. Oraliq modellar ham bor:

• Read-your-writes — foydalanuvchi o'z yozuvini doim ko'radi (boshqalar hali ko'rmasa ham).
• Monotonic reads — bir marta yangi qiymat ko'rgan foydalanuvchi keyin eskisini ko'rmaydi.
• Causal consistency — sababiy bog'liq operatsiyalar tartibi saqlanadi (izoh javob asl postdan keyin ko'rinadi).

Strong:   yoz(x=5) ──► o'qi  DOIM 5
Eventual: yoz(x=5) ──► o'qi  5 YOKI eski (3), keyinroq  5
                       (tarqalish vaqti = inconsistency oynasi)

Trade-off. Strong consistency latency va availabilityni qurbon qiladi (node'lar koordinatsiya qilishi, kutishi kerak — CAP'dagi CP). Eventual consistency — tez va yuqori mavjud, lekin dasturchi stale readni boshqarishi kerak (konfliktlar, "read-your-writes" buzilishi). Modelni biznes talabiga qarab tanlang.

Follow-up. "Eventual consistency'da konfliktlarni qanday hal qilasiz?" — Strategiyalar: LWW (last write wins — timestamp bo'yicha), vektor soatlar (vector clocks), CRDT (conflict-free replicated data types — matematik jihatdan avtomatik birlashadigan strukturalar), yoki ilova darajasida merge (masalan savat birlashtirish).

11. Message queue va Kafka

S: Message queue nima uchun kerak? Kafka qanday ishlaydi? (Senior)

J:

Ta'rif. Message queue (MQ) — producer (yuboruvchi) va consumer (qabul qiluvchi)ni ajratuvchi (decouple) oraliq buffer. Xabarlar navbatga qo'yiladi va asinxron qayta ishlanadi. Kafka — yuqori o'tkazuvchanlikka (throughput) mo'ljallangan distributed event streaming platformasi.

Mexanizm. MQ nima beradi: (1) decoupling — producer consumer'ni bilmaydi; (2) buffering — trafik cho'qqisida yukni tekislaydi (load leveling); (3) ishonchlilik — consumer o'lsa, xabar navbatda qoladi; (4) asinxronlik — sekin ish (email, rasm) fonga o'tadi.

Kafka spetsifikatsiyasi:

• Topic — xabarlar oqimi, partitionlarga bo'lingan.
• Partition — tartiblangan, faqat qo'shiladigan (append-only) log. Parallelizm birligi.
• Offset — har xabarning partition ichidagi pozitsiyasi. Consumer o'z offset'ini saqlaydi.
• Consumer group — bir guruh consumer partition'larni bo'lib oladi (scale). Kafka xabarni o'chirmaydi — retention (masalan 7 kun) davomida saqlaydi, shu tufayli qayta o'qish (replay) mumkin.

Producer ──► TOPIC "orders"
              ├─ Partition 0: [m0][m1][m2] ...  ► Consumer A
              ├─ Partition 1: [m0][m1] ...      ► Consumer B
              └─ Partition 2: [m0][m1][m2][m3]  ► Consumer C
   Consumer group: partitionlar consumerlarga bo'linadi

Trade-off. MQ murakkablik va latency qo'shadi (endi sinxron emas). Tartib (ordering) faqat partition ichida kafolatlanadi — global tartib yo'q. Exactly-once yetkazish qiyin — odatda at-least-once (takror bo'lishi mumkin), shuning uchun consumer idempotent bo'lishi shart. Kafka og'ir operatsion yuk (Zookeeper/KRaft, monitoring).

Follow-up. "Kafka va RabbitMQ farqi?" — Kafka — log-based, yuqori throughput, replay mumkin, event streaming/analitika uchun. RabbitMQ — an'anaviy broker (AMQP), murakkab routing (exchange), xabar iste'mol qilingach o'chadi, task queue uchun yaxshi. Kafka — "oqim", RabbitMQ — "vazifa navbati".

12. Rate limiting

S: Rate limiting nima va qanday algoritmlar bilan amalga oshiriladi? (Middle)

J:

Ta'rif. Rate limiting — mijoz ma'lum vaqt oynasida yubora oladigan so'rovlar sonini cheklash. Maqsad: tizimni suiiste'mol (DDoS, brute force), ortiqcha yuklama va resursni adolatsiz iste'moldan himoyalash.

Mexanizm. Asosiy algoritmlar:

• Fixed Window — har oynada (masalan 1 daqiqa) N so'rov. Oddiy, lekin oyna chegarasida burst (2N ketma-ket) muammosi.
• Sliding Window Log — har so'rov timestamp'i saqlanadi, oynadagilar sanaladi. Aniq, lekin xotira ko'p.
• Sliding Window Counter — oldingi + joriy oyna og'irlangan (weighted). Aniqlik + tejamli — amalda ko'p ishlatiladi.
• Token Bucket — chelakka doimiy tezlikda token tushadi; har so'rov token yeydi. Burst'ga ruxsat beradi (chelak to'la bo'lsa). Eng ommabop.
• Leaky Bucket — so'rovlar navbatga tushib, doimiy tezlikda "oqib" chiqadi. Chiqishni tekislaydi.

TOKEN BUCKET:
   token tushadi (10/sek) ──► [] (max 10)
   so'rov keldi  token bormi?
       ├─ ha   token ye, ruxsat ber
       └─ yo'q  429 Too Many Requests

Trade-off. Fixed window sodda lekin burst'ga zaif. Sliding window aniq lekin qimmat. Taqsimlangan tizimda markazlashgan hisoblagich (Redis) kerak — bu latency va SPOF qo'shadi; lokal hisoblagich esa aniq emas (har node alohida sanaydi).

Follow-up. "Ko'p serverli tizimda rate limit'ni qanday izchil qilasiz?" — Umumiy holatni Redisda saqlang (INCR + EXPIRE atomik, yoki Lua skript bilan sliding window). Har server lokal emas, markaziy Redis'ni so'raydi. Latency muhim bo'lsa: lokal cache + davriy sinxronlash (biroz aniqlikni qurbon qilib).

13. API Gateway

S: API Gateway nima va u qanday vazifalarni bajaradi? (Middle)

J:

Ta'rif. API Gateway — mijoz va backend xizmatlar (ayniqsa microservice'lar) o'rtasidagi yagona kirish nuqtasi (single entry point). U so'rovlarni tegishli xizmatga yo'naltiradi va umumiy (cross-cutting) vazifalarni markazlashtiradi.

Mexanizm. Gateway bajaradigan vazifalar:

• Routing — /users user-service, /orders order-service.
• Authentication/Authorization — token tekshirish (har xizmat alohida qilmasin).
• Rate limiting va throttling.
• Request/response transformation — protokol/format o'zgartirish.
• Aggregation — bir necha xizmat javobini birlashtirib mijozga bitta javob (BFF pattern).
• TLS termination, logging, monitoring, caching.

             ┌──────────────┐
  Client ──► │ API Gateway  │ (auth, rate limit, routing)
             └──────┬───────┘
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   user-service order-service payment-service

Trade-off. Gateway umumiy mantiqni markazlashtiradi (yaxshi), lekin o'zi SPOF va bottleneck bo'lishi mumkin — yuqori mavjudlikda (juftlab, LB orqasida) joylashtirish shart. Ortiqcha mantiq qo'ysangiz — "monolit gateway" ga aylanadi. Qo'shimcha network hop = biroz latency.

Follow-up. "API Gateway va Load Balancer farqi?" — LB — L4/L7 da so'rovlarni teng taqsimlaydi (trafik boshqaruvi). Gateway — application-level aqlli qatlam (auth, routing, aggregation, transformation). Ko'pincha ikkalasi birga: LB Gateway services.

14. Microservice'lar aloqasi

S: Microservice'lar bir-biri bilan qanday muloqot qiladi? Sinxron va asinxron trade-off'lari. (Senior)

J:

Ta'rif. Microservice'lar mustaqil xizmatlar bo'lgani uchun ular tarmoq orqali muloqot qiladi. Ikki asosiy uslub: sinxron (so'rov-javob, real vaqt) va asinxron (event/message, keyinroq).

Mexanizm.

• Sinxron — REST/HTTP, gRPC (Protobuf, tez, binar, kuchli tiplangan). Chaqiruvchi javobni kutadi. Oddiy, lekin temporal coupling (chaqirilgan xizmat o'lsa, chaqiruvchi ham to'xtaydi) va kaskad xatolar (cascading failure) xavfi.
• Asinxron — message queue / event bus (Kafka, RabbitMQ). Xizmat event chiqaradi, boshqalar tinglaydi. Loose coupling, chidamlilik (xizmat o'lsa, xabar kutadi), lekin eventual consistency va murakkab debugging.

SINXRON (gRPC/REST):
   OrderSvc ──so'rov──► InventorySvc  (kutadi, javobga bog'liq)

ASINXRON (event):
   OrderSvc ──"OrderCreated"──► [Kafka] ──► InventorySvc
                                        └──► EmailSvc  (mustaqil)

Trade-off. Sinxron — sodda, izchil, lekin coupling va kaskad xatolar (bir xizmat sekinlashsa, hammasi sekinlashadi). Asinxron — chidamli va scalable, lekin eventual consistency, xabar tartibi, takror (idempotency) muammolari. Amalda: real vaqt javob kerak bo'lsa sinxron, fon vazifa/event tarqatish uchun asinxron.

Follow-up. "Sinxron chaqiruvda kaskad xatoni qanday oldini olasiz?" — Circuit breaker (xizmat ko'p xato bersa, chaqiruvni vaqtincha to'xtatib "ochiq" holatga o'tadi), timeout, retry + exponential backoff + jitter, bulkhead (resurslarni izolyatsiya), va fallback (zaxira javob).

15. SPOF (Single Point of Failure)

S: SPOF nima va uni qanday yo'qotasiz? (Middle)

J:

Ta'rif. SPOF (single point of failure) — tizimning shunday komponentiki, u ishdan chiqsa, butun tizim to'xtaydi. Ishonchli tizim dizaynining asosiy maqsadi — SPOF'larni topib, ularni yo'qotish.

Mexanizm. SPOF'ni yo'qotish usuli — redundancy (ortiqchalik) va failover:

• Har qatlamni dublikat qilish: bitta LB o'rniga ikkita (active-passive/active-active), bitta DB o'rniga replica, bitta app server o'rniga bir necha.
• Failover — asosiy komponent o'lsa, zaxira avtomatik ishga tushadi.
• Health check + monitoring — o'lgan komponentni tez aniqlash.
• Multi-AZ / multi-region — butun ma'lumot markazi (data center) o'lsa ham ishlashi uchun.

SPOF bor:                    SPOF yo'q (redundant):
  Client ─► [1 LB] ─► App      Client ─► [LB1/LB2] ─► App'lar
               o'ldi               biri o'lsa, ikkinchi ishlaydi
           BUTUN tizim to'xtadi     tizim ishlashda davom etadi

Trade-off. Redundancy xarajat va murakkablik qo'shadi (ikki barobar resurs, koordinatsiya). Barcha SPOF'ni yo'qotish qimmat — biznes kritiklikka qarab tanlash kerak (99.9% yetarli bo'lsa, har komponentni 5x dublikat qilish shart emas).

Follow-up. "Ma'lumotlar bazasi SPOF'ini qanday yo'qotasiz?" — Replication (master + replicalar) + avtomatik failover (replicani promote qilish) + multi-AZ joylashuv. To'liq izchillik kerak bo'lsa — consensus (Raft/Paxos) asosidagi klaster (masalan CockroachDB, etcd).

16. Availability va SLA

S: Availability qanday o'lchanadi? SLA, SLO, SLI nima? (Middle)

J:

Ta'rif. Availability (mavjudlik) — tizim ishlab turgan vaqt ulushi, foizda o'lchanadi ("to'qqizlar" — nines). SLA (agreement) — mijozga rasmiy va'da (buzilsa jarima). SLO (objective) — ichki maqsad. SLI (indicator) — real o'lchangan ko'rsatkich.

Mexanizm. "To'qqizlar" yiliga ruxsat etilgan downtimeni belgilaydi:

Availability   Yillik downtime      Nomi
99%     (2)    ~3.65 kun            "ikki to'qqiz"
99.9%   (3)    ~8.77 soat           "uch to'qqiz"
99.99%  (4)    ~52.6 daqiqa         "to'rt to'qqiz"
99.999% (5)    ~5.26 daqiqa         "besh to'qqiz"

Availability oshirish usullari: redundancy, failover, health check, graceful degradation, ko'p region. Ketma-ket bog'liq komponentlar availability'ni ko'paytiradi (0.99 × 0.99 = 0.98 — pasayadi); parallel (redundant) komponentlar oshiradi.

Trade-off. Har qo'shimcha "to'qqiz" eksponensial qimmat — 99.9% dan 99.99% ga o'tish katta muhandislik va infratuzilma sarmoyasi talab qiladi. Ko'p tizimga 99.99% shart emas. Availability va consistency ham ziddiyatli (CAP).

Follow-up. "Latency va availability farqi?" — Availability — "javob bermoqdami?" (ishlaydimi). Latency — "qancha tez javob beradi?". Tizim mavjud, lekin sekin bo'lishi mumkin. Ikkalasi ham nofunksional talab, lekin har xil o'lchanadi (uptime % vs p50/p99 ms).

17. Consistent hashing

S: Consistent hashing nima va qanday muammoni hal qiladi? (Senior)

J:

Ta'rif. Consistent hashing — kalitlarni node'larga taqsimlashning shunday usuliki, node qo'shilganda yoki chiqarilganda kalitlarning faqat kichik qismi qayta joylashadi (odatda 1/N), hammasi emas.

Mexanizm. Oddiy hash(key) % N da N o'zgarsa (node qo'shilsa/o'chsa) — deyarli hamma kalit boshqa node'ga ko'chadi (cache uchun halokat — mass invalidation). Consistent hashing buni hal qiladi:

1. Node'lar va kalitlar bir doiraga (hash ring, 0..2³²) joylashtiriladi.
2. Har kalit soat yo'nalishida eng yaqin node'ga tegishli.
3. Node chiqsa — faqat uning kalitlari keyingi node'ga o'tadi; boshqalar tegilmaydi.
4. Virtual node'lar (har fizik node uchun ko'p nuqta) — teng taqsimlanishni ta'minlaydi.

        Hash Ring (0 .. 2³²)
              N1
         k3 ●─────● k1
        /           \
      N3             N2
        \           /
         ● k2 ─────●
   Node qo'shsangiz  faqat qo'shni kalitlar ko'chadi

Trade-off. Virtual node'larsiz taqsimlash nomutanosib bo'lishi mumkin (ba'zi node ko'p kalit oladi). Virtual node'lar buni tuzatadi, lekin metadata va murakkablik qo'shadi. Implementatsiya oddiy % N dan murakkabroq.

Follow-up. "Consistent hashing qayerda ishlatiladi?" — Taqsimlangan cache (Memcached klaster), DB sharding (Cassandra, DynamoDB, Redis Cluster hash slots — variant), va load balancer'lar (sticky routing). Node dinamik qo'shilib/chiqib turadigan har qanday taqsimlangan tizimda.

18. Database indexing

S: Database index nima va u qanday ishlaydi? Index'ning narxi nima? (Middle)

J:

Ta'rif. Index — jadval ustunidagi ma'lumotni tez qidirish uchun alohida saqlanadigan ma'lumot strukturasi (odatda B-tree). Kitob oxiridagi alifbo ko'rsatkichiga o'xshaydi: butun kitobni o'qimay, kerakli sahifani topasiz.

Mexanizm. Index'siz DB full table scan qiladi (har satrni ketma-ket tekshiradi — O(n)). B-tree index bilan qidiruv O(log n) bo'ladi. Turlari:

• B-tree — eng ko'p ishlatiladigan, oraliq (range) va tenglik so'rovlari uchun.
• Hash — faqat aniq tenglik (=), oraliq uchun emas.
• Composite — bir necha ustun ((last_name, first_name)) — tartib muhim (leftmost prefix qoidasi).
• Covering index — so'rov faqat index'dan javob oladi, jadvalga bormaydi.

So'rov: SELECT * FROM users WHERE email = 'a@b.com'
  Index'siz: 10M satrni ketma-ket tekshirish  (sekin)
  Index bilan (B-tree on email): O(log n) — bir necha qadam

Trade-off. Index o'qishni tezlashtiradi, lekin yozishni sekinlashtiradi (INSERT/UPDATE/DELETEda index ham yangilanishi kerak) va disk joyini egallaydi. Ortiqcha index — yozish sekin va bo'sh joy isrofi. Noto'g'ri tushuncha: "hamma ustunga index qo'yay" — bu zararli. Faqat WHERE, JOIN, ORDER BY da tez-tez ishlatiladiganlarga qo'ying.

Follow-up. "Composite index (a, b) da WHERE b = ? ishlaydimi?" — Yo'q yoki samarasiz. Leftmost prefix qoidasi: index (a, b) faqat a, yoki a AND b uchun ishlaydi, sof b uchun emas. Buning uchun alohida b index yoki (b, a) kerak.

19. WebSocket vs polling

S: Real vaqt yangilanish uchun polling, long polling, WebSocket va SSE'ni solishtiring. (Middle)

J:

Ta'rif. Serverdan mijozga real vaqt ma'lumot yetkazishning bir necha usuli bor. HTTP asosan mijoz so'ragandagina javob beradi ("pull"), server o'zi yubora olmaydi ("push") — bu muammoni turli texnikalar hal qiladi.

Mexanizm.

• Short polling — mijoz har N soniyada "yangilik bormi?" deb so'raydi. Oddiy, lekin isrof (ko'p bo'sh so'rov) va kechikish.
• Long polling — server javobni ma'lumot bo'lgunicha ushlab turadi, keyin javob beradi; mijoz darhol qayta so'raydi. Real vaqtga yaqin, lekin har xabar uchun yangi ulanish.
• WebSocket — bir marta ikki tomonlama (full-duplex), doimiy TCP ulanish. Chat, o'yin, jonli hamkorlik uchun ideal. Server istagan vaqtda push qiladi.
• SSE (Server-Sent Events) — server mijoz bir tomonlama doimiy oqim (HTTP ustida). Yangilik lentasi, notifikatsiya uchun yaxshi va oddiyroq (avtomatik qayta ulanish).

Short poll:  CS? CS? CS   (ko'p bo'sh so'rov)
Long poll:   CS....(kutadi)...  CS...
WebSocket:   CS  (bitta doimiy ikki tomonlama kanal)
SSE:         CSSS  (bir tomonlama oqim)

Trade-off. WebSocket eng kuchli, lekin stateful (har ulanish server xotirasini egallaydi) — scale qilish qiyin (sticky, connection manager, Redis pub-sub kerak). Polling — stateless va oddiy, lekin isrofgar. SSE — yengil, lekin bir tomonlama va eski brauzerlarda cheklangan.

Follow-up. "Millionlab WebSocket ulanishni qanday scale qilasiz?" — Ulanishlarni ko'p gateway nodega taqsimlang (sticky LB), holatni tashqarida (Redis) saqlang va node'lararo xabar tarqatish uchun pub-sub (Redis/Kafka) ishlating. Har node faqat o'ziga ulangan mijozlarga push qiladi; xabar boshqa node'ga tegishli bo'lsa, pub-sub orqali uzatiladi.

20. Idempotency

S: Idempotency nima va nima uchun taqsimlangan tizimda muhim? (Middle)

J:

Ta'rif. Idempotent operatsiya — bir necha marta bajarilsa ham, natija bir martalik bajarish bilan bir xil bo'ladigan operatsiya. Masalan x = 5 idempotent (necha marta yozsangiz ham 5), lekin x = x + 1 emas.

Mexanizm. Nega muhim? Tarmoq ishonchsiz — so'rov yuborildi, lekin javob yo'qoldi. Mijoz qayta yuboradi (retry). Agar operatsiya idempotent bo'lmasa (masalan "to'lovni amalga oshir"), pul ikki marta yechiladi. Yechim: idempotency key:

1. Mijoz har operatsiyaga noyob kalit (UUID) qo'shadi.
2. Server kalitni saqlaydi. Xuddi shu kalitli so'rov qayta kelsa — qayta bajarmay, oldingi natijani qaytaradi.

HTTP metodlari: GET, PUT, DELETE tabiatan idempotent; POST emas (shu sabab to'lov/buyurtma uchun idempotency key kerak).

   1. POST /pay  {key: "abc-123", amount: 100}
        └─ server: "abc-123" ko'rilmagan  to'lovni bajar, natijani saqla
   2. (retry) POST /pay {key: "abc-123", ...}
        └─ server: "abc-123" bor  QAYTA bajarma, saqlangan natija qaytar

Trade-off. Idempotency key'larni saqlash (Redis/DB) qo'shimcha holat va TTL boshqaruvi talab qiladi. Race condition (bir vaqtda ikki bir xil so'rov) — atomik "check-and-set" (lock/unique constraint) kerak. Kalit umrini to'g'ri tanlash muhim (juda qisqa — himoya yo'q, juda uzun — xotira).

Follow-up. "At-least-once yetkazishda idempotency nega zarur?" — Ko'p message queue (Kafka, SQS) at-least-once kafolat beradi — xabar takror yetkazilishi mumkin. Consumer idempotent bo'lmasa, takror xabar ikki marta ta'sir qiladi (masalan ikki email). Shuning uchun consumer yo idempotent, yo qayta ishlangan xabar ID'larini kuzatishi kerak (deduplication).

B QISM — TO'LIQ DIZAYN MASALALARI

Har masala 6 bosqichda yechiladi. Intervyuda shu tartibni ushlang: talablar hajm API DB arxitektura chuqurlashtirish. Diagrammalarni oq taxtada chizishga mashq qiling.

Masala 1. URL Shortener (bit.ly)

Uzun URL'ni qisqa havolaga (bit.ly/aB3xK) aylantiradigan xizmat loyihalang.

1. Talablar

Funksional:

• Uzun URL qisqa URL yaratish.
• Qisqa URL bosilganda asl URL'ga yo'naltirish (redirect).
• (Ixtiyoriy) maxsus alias, muddat (expiry), bosishlar analitikasi.

Nofunksional:

• Yuqori mavjudlik (havola ishlamasa yomon).
• Redirect past latency (< 100ms).
• Qisqa URL oldindan taxminlanmaydigan (xavfsizlik) va noyob.
• Read-heavy — o'qish (redirect) yozishdan ~100:1 ko'p.

2. Hajm baholash

Yozish: 100M yangi URL/oy  ~40 URL/sek (yozish QPS)
O'qish: 100:1 nisbat  ~4000 redirect/sek (o'qish QPS)
Storage: 100M/oy × 5 yil × ~500 bayt ≈ 3 TB
Qisqa kod uzunligi: base62 (a-z,A-Z,0-9)
   62^7 ≈ 3.5 trillion kombinatsiya  7 belgi yetarli

3. API dizayn

POST /api/shorten
   body: { longUrl, customAlias?, expiry? }
    200 { shortUrl: "https://bit.ly/aB3xK" }

GET /{shortCode}
    301/302 Redirect  (Location: longUrl)

301 (permanent) — brauzer cache qiladi, origin yuki kam, lekin analitika yo'qoladi. 302 (temporary) — har bosishda serverga keladi (analitika uchun yaxshi). Ko'pincha 302.

4. DB sxemasi

urls
  short_code  VARCHAR(7)  PRIMARY KEY  (index)
  long_url    TEXT
  created_at  TIMESTAMP
  expiry      TIMESTAMP  (nullable)
  user_id     BIGINT     (nullable)

Bu key-value access pattern (short_code long_url) — NoSQL (DynamoDB/Cassandra) yoki katta SQL + sharding mos keladi.

5. Yuqori darajali arxitektura

   Client ──► LB ──► App Servers ──► [Cache: Redis] ──► DB (sharded)
                          │
                          └──► Key Generation Service
   Redirect: GET /aB3xK  Redis (HIT? qaytar)  miss  DB  cache'la  302

Kod yaratish — asosiy masala. Ikki yondashuv:

• Hash-based: long_url'ni MD5/base62 qilib birinchi 7 belgi. Muammo: collision (turli URL bir kod). Yechim: collision bo'lsa qayta hash / counter qo'shish.
• Counter-based (afzal): global auto-increment counter base62 encode. Collision yo'q. Taqsimlangan counter uchun key generation service (masalan Zookeeper yoki alohida DB har node'ga oraliq (range) beradi — offline kalit generatori).

6. Chuqurlashtirish

• Cache: mashhur havolalar (80/20 qoidasi — oz havola ko'p trafik oladi) Redis'da. Redirect'ning ko'pi cache'dan DB yengillaydi.
• DB sharding: short_code bo'yicha hash sharding — teng taqsimlanadi.
• Bottleneck — kod generatori: har yozishda global counter SPOF/bottleneck bo'lmasin. Yechim: har app node oldindan kalit oralig'ini (masalan 1000 ta) oladi va lokal ishlatadi (offline generation).
• Analitika: har redirect'da sinxron yozmang — event'ni Kafkaga yuboring, alohida consumer agregatsiya qilsin (asinxron).
• Expiry: TTL yoki fon job eskirgan yozuvlarni tozalaydi.
• CDN/geo: redirect'ni edge'ga yaqinlashtirish uchun geo-DNS + edge cache.

Bu masala kalit generatsiyasi va read-heavy cache strategiyasini ko'rsatish uchun ideal.

Masala 2. Chat ilova (WhatsApp / Telegram)

Real vaqt xabar almashinuvi tizimini loyihalang (1:1 va guruh).

1. Talablar

Funksional:

• 1:1 xabar yuborish/qabul qilish real vaqtda.
• Guruh chat.
• Online/offline holat (presence), yetkazildi/o'qildi belgilari (delivery/read receipts).
• Offline foydalanuvchi keyin xabarlarni oladi (message history).

Nofunksional:

• Past latency (< 100ms yetkazish).
• Yuqori mavjudlik, xabar yo'qolmasligi (durability).
• Xabarlar tartibi saqlanishi.

2. Hajm baholash

50M DAU, har foydalanuvchi ~40 xabar/kun  2B xabar/kun
    ~23,000 xabar/sek (o'rtacha), cho'qqida ~5x
Storage: 2B × 300 bayt/xabar ≈ 600 GB/kun  yiliga ~200 TB
Ulanishlar: millionlab bir vaqtdagi WebSocket

3. API dizayn

WebSocket asosiy kanal:
   ws://chat.app/connect   (auth token bilan)
    send:    { type:"msg", to, text, clientMsgId }
    receive: { type:"msg", from, text, serverMsgId, ts }
    ack:     { type:"delivered"/"read", msgId }

REST (history/metadata):
   GET /conversations
   GET /conversations/{id}/messages?before={ts}&limit=50

4. DB sxemasi

messages  (Cassandra — write-heavy, time-series)
  conversation_id  (partition key)
  message_id       (clustering key, timeuuid — tartib)
  sender_id, content, created_at, status

conversations
  conversation_id, type (1:1/group), participants[], last_message

user_presence  (Redis)
  user_id  { status: online/offline, last_seen, gateway_node }

messages uchun Cassandra — yuqori yozish, conversation_id partition, xabarlar vaqt bo'yicha tartiblangan (write-heavy, no complex JOIN).

5. Yuqori darajali arxitektura

  User A  [WebSocket Gateway 1] ─┐
                                  ├─► [Redis Pub/Sub] ── xabar routing
  User B  [WebSocket Gateway 2] ─┘         │
                                            ▼
        [Message Service] ──► [Kafka] ──► [Cassandra] (persist)
                                     └──► [Push Notification] (offline)

Oqim: User A gateway 1'ga xabar yuboradi Message Service saqlaydi (Cassandra) qabul qiluvchi qaysi gateway'da? (Redis'da presence) Redis pub-sub orqali gateway 2'ga User B'ga push. Offline bo'lsa push notification (APNs/FCM) + keyin history'dan oladi.

6. Chuqurlashtirish

• WebSocket scaling: millionlab ulanish ko'p gateway node. Har foydalanuvchi qaysi node'da — Redisda (presence + routing). Node'lararo xabar — pub-sub.
• Xabar tartibi: Cassandra timeuuid clustering key + har conversation bitta partition tartib saqlanadi. Guruhda — sequence number.
• Delivery guarantee: xabar avval persist qilinadi (Cassandra), keyin yetkaziladi. Ack kelmasa — retry. Idempotency (clientMsgId) takror xabarni oldini oladi.
• Presence: har node heartbeat orqali Redis'ga yozadi (TTL). Katta miqyosda presence "eventual" (aniq bo'lmasa ham bo'ladi).
• Guruh chat: kichik guruh — har a'zoga fan-out. Katta guruh (kanal) — pull model (a'zolar so'raganda oladi).
• End-to-end shifrlash: (ixtiyoriy) Signal protokoli — server matnni ko'rmaydi.

Bu masala WebSocket scaling, pub-sub routing va delivery guaranteeni ko'rsatadi.

Masala 3. Ijtimoiy feed (Twitter / Instagram lentasi)

Foydalanuvchiga u kuzatadigan (follow) odamlar postlarini lentada ko'rsatuvchi tizim loyihalang.

1. Talablar

Funksional:

• Post yaratish (matn, rasm).
• Kuzatilayotganlar postlaridan iborat lenta (feed) — teskari xronologik yoki reyting bo'yicha.
• Follow/unfollow.
• Like, comment.

Nofunksional:

• Feed tez yuklanishi (< 200ms).
• Read-heavy — feed o'qish postdan ancha ko'p.
• Eventual consistency qabul (post 1-2 soniya kechroq ko'rinishi joiz).

2. Hajm baholash

300M DAU, har biri kuniga ~10 marta feed ochadi  3B feed o'qish/kun
    ~35,000 feed QPS
Post: har DAU ~2 post/kun  600M post/kun  ~7000 yozish QPS
Read:Write ≈ 100:1    feed o'qishni tezlashtirish asosiy masala

3. API dizayn

POST /api/posts            { content, mediaUrl }
GET  /api/feed?cursor={ts}&limit=20    postlar ro'yxati
POST /api/follow           { targetUserId }
POST /api/posts/{id}/like

Feed cursor-based pagination (offset emas — barqaror, tez).

4. DB sxemasi

posts        post_id, user_id, content, media_url, created_at
follows      follower_id, followee_id   (kim kimni kuzatadi)
feed_cache   user_id  [post_id, ...]   (Redis — oldindan hisoblangan feed)

5. Yuqori darajali arxitektura — Fan-out muammosi

Asosiy savol: feed'ni qachon yaratish?

• Fan-out on write (push): foydalanuvchi post qo'yganda, uni barcha kuzatuvchilarning feed cache'iga (Redis) yozib qo'yiladi. Feed o'qish juda tez (tayyor). Lekin mashhur odam (10M follower) post qo'ysa — 10M yozish (celebrity problem).
• Fan-out on read (pull): feed so'ralganda, kuzatilayotganlarning oxirgi postlarini real vaqtda yig'iladi. Yozish arzon, lekin o'qish sekin (ko'p so'rov).

   Post yaratish ──► [Post Service] ──► DB
                          │
                          └─► [Fan-out Service]
                                ├─ oddiy user  follower feed cache'lariga PUSH
                                └─ mashhur (celebrity)  PUSH qilinmaydi
   Feed o'qish ──► Redis feed cache (push qilinganlar)
                    + real vaqt PULL (kuzatilayotgan mashhurlar postlari)
                     birlashtir (merge)  qaytar

6. Chuqurlashtirish

• Gibrid yondashuv (afzal): oddiy foydalanuvchilar uchun fan-out on write (tayyor feed, tez o'qish); mashhurlar uchun fan-out on read (post vaqtida merge). Bu celebrity problem'ni hal qiladi.
• Feed cache: har foydalanuvchi feed'i Redis'da (masalan oxirgi 500 post ID). Post'lar o'zi alohida cache'da.
• Ranking: teskari xronologik yoki ML reyting (relevance). Reyting bo'lsa — offline hisoblangan skorlar.
• Media: rasm/video CDN + object storage (S3), DB'da faqat URL.
• Bottleneck — fan-out: asinxron (Kafka + worker'lar) — post yaratish darhol qaytadi, fan-out fonda.
• Cold start / inactive users: nofaol foydalanuvchi uchun feed'ni oldindan hisoblamang (isrof) — u kirganda pull qiling.

Bu masala fan-out (push vs pull) va celebrity problem trade-off'ini ko'rsatish uchun mashhur.

Masala 4. Taqsimlangan Rate Limiter

API'ni himoyalaydigan, ko'p serverga tarqalgan rate limiter loyihalang.

1. Talablar

Funksional:

• Mijoz (user/IP/API key) bo'yicha so'rovlarni cheklash (masalan 100 so'rov/daqiqa).
• Limit oshsa — 429 Too Many Requests + Retry-After header.
• Turli endpoint uchun turli limit (konfiguratsiya).

Nofunksional:

• Past latency — rate limit tekshiruvi so'rovga sezilarli kechikish qo'shmasin (< 5ms).
• Aniqlik — limitdan ortiqcha o'tkazmasin.
• Taqsimlangan — ko'p server bir xil limitni ko'rsin.
• Rate limiter o'zi yuqori mavjud (o'lsa API'ni to'sib qo'ymasin).

2. Hajm baholash

1M so'rov/sek tekshiriladi  har biriga Redis operatsiyasi
   Redis ~100K+ ops/sek/node  sharding yoki lokal cache kerak
Xotira: har active user uchun ~kichik counter  millionlab  Redis'ga sig'adi

3. API dizayn

Rate limiter — mustaqil API emas, middleware / gateway komponenti:

   Har kiruvchi so'rov:
     allowRequest(clientId, endpoint)  true/false
   Rad etilsa javob:
     429 Too Many Requests
     Retry-After: 30
     X-RateLimit-Remaining: 0

4. DB / holat sxemasi

Redis:
  ratelimit:{clientId}:{window}   counter (INCR + EXPIRE)
  yoki ZSet:  ratelimit:{clientId}  sliding window timestamp'lar
Konfiguratsiya:
  rules:{endpoint}  { limit, windowSec }

5. Yuqori darajali arxitektura

   Client ──► API Gateway ──► [Rate Limiter Middleware]
                                    │
                                    ▼
                            [Redis (markaziy counter)]
                                    │
                       allow? ──► backend service
                       deny?  ──► 429

Algoritm — sliding window counter (Redis Lua skript bilan atomik). Token bucket ham mashhur (burst'ga ruxsat).

6. Chuqurlashtirish

• Atomiklik: INCR + EXPIRE ni Lua skriptda bitta atomik operatsiya sifatida (race condition yo'q). Aks holda ikki so'rov bir vaqtda counter'ni noto'g'ri o'qishi mumkin.
• Latency vs aniqlik: har so'rov markaziy Redis'ni urishi latency qo'shadi. Yechim: lokal cache + davriy sinxronlash — har node lokal counter yuritadi, davriy Redis bilan moslaydi (biroz aniqlikni qurbon qilib, latency'ni kamaytiradi).
• Redis SPOF: Redis o'lsa nima bo'ladi? Fail-open (limitni o'tkazib yuborish — API ishlashi muhimroq) yoki fail-closed (rad etish — himoya muhimroq). Odatda fail-open + Redis replicasi/cluster.
• Sharding: juda ko'p mijoz bo'lsa — Redis Cluster, clientId bo'yicha shard.
• Distributed sync: to'liq aniqlik shart bo'lsa, markaziy; approximate yetsa, lokal + gossip.

Bu masala atomiklik, latency vs aniqlik va fail-open/closed trade-off'ini chuqur ko'rsatadi.

Masala 5. Video streaming (YouTube / Netflix)

Video yuklash va oqim (streaming) tizimini loyihalang.

1. Talablar

Funksional:

• Video yuklash (upload).
• Video ko'rish (streaming) — turli sifatda (adaptive quality).
• Qidiruv, tavsiya (ixtiyoriy).

Nofunksional:

• Yuqori mavjudlik, past buffering.
• Read-heavy (ko'rish yuklashdan ancha ko'p).
• Global — dunyoning har yeridan tez ko'rish.
• Katta storage va bandwidth.

2. Hajm baholash

2B foydalanuvchi, 500 soat video/daqiqa yuklanadi
Ko'rish: kuniga milliardlab soat  juda katta bandwidth (petabaytlar)
Storage: 1 daqiqa video ~ har sifatda ~50MB × ko'p sifat × millionlab video  PB
    Object storage (S3/GCS) + CDN majburiy

3. API dizayn

POST /api/videos/upload/init    { uploadId, presignedUrls[] }  (chunk upload)
POST /api/videos/{id}/complete  transcoding boshlanadi
GET  /api/videos/{id}           metadata + manifest URL (HLS/DASH)
GET  /api/videos/{id}/stream    .m3u8 manifest  segment URL'lar (CDN)

4. DB sxemasi

videos      video_id, uploader_id, title, description, status,
            duration, created_at, view_count
video_files video_id, resolution (240p..4k), format, cdn_url, segment_list
   (transcode natijasidagi fayllar)
metadata  SQL/NoSQL;  video fayllar  Object Storage (S3);  CDN

5. Yuqori darajali arxitektura

UPLOAD:
   Client ─► Upload Service ─► [S3 raw] ─► [Kafka: "video_uploaded"]
                                              │
                              [Transcoding Workers] (240p,480p,720p,1080p,4k)
                                              │
                              [S3: transcoded segments] ─► [CDN]
                                              │
                              metadata DB update (status: ready)

STREAM:
   Client ─► CDN (edge) ─► manifest (.m3u8) ─► segments (.ts)
             (adaptive bitrate: tarmoqqa qarab sifat almashadi)

6. Chuqurlashtirish

• Transcoding: yuklangan video bir necha sifat/formatga o'giriladi (asinxron, Kafka + worker fleet). Chunk (segment)larga bo'linadi — HLS/DASH.
• Adaptive Bitrate Streaming (ABR): manifest turli sifat variantlarini beradi; player tarmoq tezligiga qarab sifatni real vaqtda almashtiradi (buffering kamayadi).
• CDN — asosiy: video segmentlar edge'da cache'lanadi; ko'rish trafigining ~95%+ CDN'dan (origin yengillaydi, global past latency).
• Storage: raw + har sifat object storage (S3), "hot" (mashhur) videolar CDN'da, "cold" (kam ko'riladigan) arzon storage'da (S3 Glacier).
• Bottleneck — bandwidth: eng katta xarajat. CDN + kompressiya (kodeklar: H.264/H.265/AV1) + peer-assisted (ba'zi platformalar).
• View count: har ko'rishda sinxron UPDATE qilmang — Kafka'ga event, batch agregatsiya (approximate hisoblash).
• Katta upload: chunked/resumable upload (tarmoq uzilsa qaytadan boshlamaslik), presigned URL bilan to'g'ridan-to'g'ri S3'ga.

Bu masala CDN, asinxron transcoding pipeline va adaptive streamingni ko'rsatadi.

Masala 6. Taxi ilova (Uber / Yandex Go)

Yo'lovchini yaqin haydovchi bilan bog'lovchi real vaqt tizimini loyihalang.

1. Talablar

Funksional:

• Yo'lovchi buyurtma beradi yaqin haydovchi topiladi (matching).
• Haydovchi lokatsiyasi real vaqtda kuzatiladi.
• Narx hisoblash (surge pricing), safar holati (accepted arrived completed).

Nofunksional:

• Past latency matching (< bir necha soniya).
• Real vaqt lokatsiya yangilanishi (har 3-5 soniya).
• Yuqori mavjudlik, geografik.
• Buyurtma va to'lov — izchil (bir haydovchi ikki safarga tayinlanmasin).

2. Hajm baholash

10M active haydovchi, har 4 soniyada lokatsiya yuboradi
    ~2.5M lokatsiya yangilanish/sek  (yozish juda ko'p!)
Buyurtma: cho'qqida ~100K buyurtma/daqiqa
    lokatsiya oqimi asosiy bottleneck

3. API dizayn

WebSocket (haydovchi lokatsiya oqimi):
    { driverId, lat, lng, ts }   (har 4 sek)

REST/gRPC:
   POST /api/rides/request   { pickup, dropoff }
       { rideId, status: "matching" }
   POST /api/rides/{id}/accept   (haydovchi qabul qiladi)
   GET  /api/rides/{id}           status + haydovchi lokatsiyasi

4. DB sxemasi

drivers        driver_id, status(online/busy/offline), current_geohash
driver_location (Redis geo)    GEOADD:  key=geohash, driverId, lat, lng
rides          ride_id, rider_id, driver_id, status, pickup, dropoff,
               fare, created_at

Lokatsiya — Redis Geospatial (GEOADD/GEOSEARCH) yoki geohash indeks; safarlar — SQL (izchillik uchun).

5. Yuqori darajali arxitektura

  Haydovchi app  [Location Service] ─► [Redis Geo / QuadTree]
                                             │
  Yo'lovchi ─► [Ride Service] ─► [Matching Service]
                                     │ (yaqin haydovchilarni Redis Geo'dan qidiradi)
                                     ▼
                       yaqin haydovchilarga taklif yuboradi (WebSocket)
                       birinchi qabul qilgan  ride'ga tayinlanadi (atomik lock)
                                     │
                       [Ride Service] ─► DB (safar holati) ─► [Payment]

Geo-indexing: dunyoni geohash yoki QuadTree kataklarga bo'lish. Yaqin haydovchini topish = shu katak + qo'shni kataklardan qidirish (butun bazani emas).

6. Chuqurlashtirish

• Lokatsiya oqimi (asosiy bottleneck): 2.5M yozish/sek. Yechim: DB'ga har yangilanishni yozmang — Redis geo (in-memory, tez) + davriy snapshot. Eski lokatsiya muhim emas (faqat oxirgisi kerak).
• Geo-indexing: geohash (yer yuzasini gridga bo'lish) yoki QuadTree (zich hududda mayda katak). Yaqin haydovchi = qo'shni kataklar qidiruvi (O(1) ga yaqin).
• Matching atomiklik: bitta haydovchi ikki yo'lovchiga tayinlanmasligi kerak distributed lock (Redis SET NX) yoki DB UPDATE ... WHERE status='online' (optimistic). Birinchi qabul yutadi.
• Surge pricing: hudud bo'yicha talab/taklif nisbati real vaqt hisoblanadi (stream processing — Kafka/Flink).
• Safar holati — izchil: ride status va to'lov SQL/ACID (pul bilan ishlash — eventual consistency yaramaydi).
• Region sharding: dunyo hududlarga bo'linadi (geografik shard) — Toshkent buyurtmasi Toshkent klasterida ishlanadi (latency + izolyatsiya).
• Haydovchi topilmasa: qidiruv radiusini bosqichma-bosqich kengaytirish, timeout, retry.

Bu masala geospatial indexing, real vaqt lokatsiya oqimi va matching atomiklikni ko'rsatadi — eng murakkab masalalardan biri.

System design intervyu maslahatlari

Vaqtingiz kam bo'lsa, quyidagilarni mustahkam biling — ular deyarli har system design intervyusida uchraydi:

1. 4-qadam frameworkni yoddan biling: talablar hajm dizayn chuqurlashtirish. Doim shu tartibda boring.
2. Avval savol bering. Talablarni oydinlashtirmasdan chizishni boshlamang. "Nechta foydalanuvchi? Read:write nisbati? Latency talabi?"
3. Read-heavy tizimda — cache, CDN, read replica; write-heavy tizimda — sharding, queue, LSM/NoSQL.
4. Trade-off'larni ochiq ayting. "Bu yerda strong consistency tanlayman, chunki bank; latency oshadi, lekin to'g'rilik muhimroq." Bu Senior belgisi.
5. CAP/PACELC — har taqsimlangan tizimda C yoki A tanlovini asoslang.
6. SPOF'ni toping va yo'qoting — har komponentga "bu o'lsa nima bo'ladi?" deb so'rang.
7. Hajm baholashni ovoz chiqarib qiling (QPS, storage, bandwidth) — bu arxitekturani belgilaydi.
8. Bottleneck'ni aniqlang — dizaynning eng zaif nuqtasi qayerda? Uni qanday hal qilasiz?
9. Oddiydan boshlang, keyin scale qiling. Avval sodda ishlaydigan dizayn, keyin "million foydalanuvchi bo'lsa-chi?" deb chuqurlashtiring.
10. Aniq javob yo'q — intervyuer sizning fikrlash jarayoningizni baholaydi, mukammal yechimni emas.

Eng muhim maslahat: system design — muloqot imtihoni, bilim imtihoni emas. Fikringizni ovoz chiqarib ayting, chizing, savol bering, taxminlaringizni tekshiring. "Bilmayman" o'rniga "Men bunday taxmin qilaman, chunki..." deng. Intervyuer bilan birga loyihalang, unga ma'ruza o'qimang.

Yakuniy eslatma. Bu savollarni yodlamang — tushuning. Har tushunchani real loyihada qo'llab ko'ring: kichik URL shortener yozing, Redis cache qo'shing, rate limiter yasang. Amaliyot bilan bu tushunchalar "nazariy" bo'lishdan to'xtaydi va intervyuda tabiiy chiqadi. Omad!