Slack qanday ishlaydi

Bu darsda nima o‘rganasiz

Slack — ko‘rinishidan eng sodda mahsulot: chap tomonda kanallar, o‘rtada xabarlar, pastda yozish maydoni. Aynan shuning uchun u tizim dizayni uchun ajoyib misol: hamma narsa tanish, demak butun e’tiborni mexanizmga qaratsa bo‘ladi.

Bu darsning markazida bitta savol turadi: serverdan mijozga xabarni qanday yetkazasiz? Oldingi darslarda mijoz so‘raydi, server javob beradi. Bu yerda teskari: server gapirishi kerak, va mijoz qachon gapirishini oldindan bilmaydi. Bu bitta o‘zgarish butun arxitekturani ostin-ustun qiladi — ulanishlar doimiy bo‘ladi, holat serverda yashay boshlaydi, va “server qayta ishga tushdi” degan oddiy hodisa million kishilik hujumga aylanadi.

Yo‘l shunday boradi: avval so‘rov-javob modelining chegarasini raqam bilan ko‘rsatamiz, keyin doimiy ulanishning haqiqiy narxini (kernel, TLS, xotira) hisoblaymiz. So‘ng Slack tarixidagi eng qimmat dars — ulanish paytida butun ish maydoni holatini yuborish — va undan chiqqan chekka kesh g‘oyasi. Keyin presence: eng arzon ko‘rinadigan, amalda eng qimmat funksiya. Oxirida xabar tartibi, o‘qilmaganlar hisobi, qayta ulanish bo‘roni, iqtisod va sig‘im rejalashtirish.

Dars ikkinchi kursdan yuqori darajadagi muhandislar uchun. Oldingi darslardan Twitter (fan-out) va Reddit (navbat va guruhlash) tushunchalari kerak bo‘ladi, lekin ularsiz ham o‘qish mumkin — kerak joyda eslatib o‘tiladi.

1. Muammo: aslida nimani qurmoqchimiz?

1.1 Funksional talablar

1.2 Nofunksional talablar

Uchinchi qatorga alohida diqqat qiling: biz “dublikat bo‘lishi mumkin” deb ochiq yozdik. Bu — taslim bo‘lish emas, ongli qaror. Taqsimlangan tizimda “aniq bir marta yetkazish” (exactly-once) tarmoq darajasida mavjud emas; mavjud bo‘lgan narsa — kamida bir marta yetkazish va mijoz tomonda dublikatni tanib olish. 7-bo‘limda buni qanday qilishni ko‘ramiz. Agar talabnomangizda “exactly-once” deb yozilgan bo‘lsa, siz hali yechilmagan muammoni talab qilyapsiz.

1.3 Konvert orqasidagi hisob

Butun darsda ikkita hajm bilan ishlaymiz: bitta katta ish maydoni (100 000 a’zo — yirik korporatsiya) va butun platforma (10 000 000 bir vaqtda ulangan foydalanuvchi). Ikkalasi ham taxminiy, illyustratsiya uchun.

Bu hisobning natijasi darsning butun yo‘nalishini belgilaydi. Oldingi darslarda qiyinchilik hajmda edi: juda ko‘p so‘rov, juda ko‘p ma’lumot. Bu yerda hajm kichik. Qiyinchilik — holatda: tizim 10 million ochiq ulanishni, ularning har biri kim ekanini, qaysi kanalga obuna ekanini va qayerda to‘xtab qolganini eslab turishi kerak.

Bu farq muhim, chunki u odatiy optimallashtirish usullarini foydasiz qiladi. Keshlash yordam bermaydi — ma’lumot allaqachon issiq. Ro‘yxatni oldindan hisoblash yordam bermaydi — hisoblanadigan narsa yo‘q. Yordam beradigan yagona narsa — ulanishning o‘zini arzonlashtirish.

2. Nol nuqta: doimiy ulanish

Bu bo‘lim darsning poydevori. Servis, navbat va kesh haqida gapirishdan oldin bitta savolga aniq javob kerak: server mijozga o‘zi qanday gapiradi?

2.1 HTTP nima uchun yetarli emas

HTTP — so‘rov-javob protokoli. Mijoz so‘raydi, server javob beradi, ulanish yopiladi (yoki keep-alive bilan bo‘sh turadi). Serverda “mana shu mijozga xabar yuboraman” degan tushuncha yo‘q: server faqat so‘ralgan narsani qaytara oladi.

Demak yangi xabarni yetkazishning uchta yo‘li bor:

Jadval uchta usulni ko‘rsatadi, lekin ular bir xil o‘qda yotadi: ulanish qancha vaqt ochiq turadi. Qisqa so‘rovda millisekundlar, uzun so‘rovda daqiqalar, WebSocket’da soatlar. Va shu bilan birga narx ham bir joydan ikkinchisiga ko‘chadi: bo‘sh trafikdan server xotirasiga.

Raqamsiz bu jadval hech narsa demaydi. Hisoblaymiz.

Diqqat qiling, raqam ikki marta hisoblandi va ikkinchi javob birinchisidan yaxshiroq: 95 emas, 6.3. Bu — hisob-kitobda tez-tez uchraydigan tuzoq: “xabar” va “yetkazish” bir xil narsa emas. Ammo xulosa o‘zgarmaydi. Trafikning 80% i bo‘sh, va eng muhimi — kechikish protokolning o‘zidan kelib chiqadi. Uni serverni tezlashtirib tuzatib bo‘lmaydi: agar mijoz 3 soniyada bir so‘rasa, o‘rtacha kechikish 1.5 soniya, nuqta.

Oraliqni qisqartirish yordam beradimi? 3 soniya o‘rniga 0.5 soniya qilsangiz, kechikish 250 ms ga tushadi — byudjetga sig‘adi. Lekin so‘rovlar soni olti barobar oshadi: 20 million so‘rov/s, 208 Gbit/s bo‘sh trafik. Kechikish va narx bu yerda bir-biriga qarama-qarshi, va ikkalasini birdan yaxshilaydigan tutqich yo‘q. Aynan shuning uchun protokolni almashtirish kerak — parametrni emas.

Taqqoslashning eng muhim qatori — oxirgisi. Qisqa so‘rovning yagona, lekin katta ustunligi: server holatsiz. U yiqilsa, hech kim sezmaydi — keyingi so‘rov boshqa node’ga tushadi. WebSocket’ga o‘tish bilan biz bu ustunlikdan voz kechamiz va uning o‘rniga qayta ulanish, oqizish, jitter, metastabil nosozlik kabi butun bir muammolar oilasini olamiz. Darsning qolgan qismi asosan shu narxni to‘lash haqida.

2.2 WebSocket: ulanish qanday ochiladi

WebSocket — alohida protokol emas, oddiy HTTP so‘rovidan o‘sib chiqadigan ulanish. Mijoz odatdagi so‘rov yuboradi, lekin unda “men bu ulanishni boshqa protokolga o‘tkazmoqchiman” degan sarlavha bor.

GET /ws HTTP/1.1
Host: gateway.darslik.uz
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

101 javobidan keyin bu TCP ulanishida HTTP yo‘q. Ikkala tomon ham istagan vaqtda freym yubora oladi. Freym juda arzon: 2 baytlik sarlavha (kichik xabarlar uchun), maska (mijozdan serverga), so‘ng foydali yuk.

Freym tuzilishi (soddalashtirilgan):

 bayt 0:  FIN(1) RSV(3) OPCODE(4)     <- 0x81 = oxirgi freym, matn
 bayt 1:  MASK(1) LEN(7)              <- 125 baytgacha shu yerda
 bayt 2+: [maska 4 bayt] [ma'lumot]

Slack uslubidagi xabar, JSON:
 {"type":"message","channel":"C123","text":"salom"}  = 50 bayt
 Freym qo'shimchasi: 2 + 4 = 6 bayt

HTTP so'rovi bilan taqqoslang: ~800 bayt sarlavha.
Farq 130 barobar.

Mana shu 6 baytlik qo‘shimcha — WebSocket’ning butun mazmuni. Ulanish bir marta ochiladi, autentifikatsiya bir marta tekshiriladi, sarlavhalar bir marta yuboriladi. Keyingi hamma narsa sof ma’lumot.

Server -> mijoz:  PING   (har 30 soniyada)
Mijoz  -> server: PONG   (avtomatik, brauzer o'zi javob beradi)

Agar 2 ta PING ga PONG kelmasa -> ulanish o'lik deb belgilanadi
Aniqlash vaqti: 30 x 2 = 60 soniya (eng yomoni 90)

2.3 Ochiq ulanish qancha xotira yeydi

Endi eng muhim raqam. Ulanish “bo‘sh turibdi” degan gap bepul degani emas: u yadroda ham, TLS qatlamida ham, ilovangizda ham joy band qiladi.

Bu hisobda ikkita muhim tafsilot bor va ularni o‘tkazib yubormang.

Birinchisi — TLS buferi eng katta modda. OpenSSL standart holatda har bir ulanish uchun 16 KB li o‘qish va yozish buferini ushlab turadi, hatto ulanish butunlay bo‘sh bo‘lsa ham. SSL_MODE_RELEASE_BUFFERS bayrog‘i bo‘sh turgan ulanishlarda bu buferlarni qaytarib beradi va 35 KB ni 19 KB ga tushiradi — ya’ni bitta konfiguratsiya sozlamasi xotirani deyarli ikki barobar kamaytiradi. Bu kod yozishdan ancha arzon optimallashtirish.

Ikkinchisi — nazariy va amaliy sig‘im o‘rtasidagi 6 barobarlik farq. Xotira hisobi bitta mashinaga 1.9 million ulanish sig‘adi deydi. Amalda 150 000–300 000 dan oshmaydi. Sabab xotirada emas: 2 million ulanishni kuzatadigan epoll halqasi, ularning taymerlari, va — agar ilovangiz axlat yig‘uvchili tilda yozilgan bo‘lsa — 2 million obyektni skanerlaydigan GC pauzalari.

1-AVLOD: har ulanishga bitta oqim (thread)
  200 000 oqim x 8 MB stek (virtual) = 1.6 TB manzil maydoni
  Kontekst almashinuvi: har biri ~2-5 us
  Natija: 10 000 da allaqachon ishlamaydi

2-AVLOD: select() / poll()
  Bitta oqim, lekin HAR CHAQIRUVDA barcha soketlar ro'yxati yadroga beriladi
  200 000 soket x har chaqiruv = O(n)
  Sekundiga 1 000 hodisa bo'lsa: 200 000 x 1 000 = 2 x 10^8 tekshiruv/s
  Natija: CPU faqat "kim tayyor?" degan savolga sarflanadi

3-AVLOD: epoll (Linux), kqueue (BSD/macOS)
  Soketlar yadroga BIR MARTA ro'yxatdan o'tkaziladi (epoll_ctl)
  epoll_wait() faqat TAYYOR soketlarni qaytaradi
  Narx: O(tayyorlar soni), O(jami) emas
  200 000 soket, 1 000 tayyor -> 1 000 ta ish

3. v0: eng sodda ishlaydigan yechim

Bitta jarayon. Ulanishlar xotirada, obunalar lug‘atda, xabarlar Postgres’da. Bu kod haqiqatan ishlaydi — 500 foydalanuvchigacha.

connections = {}          # user_id -> websocket
channel_members = {}      # channel_id -> set(user_id)

async def on_connect(ws, user_id):
    connections[user_id] = ws
    # Mijozga butun ish maydoni holatini yuboramiz
    await ws.send(json.dumps({
        "type": "hello",
        "users":    db.all_users(ws.workspace_id),      # <- shu yerda
        "channels": db.all_channels(ws.workspace_id),
        "prefs":    db.prefs(user_id),
    }))

async def on_message(ws, user_id, channel_id, text):
    ts = f"{time.time():.6f}"
    db.insert_message(channel_id, user_id, text, ts)
    payload = json.dumps({"type": "message", "channel": channel_id,
                          "user": user_id, "text": text, "ts": ts})
    for member in channel_members[channel_id]:
        conn = connections.get(member)
        if conn:
            await conn.send(payload)

Bu yechimning yaxshi tomoni — mijoz kodi juda sodda. Ulanish ochiladi, mijoz butun ish maydonini biladi: barcha foydalanuvchilar, barcha kanallar, barcha nomlar va avatarlar. Undan keyin hech qachon hech narsa so‘ramaydi — xabar kelganda user_id ni o‘z xotirasidagi lug‘atdan topadi va ism chiqaradi. Hech qanday “yuklanmoqda” holati, hech qanday qo‘shimcha so‘rov.

Aynan shu soddalik keyinchalik eng qimmat qarorga aylanadi.

for member in channel_members[channel_id]:
    conn = connections.get(member)
    if conn:
        await conn.send(payload)

4. Nima sindi

4.1 Ulanish paytida yuboriladigan holat

Bu — darsning markaziy raqami, shuning uchun uni ikki tomondan ko‘rib chiqamiz.

Mijoz tomondan bu mahsulot muammosi: ilova ochilishi 2 daqiqa davom etadi, telefon xotirasi tugaydi, mobil internetda foydalanuvchi 155 MB trafik sarflaydi.

Server tomondan bu esa o‘lim jazosi, va sababi ulanishlar soni emas — qayta ulanishlar.

Tabiiy savol: “men shunchalik katta ish maydoni qurmayman-ku”. To‘g‘ri, lekin formulani qarang — portlash hajmi a’zolar soniga kvadratik bog‘liq: ulanishlar soni a’zolarga proporsional, va har bir ulanish oladigan holat ham a’zolarga proporsional. 10 000 a’zoli ish maydonida bu 2 000 × 15.5 MB = 31 GB, ya’ni 2.5 soniya. Sezilarli, lekin halokatli emas. 100 000 da esa 3.1 TB.

Kvadratik o‘sish har doim shunday xatti-harakat qiladi: uzoq vaqt muammo ko‘rinmaydi, keyin birdan hamma narsa buziladi. Va bu sizning eng katta, eng qimmat mijozingizda sodir bo‘ladi.

t=0     Tarmoq 2 soniyaga uzildi.
        20 000 mijoz uziladi.

t=2     Hammasi bir vaqtda qayta ulanadi.
        Serverga 20 000 ta TLS + auth + 155 MB holat so'rovi keladi.

t=2-30  Server band. Yangi so'rovlar navbatda kutadi.
        Navbatda kutgan mijozlarning TIMEOUT'i ishga tushadi (odatda 30 s).

t=32    Timeout bo'lgan mijozlar uzilib, YANA urinadi.
        Ayni paytda server hali birinchi to'lqinni qayta ishlayapti.
        Endi navbatda 20 000 emas, 35 000 so'rov bor.

t=35    Serverning xotirasi to'ladi (har bir yarim tugagan so'rov
        155 MB javob tayyorlayapti).
        Node yiqiladi.

t=36    Uning ulanishlari QO'SHNI node'larga o'tadi.
        Ular ham xuddi shu yo'ldan o'tadi.

4.2 Barcha ulanishlar bitta jarayonda

connections lug‘ati xotirada, ya’ni:

• Jarayon qayta ishga tushsa — hamma uziladi
• Deploy qilsangiz — hamma uziladi
• Ikkinchi mashina qo‘shsangiz — u birinchisidagi ulanishlarni ko‘rmaydi, demak channel_members bo‘yicha yetkazish ishlamaydi

Uchinchi nuqta eng nozik. Ikki mashinaga bo‘linganingiz bilan xabar yetkazish buziladi: A mashinasidagi foydalanuvchi yozgan xabar B mashinasidagi kanal a’zolariga bormaydi. Ya’ni gorizontal masshtablash uchun avval mashinalararo yo‘l qurish kerak — bu 5-bo‘limning birinchi qadami.

4.3 Xabar tartibi tasodifiy

ts = time.time() — bu mahalliy soat. Ikki mashinada soatlar farq qiladi.

Bu muammo ayniqsa yomon, chunki u jim: hech qanday xatolik yo‘q, hech qanday metrika yonmaydi. Foydalanuvchilar esa javobni savoldan oldin ko‘radi va “Slack buzildi” deb o‘ylaydi. 7-bo‘limda buni qanday to‘g‘rilashni ko‘ramiz.

4.4 Presence umuman yo‘q

v0 da presence haqida o‘ylanmagan ham. Uni “oson” deb qo‘shishga urinsangiz, darsning eng katta kutilmagan raqami chiqadi — 6-bo‘lim.

4.5 Yo‘qolgan xabarlar

Mijoz uzilib qolgan vaqtda kelgan xabarlar hech qayerga yozilmaydi: for member in channel_members halqasi connections.get(member) ni None topadi va shunchaki o‘tib ketadi. Mijoz qayta ulanganda ularni hech qachon ko‘rmaydi.

To‘g‘ri yechim “yetkazilmaganlarni navbatga qo‘yish” emas — bu yo‘l har bir foydalanuvchi uchun alohida navbat yaratishga olib keladi va 10 million navbat boshqarib bo‘lmaydi. To‘g‘ri yechim — kanal tarixining o‘zini navbat sifatida ishlatish, va mijozga “men shu nuqtadan keyingisini bilmayman” deyishga imkon berish. 5-bo‘limning 8-qadami.

5. Evolyutsiya: o‘n to‘rt qadam

Har bir qadamda nima yutilgani va nima yo‘qotilgani yoziladi. Ikkinchisisiz bu ro‘yxat reklama bo‘lib qoladi, darslik emas.

ESKI: connect -> 155 MB (hamma narsa)

YANGI: connect -> 20 KB (menga tegishli minimal holat):
         - mening kanallarim ro'yxati (id va nom, 500 ta = 15 KB)
         - o'qilmaganlar hisobi
         - mening sozlamalarim
       keyin kerak bo'lganda:
         GET /users?ids=U1,U2,...  -> chekka keshdan, 2-5 ms

1. API: UPDATE users SET name = ..., version = version + 1 WHERE id = U1
2. API: e'lon -> "user_changed" {id: U1, version: 48}
         mavzu: ws:<ish_maydoni>   (faqat shu ish maydoniga)
3. Chekka keshlar: U1 ni o'chiradi (keyingi so'rovda qayta yuklanadi)
4. Gateway'lar: shu ish maydonidagi ulangan mijozlarga yuboradi
5. Mijoz: mahalliy U1.version < 48 bo'lsa -> yangilaydi yoki o'chiradi

# Kanal shardida, bitta oqimda:
def assign_ts(channel_id, wall_clock):
    last = last_ts[channel_id]
    ts = max(wall_clock, last + 0.000001)   # monotonlikni majburlash
    last_ts[channel_id] = ts
    return f"{ts:.6f}"

Mijoz: send(client_msg_id=abc-123, text="salom")
       [tarmoq uzildi, javob kelmadi]
Mijoz: send(client_msg_id=abc-123, text="salom")   <- bir xil id
Server: bu id allaqachon bor -> ts=1405894322.002768 qaytaraman
Mijoz: mahalliy "yuborilmoqda" xabarini shu ts bilan almashtiradi

Mijoz uzilganda oxirgi ko'rgan ts'ni eslab qoladi:
  {"C123": "1405894322.002768", "C456": "1405894100.000431"}

Qayta ulanganda:
  connect(last_seen={"C123": "1405894322.002768", ...})

Server har bir kanal uchun:
  SELECT * FROM messages
  WHERE channel_id = 'C123' AND ts > '1405894322.002768'
  ORDER BY ts LIMIT 200

Kanalda:              channel_seq[C123] = 48 210   (har xabarda +1)
Foydalanuvchida:      read_seq[U1][C123] = 48 195  (o'qiganda yangilanadi)

O'qilmagan = 48 210 - 48 195 = 15        <- ayirish, O(1)

1. Node'ni yuk balanslagichdan olib tashlash (yangi ulanish kelmaydi)
2. Ulangan mijozlarga "boshqa joyga ko'ching" signali yuborish,
   TASODIFIY KECHIKISH bilan: har biriga 0-300 s oralig'ida
3. Mijoz o'zi qulay paytda uzilib, qayta ulanadi
4. Node bo'shaganda o'chiriladi

6. Presence: eng arzon ko‘rinadigan, eng qimmat funksiya

Yashil nuqta. Ismning yonidagi kichkina doira. Mahsulot hujjatida bir qator: “foydalanuvchi onlayn ekanini ko‘rsatish”. Rejalashtirishda bir soatlik ish.

Amalda bu — butun tizimdagi eng katta trafik manbai bo‘lishi mumkin. Sababini raqam bilan ko‘rsatamiz.

6.1 Sodda yechimning narxi

Sodda yechim: har bir mijoz o‘z ish maydonidagi hammaning presence holatini biladi va o‘zgarishlarni oladi.

Endi buni o‘sha ish maydonidagi haqiqiy suhbat bilan solishtiring.

Bu raqam darsning eng muhim xulosasiga olib keladi, va u faqat Slack haqida emas: mahsulotning eng arzon ko‘rinadigan funksiyasi eng qimmat bo‘lib chiqishi mumkin, va buni faqat hisoblash orqali bilasiz. Yashil nuqta foydalanuvchiga hech narsaga tushmaydi — u hatto qaramaydi ham. Tizimga esa suhbatdan 50 000 barobar qimmatga tushadi.

Sabab strukturaviy: xabar yo‘naltirilgan (kanal a’zolariga), presence esa eshittirish (hammaga). Yo‘naltirilgan trafik a’zolar soniga chiziqli o‘sadi, eshittirish esa kvadratik.

6.2 Yechim: ko‘rinadigan narsaga obuna bo‘lish

Asosiy kuzatish: foydalanuvchi ekranida bir vaqtda 50 tadan ortiq odam ko‘rinmaydi. Kanal a’zolari ro‘yxati ochilsa — 30 ta nom. Suhbat oynasida — oxirgi 15 ta yozgan odam. Yon panelda — 10 ta shaxsiy suhbat.

Demak mijoz hammaning presence’ini bilishi shart emas. U faqat hozir ekranda ko‘rinayotganlarga obuna bo‘lsin.

Mijoz kanalni ochdi:
  -> presence_sub {"ids": ["U1","U2",...,"U47"]}

Foydalanuvchi boshqa kanalga o'tdi:
  -> presence_sub {"ids": [...yangi ro'yxat...]}   (eskisi bekor qilinadi)

Server tomonda:
  watchers[U1] = {conn_a, conn_c, conn_f, ...}

Uch hisobning ketma-ketligini qayta o‘qing: 3 000 000 → 5 000, va buning uchun qo‘shimcha 60 MB xotira sarflandi. Trafikni xotiraga almashtirish — bu darsdagi eng foydali almashtirish, va u bir necha joyda takrorlanadi (obuna jadvali, chekka kesh, o‘qilmaganlar hisoblagichi).

Ikki ustunning oxirgi qatorini solishtiring — ular bir-biriga zid emas. Eshittirish kichik ish maydonida to‘g‘ri tanlov: 50 a’zo uchun obuna jadvali ortiqcha murakkablik. Amaliy tizimlar ikkalasini ham ishlatadi va chegarani ish maydoni hajmiga qarab belgilaydi — masalan, 500 a’zogacha eshittirish, undan yuqori obuna. Bu “bitta to‘g‘ri yechim” emas, hajmga bog‘liq ikkita yechim va ular orasidagi o‘tish nuqtasi.

6.3 “Uzoqda” holati va soat

Presence uch holatli: active, away, offline. Ikkinchisi eng qiziq, chunki u hech qanday hodisadan kelib chiqmaydi — u hodisaning yo‘qligidan kelib chiqadi.

Mijoz: har 30 soniyada "men tirikman" (yoki foydalanuvchi harakat qilsa)
Server: oxirgi signal vaqtini yozadi

active:  oxirgi harakat < 10 daqiqa
away:    oxirgi harakat > 10 daqiqa, ulanish ochiq
offline: ulanish yo'q

Muammo: “10 daqiqa o‘tdi” degan hodisani kim yaratadi? Taymer bilan har bir foydalanuvchi uchun alohida kuzatish 10 million taymer degani.

Bu — umumiy naqsh: “vaqt o‘tdi” hodisasini yaratmang, vaqtni o‘qish paytida hisoblang. Taymer hodisalari taqsimlangan tizimda qimmat, chunki ular holat talab qiladi va ular node bilan birga o‘ladi.

7. Xabar tartibi va identifikatorlar

Bu bo‘lim 5-bo‘limning 5- va 6-qadamlarini birlashtiradi va ularning oqibatlarini oxirigacha olib boradi.

7.1 ts bir vaqtda uch ishni bajaradi

Slack’da xabar identifikatori — "1405894322.002768" ko‘rinishidagi satr. Bu bitta qiymat uchta rol o‘ynaydi:

Uchta rolni bitta qiymatga yuklash — ataylab qilingan qaror, va uning foydasi katta: sahifalash, quvib yetish (5.8) va havola qilish uchun alohida mexanizm kerak emas. Lekin narxi ham bor, va u ko‘pchilik o‘ylamaydigan joyda.

1405894322.002768  -> float64 -> 1405894322.0027680
1405894322.002769  -> float64 -> 1405894322.0027690   (hozircha yaxshi)

Lekin 2033-yilda (11 xonali epoch):
14058943220.002768 -> float64 -> 14058943220.002768   (17 raqam!)
14058943220.002769 -> float64 -> 14058943220.002769
  ...aniqlik yo'qola boshlaydi, qo'shni qiymatlar birlashadi

7.2 Optimistik yuborish va uni to‘g‘ri almashtirish

Foydalanuvchi Enter bosganda xabar darhol ko‘rinishi kerak — server javobini kutib o‘tirish mumkin emas. Demak mijoz uni mahalliy qo‘shadi, keyin serverdan tasdiq kelganda almashtiradi.

1. Mijoz: local_id = uuid()
          UI'ga qo'shadi: {id: local_id, text: "salom", pending: true}
          send({client_msg_id: local_id, channel: "C123", text: "salom"})

2. Server: ts tayinlaydi, saqlaydi, kanalga tarqatadi

3. Mijoz ikkita narsa oladi:
   a) ack: {client_msg_id: local_id, ts: "1405894322.002768"}
   b) message: {ts: "1405894322.002768", user: "U1", text: "salom"}
      (bu HAMMAGA ketadi, jumladan yuboruvchining o'ziga)

4. Mijoz: local_id bo'yicha topadi, ts bilan almashtiradi, pending'ni oladi

Uchinchi qadamda nozik joy bor: mijoz ikkita xabar oladi, va ular istalgan tartibda kelishi mumkin. Agar message ack dan oldin kelsa va mijoz sodda yozilgan bo‘lsa, u xabarni ikki marta ko‘rsatadi: bittasi mahalliy pending, bittasi serverdan.

Shuning uchun mijoz tarqatilgan xabarda ham client_msg_id ni ko‘radi va o‘zinikini tanib oladi. Bu — server tomondan bitta qo‘shimcha maydon, mijoz tomondan esa butun sinf xatolarning oldini olish.

Noutbuk: mark_read(C123, seq=48210)
Server:  read_seq[U1][C123] = max(eski, 48210)     <- max(): orqaga ketmaydi
         -> U1 ning BARCHA ulanishlariga: {"type":"read_marker","ch":"C123","seq":48210}
Telefon: o'qilmagan = channel_seq - 48210 = 0  -> nishon o'chadi

8. Bugungi arxitektura

Diagrammada e’tibor berilishi kerak bo‘lgan narsa — gateway qatlami hech qanday biznes mantiq bajarmaydi. U kim ulanganini, kim nimaga obuna ekanini biladi, va freymlarni uzatadi. Boshqa hech narsa. Bu ataylab: gateway kamdan-kam deploy qilinadi (5.1-qadam), demak undagi kod qanchalik kam bo‘lsa, shuncha yaxshi.

8.1 Xabar yetkazishning kechikish byudjeti

Byudjetning taqsimotiga qarang: 93 ms ning 50 ms i tarmoq, ya’ni sizning kodingiz emas. Serverdagi butun ish — ruxsat, yozish, marshrutlash — 23 ms oladi.

Bundan ikkita amaliy xulosa chiqadi. Birinchisi: serverni optimallashtirish bu yerda kam foyda beradi; 23 ms ni 12 ms ga tushirsangiz, foydalanuvchi farqni sezmaydi. Ikkinchisi va muhimrog‘i: kechikishni yaxshilashning yagona jiddiy yo‘li — mintaqaviy joylashuv. Gateway foydalanuvchiga yaqin bo‘lsa, 25 ms 8 ms ga tushadi; xabarning ikki uchida ham shunday bo‘lsa, 34 ms tejaladi — bu serverdagi butun ishdan ko‘proq.

Aynan shuning uchun 12-bo‘limdagi E bosqichi (ko‘p mintaqa) sig‘im uchun emas, kechikish uchun qilinadi.

9. Ishonchlilik

9.1 Nosozliklar taksonomiyasi

Jadvalning ikkinchi ustuniga diqqat qiling: birinchi qatordan boshqa hammasida foydalanuvchi tizimni ishlatishda davom etadi. Bu tasodif emas — arxitektura ataylab shunday qurilgan: o‘qish yo‘li (tarix, kesh) yozish yo‘lidan mustaqil, va real vaqt qatlami (pub/sub) ishlamasa ham mijoz tarixdan quvib yetish orqali xabarlarni oladi (5.8-qadam).

Birinchi qator esa — bu darsning eng jiddiy nosozligi, va unga alohida qarash kerak.

9.2 Qayta ulanish bo‘roni va jitter

Gateway yiqilganda 200 000 mijoz bir vaqtda qayta ulanadi. Agar ularning hammasi darhol urinsa, qolgan node’lar ham yiqiladi — va bu jarayon o‘zini takrorlaydi.

Jitter’ning ishlash prinsipi tushunarli bo‘lsin: eksponensial backoff intervalni kattalashtiradi, jitter esa bir xil vaqtda uyg‘onishni buzadi. Ikkinchisisiz birinchisi deyarli befoyda — bu taqsimlangan tizimlardagi eng ko‘p takrorlanadigan konfiguratsiya xatosi.

def reconnect_delay(attempt, cap=300):
    base = min(cap, 2 ** attempt)
    return random.uniform(0, base)        # to'liq jitter

# Muhim qo'shimcha: serverning o'zi ham aytsin
# 503 javobida Retry-After: 45 bo'lsa, mijoz shunga bo'ysunsin.
# Bu serverga o'z tiklanish tezligini boshqarish imkonini beradi.

Oxirgi izohdagi g‘oya ko‘pincha e’tibordan chetda qoladi: server o‘z yukini o‘zi boshqarishi kerak. Mijoz backoff’i faqat taxmin qiladi; server esa hozirgi yukni biladi va mijozlarga aniq qachon qaytishni ayta oladi.

Hammasini birga, vaqt bo‘yicha ko‘ramiz — 180 000 ulanishli gateway yiqilganidan keyingi birinchi daqiqa, to‘g‘ri sozlangan tizimda:

Timeline’dagi eng muhim raqam — uchinchi qatordagi 87 ulanish/s har bir node’ga. Bu shunchalik kichikki, qolgan node’lar yiqilish bo‘lganini deyarli sezmaydi. Jittersiz esa xuddi shu 180 000 ulanish birinchi soniyada keladi: 2 600 ulanish/s har bir node’ga, har biri 3 ms CPU — ya’ni har bir node bitta soniyada ~8 CPU-soniyalik ish oladi: 16 yadrosining yarmi faqat qayta ulanishga ketadi, xabar yetkazish esa shu vaqtda navbatda kutadi. Farq — bitta konfiguratsiya qatori.

9.3 Degradatsiya tartibi

Tartibning mantig‘i ikkita tamoyilga tayanadi. Birinchisi — o‘tkinchi ma’lumot birinchi qurbon: yozmoqda va presence yo‘qolsa, hech narsa qaytarib bo‘lmaydigan tarzda yo‘qolmaydi. Ikkinchisi — real vaqt funksiya emas, optimallashtirish: 5-bosqichda WebSocket butunlay o‘chiriladi va tizim v0 ning so‘rov modeliga qaytadi. Sekin, lekin ishlaydi — chunki tarix haqiqat manbai (5.3-qadam) va quvib yetish mexanizmi allaqachon mavjud (5.8-qadam).

Bu ikkinchi nuqta arxitektura darajasidagi qaror: har doim real vaqtsiz ishlaydigan yo‘lni saqlang. Reddit darsida bu new tartibi edi, bu yerda u tarixdan quvib yetish. Har ikkalasi ham “eng murakkab qism butunlay o‘lsa, mahsulot baribir ishlaydi” degan kafolatni beradi.

10. Xavfsizlik: izolyatsiya va ilovalar

Slack’ga o‘xshash tizimning xavfsizlik modeli Reddit’nikidan tubdan farq qiladi. Reddit’da hamma narsa ommaviy va hujumchi e’tiborni o‘g‘irlaydi. Bu yerda hamma narsa yopiq va hujumchi ma’lumotni o‘g‘irlaydi — kompaniyaning ichki yozishmalari, mijoz ro‘yxatlari, parollar (odamlar ularni suhbatda yuboradi, qancha ogohlantirmang).

10.1 Ish maydoni izolyatsiyasi — birinchi va oxirgi chegara

Eng muhim qoida bitta: hech qanday so‘rov ish maydoni chegarasidan o‘tmasligi kerak. Bu tekshiruv bitta joyda emas, har bir qatlamda takrorlanishi shart.

Jadvalning oxirgi ustunini alohida o‘qing: har bir qatorda oqibat bir xil og‘irlikda — ma’lumot sizib chiqishi. Bu odatdagi xavfsizlik jadvallaridan farq qiladi, chunki odatda qatlamlar bir-birini qoplaydi: biri o‘tkazib yuborsa, ikkinchisi ushlaydi.

Bu yerda esa ular ketma-ket emas, parallel — har biri o‘z yo‘lini himoya qiladi. Gateway’dagi tekshiruv bazadagi xato WHERE ni to‘xtata olmaydi. Shuning uchun “biz API darajasida tekshiramiz” degan javob yetarli emas.

Amaliy yechim — tekshiruvni qo‘lga qoldirmaslik. Har bir baza so‘rovi ish maydoni kontekstidan o‘tadigan qatlam orqali yuboriladi:

# Yomon: har bir so'rovda dasturchi eslab qolishi kerak
db.query("SELECT * FROM messages WHERE channel_id = %s", (cid,))

# Yaxshi: kontekst majburiy, unutib bo'lmaydi
with workspace_scope(request.workspace_id) as db:
    db.query("SELECT * FROM messages WHERE channel_id = %s", (cid,))
    # -> avtomatik qo'shiladi: AND workspace_id = <kontekstdan>

Bu naqsh (Postgres’da row level security yoki ilova darajasidagi o‘ralgan ulanish) bitta muhim xususiyatga ega: yangi kod yozgan dasturchi xavfsizlikni buzish uchun ataylab harakat qilishi kerak. Unutish yetarli emas. Ko‘p foydalanuvchili tizimda bu — dizaynning eng muhim qismi.

10.2 Ilovalar va webhook’lar — eng katta hujum yuzasi

Slack’ning kuchi uchinchi tomon ilovalarida, va xavfsizlik muammosi ham o‘sha yerda. Ilova ish maydoniga o‘rnatilganda u token oladi, va o‘sha token ko‘pincha kerakidan ancha keng ruxsatga ega.

Oxirgi ikki qator eng muhimi. Bu hujumda hech narsa buzilmaydi — barcha so‘rovlar qonuniy, token haqiqiy, cheklovlar hurmat qilinadi. Klassik xavfsizlik nazorati (noto‘g‘ri parol, ruxsatsiz so‘rov, SQL in’ektsiyasi) buni ko‘rmaydi.

Shuning uchun bu yerda kerak bo‘lgan narsa — xatti-harakat bo‘yicha aniqlash:

Bu jadval bitta umumiy g‘oyani ko‘rsatadi: har bir ilova uchun normal xatti-harakat profilini saqlang va og‘ishni o‘lchang. Statik qoidalar (“soatiga 10 000 dan ko‘p o‘qish — shubhali”) ishlamaydi, chunki ilovalar juda xilma-xil: birov bitta kanalni kuzatadi, boshqasi butun arxivni indekslaydi va bu uning normal ishi.

Mahsulot tomonidagi javob ham muhim va u texnik emas:

• Ruxsatlar tor bo‘lsin — “barcha kanallar” o‘rniga “bu ilova qo‘shilgan kanallar”. Bu bitta qaror hujum yuzasini 10 000 kanaldan 3 taga tushiradi.
• Token muddati bo‘lsin — abadiy token abadiy xavf.
• Administrator ko‘ra olsin — qaysi ilova nimani o‘qidi, qachon.

10.3 Ma’lumotni saqlash muddati

Bu bo‘lim texnik emas, lekin u arxitekturaga to‘g‘ridan-to‘g‘ri ta’sir qiladi.

Korporativ mijozlar ikki qarama-qarshi narsani talab qiladi: hamma narsani abadiy saqlash (audit, huquqiy tekshiruv) va hamma narsani 30 kunda o‘chirish (maxfiylik siyosati, huquqiy xavfni kamaytirish). Ba’zan bir kompaniya ikkalasini ham — turli kanallar uchun.

Arxitekturaga ta’siri:

1. O‘chirish haqiqiy bo‘lishi kerak — bayroq emas. Demak qidiruv indeksidan, keshlardan, zaxira nusxalardan ham.
2. O‘chirish kanal darajasida sozlanadi, ya’ni siyosat ma’lumot bilan birga saqlanadi.
3. 5.8-qadamdagi “tarixdan quvib yetish” mexanizmi o‘chirilgan xabarlarga duch kelganda to‘g‘ri ishlashi kerak: mijozda ts bor, lekin xabar yo‘q — bu xato emas, normal holat.

Uchinchi nuqta ko‘pincha kech topiladi va u ishlab chiqarishda “kanal ochilmayapti” degan g‘alati xatolar keltirib chiqaradi.

11. Iqtisod: bitta ulanish qancha turadi

Reddit darsida xarajatning 91% i chiqish trafigi edi. Bu yerda taqsimot butunlay boshqacha, va farqning sababi o‘rganishga arziydi.

Uch tiyin. Bu raqam shunchalik kichikki, undan noto‘g‘ri xulosa chiqarish oson: “demak ulanishlar arzon, xohlagancha ochaveramiz”. Keling, boshqa moddalarni ham hisoblaymiz.

Jadval Reddit darsidagi taqsimotning teskarisi. U yerda trafik 91% edi, bu yerda 3%. Sabab bitta jumlada: Reddit ommaviy o‘qish tizimi, Slack esa yopiq yozish tizimi. Reddit’da bitta post millionlab marta o‘qiladi va har o‘qish trafik; Slack’da xabar 15 ta odamga boradi va u ham kichik.

Bundan uchta amaliy qaror chiqadi:

Birinchi: ulanish narxini optimallashtirish eng katta ta’sir beradi. 47% li moddada 30% tejash (masalan, SSL_MODE_RELEASE_BUFFERS va node boshiga ulanishni 180 K dan 250 K ga oshirish) umumiy xarajatning 14% ini beradi. Bu Reddit darsidagi CDN qaroriga o‘xshash “bitta sozlama, katta natija” holati.

Ikkinchi: xabarlarni saqlash muddati moliyaviy qaror. 24% li modda — Postgres, va u chiziqli o‘sadi. Saqlash siyosatini mahsulotning narx rejasiga bog‘lash (bepul reja — 90 kun, korporativ — cheksiz) — bu xususiyat emas, iqtisodiy zarurat.

Uchinchi: qidiruv indeksi kutilganidan qimmat. 13% — bu xabar saqlashning yarmi, garchi u faqat hosila ma’lumot bo‘lsa ham. Sababi: indeks xotirada bo‘lishi kerak, va u asl matndan 1.5–2 barobar katta. Shuning uchun qidiruvni ham saqlash siyosatiga bog‘lash mantiqiy — eski xabarlarni indeksdan chiqarib, “sekin arxiv qidiruvi” taklif qilish.

Bitta to'liq TLS 1.3 qo'l siqishi, server tomonda (bitta yadro, taxminan):

  RSA-2048 imzo            ~1.0 ms CPU
  ECDSA P-256 imzo         ~0.05-0.1 ms CPU
  ECDHE (X25519) kalit     ~0.05 ms CPU

  RSA sertifikat bilan:    ~1.05 ms
  ECDSA sertifikat bilan:  ~0.12 ms
  Farq: ~9 barobar

Sessiyani tiklash (resumption, PSK):
  imzo YO'Q -> ~0.05 ms, va 1 RTT o'rniga 0-RTT imkoniyati

RSA:    200 000 x 1.05 ms = 210 CPU-soniya
ECDSA:  200 000 x 0.12 ms =  24 CPU-soniya

10 a'zoli ish maydoni:
  ulanishlar: 3 ta -> 0.009 $/oy
  holat: har biri 10 a'zoni biladi, 15 KB -> arzimas
  xabarlar: kuniga 200 ta -> arzimas
  JAMI: ~0.05 $/oy, 10 kishiga

100 000 a'zoli ish maydoni:
  ulanishlar: 30 000 -> 86 $/oy
  holat (kesh bilan): 18 $/oy
  xabarlar: kuniga 100 000, 3 yil saqlash = 110 M xabar
    x 1 KB (matn + metama'lumot + indeks) = 110 GB
    Postgres + replikalar + zaxira = ~330 GB -> ~120 $/oy
  qidiruv indeksi: ~200 $/oy
  JAMI: ~424 $/oy, 100 000 kishiga = 0.004 $/kishi

12. Sig‘im rejalashtirish

Doimiy ulanishli tizimda sig‘im rejalashtirish boshqa tizimlardan bitta jihati bilan farq qiladi: chegaraga yetganingizni sekin bilasiz, lekin undan o‘tganingizni bir zumda bilasiz. So‘rov-javob tizimida yuk oshgan sari kechikish asta-sekin o‘sadi va sizda ogohlantirish bo‘ladi. Bu yerda node ulanishlarni ushlab turaveradi — toki xotira yoki fayl deskriptorlari tugab, u birdan yiqilguncha. Va u yiqilganda uning yuki qo‘shnilariga o‘tadi.

Shuning uchun quyidagi jadvaldagi signallar oddiygidan ham ertaroq qo‘yilgan.

Jadvalning signal ustunida bitta ham “foydalanuvchi soni” yo‘q, va bu Reddit darsidagi bilan bir xil sabab. Lekin bu yerda qo‘shimcha nozik jihat bor: C va D bosqichlaridagi signallar bir-biridan mustaqil. Siz 300 000 ulanishda chekka keshga muhtoj bo‘lasiz agar ish maydonlaringiz katta bo‘lsa; 3 000 ta kichik ish maydoni bilan esa 10 million ulanishgacha usiz yashaysiz.

Ya’ni bu yo‘l chiziqli emas. Sizning keyingi qadamingiz umumiy foydalanuvchi soniga emas, eng katta mijozingizning hajmiga bog‘liq.

Bu jadval darsning eng amaliy qismi bo‘lishi mumkin. Odatiy sig‘im rejalashtirish bitta o‘qda boradi — “qancha foydalanuvchi”. Ko‘p ijarachili (multi-tenant) tizimda esa ikkinchi o‘q ham bor: eng katta ijarachining hajmi, va ko‘pincha aynan u arxitekturani belgilaydi.

Xuddi shu naqsh boshqa joyda ham uchraydi: SaaS analitikasida — eng katta mijozning ma’lumot hajmi; CI tizimida — eng katta repozitoriyaning o‘lchami; fayl saqlashda — eng katta papkadagi fayllar soni. Har safar o‘rtacha yaxshi ko‘rinadi va eng katta ijarachi tizimni buzadi.

Uchta chegarani alohida hisoblash odati juda foydali, chunki qaysi biri g‘olib bo‘lishini oldindan taxmin qilib bo‘lmaydi. Bu misolda CPU chegarasi xotiradan 10 barobar uzoq — ya’ni ping/pong haqida qayg‘urish vaqtni behuda sarflash. Boshqa konfiguratsiyada (masalan, har 5 soniyada ping) u birinchi chegara bo‘lib chiqardi.

13. Kuzatuv: real vaqt buzilganini qanday bilasiz

Reddit darsida “jim buzilish” muammosi bor edi: reyting noto‘g‘ri ishlaydi, lekin hamma metrika yashil. Bu yerda muammo boshqacha va ba’zan yomonroq: xatolik darajasi nolga teng bo‘lishi mumkin, chunki so‘rov degan narsa yo‘q.

WebSocket ulanishida HTTP status kodi yo‘q. Xabar yuborildi — javob kelmaydi. Agar gateway xabarni tashlab yuborsa, hech kim xato qaytarmaydi: mijoz kutadi, server unutdi, va hech qanday metrika o‘zgarmaydi.

13.1 Ulanish qatlami metrikalari

ws_send_queue_depth — bu ro‘yxatdagi eng kam tushuniladigan va eng foydali metrika. U sekin mijozlarni ko‘rsatadi: mobil tarmoqdagi yoki brauzer yorlig‘i fonda qolgan foydalanuvchi freymlarni o‘qimaydi, navbat esa o‘sadi. Agar cheklov qo‘yilmasa, bitta sekin mijoz gateway xotirasini yeb qo‘yadi.

To‘g‘ri javob — navbatga chegara qo‘yish va oshib ketganda ulanishni uzish: mijoz qayta ulanadi va tarixdan quvib yetadi (5.8-qadam). Bu ataylab qilingan qaror: sekin mijozga xizmat qilishdan ko‘ra, uni uzib, tiklanish yo‘liga yuborish arzonroq.

connected_clients dagi node’lar orasidagi farq esa yuk balanslagichning to‘g‘ri ishlayotganini ko‘rsatadi. Doimiy ulanishlarda bu muammo o‘ziga xos: yangi node qo‘shsangiz, unga faqat yangi ulanishlar tushadi, eskilari esa eski node’larda qolaveradi. Node bir soatdan keyin ham bo‘sh bo‘lishi mumkin. Shuning uchun ba’zi tizimlar ataylab ulanishlarni davriy ravishda ko‘chiradi.

13.2 Yetkazish sifati metrikalari

catchup_gap_size — bu jadvaldagi eng qimmatli metrika va u tizimning o‘zidan tekin keladi. Mijoz qayta ulanganda ts > last_seen so‘rovini yuboradi va natija oladi. Agar natija bo‘sh bo‘lsa — real vaqt qatlami mukammal ishlagan. Agar 5 ta xabar qaytsa — demak o‘sha 5 tasi real vaqtda yetkazilmagan.

Ya’ni tiklanish mexanizmining o‘zi yetkazish sifatining o‘lchovi bo‘lib xizmat qiladi. Bu juda nafis naqsh: siz alohida tekshiruv qurmaysiz, mavjud mexanizmdan o‘lchov chiqarasiz.

Bu hisobning qiymati — sezish vaqtini ko‘rsatishida. Reddit darsida 1% yo‘qotishni sezish uchun 15 daqiqalik oyna kerak edi. Bu yerda namunalar soni ko‘p va signal kuchli, shuning uchun 10% li yo‘qotish bir necha soniyada ko‘rinadi.

13.3 Sintetik nazorat: ikkita kanareyka mijoz

Metrikalar qanchalik yaxshi bo‘lmasin, ular quvurning qismlarini o‘lchaydi. To‘liq yo‘lni faqat uchidan-uchiga test ko‘radi.

# Har mintaqada ikkita doimiy ulangan kanareyka mijoz
def canary_loop():
    while True:
        nonce = uuid4().hex
        t0 = time.monotonic()
        sender.send(channel=CANARY_CHANNEL, text=nonce)

        got = receiver.wait_for(nonce, timeout=5.0)
        if got is None:
            emit("canary_delivered", 0)
            alert("Kanareyka xabari 5 soniyada yetib kelmadi")
        else:
            emit("canary_delivered", 1)
            emit("canary_e2e_ms", (time.monotonic() - t0) * 1000)

        time.sleep(10)

Bu test bir vaqtda o‘nta narsani tekshiradi: ulanish tirikmi, autentifikatsiya ishlayaptimi, kanal shardi ts tayinlayaptimi, Postgres yozyaptimi, pub/sub e’lon qilyaptimi, obuna jadvali to‘g‘rimi, gateway freym yuboryaptimi.

Ikkita muhim tafsilot bor.

Birinchi: yuboruvchi va qabul qiluvchi boshqa node’da bo‘lishi shart. Aks holda test pub/sub’ni umuman tekshirmaydi — xabar bitta jarayon ichida o‘tib ketadi va hamma narsa yashil ko‘rinadi, holbuki gateway’lararo yo‘l uzilgan.

Ikkinchi: kanareyka mijozlari qayta ulanish mantig‘ini o‘chirmasin. Ular ham oddiy mijozlar kabi uzilib qayta ulansin — shunda siz qayta ulanish yo‘lini ham doimiy sinab turasiz. Ko‘p jamoalar kanareykani “barqaror” qilishga harakat qiladi va shu bilan eng zaif yo‘lni test qilmay qoldiradi.

14. Antinaqshlar

Quyidagi beshta qaror haqiqiy loyihalarda muntazam uchraydi. Har biri uchun avval nima uchun jozibali ekanini tushuntiramiz — chunki bu qarorlarni befarq odamlar emas, aqlli muhandislar qabul qiladi.

Birinchi qator jozibali, chunki u mijoz kodini bir necha barobar soddalashtiradi. Hech qanday “yuklanmoqda” holati, hech qanday keshni yangilash mantig‘i, hech qanday yo‘q obyekt bilan ishlash. Va u 1 000 a’zoli ish maydonida mukammal ishlaydi — 1.5 MB, bir soniyada yuklanadi. Muammo shundaki, bu qaror mahsulot muvaffaqiyatli bo‘lgandagina buziladi: birinchi yirik korporativ mijoz kelganda. Bu yerdagi dars — “hech qachon to‘liq holat yubormang” emas, balki o‘sish bo‘yicha kvadratik bo‘lgan har qanday narsani oldindan belgilab qo‘yish.

Ikkinchi qator jozibali, chunki presence obunasi mijoz tomonda haqiqiy ish talab qiladi: qaysi foydalanuvchilar ekranda ko‘rinayotganini kuzatish, kanal almashganda obunani yangilash, virtual ro‘yxatlarda scroll bilan sinxronlash. Eshittirish esa hech qanday kod talab qilmaydi. Va yana — kichik ish maydonida u to‘g‘ri yechim: 50 a’zoda eshittirish arzonroq va soddaroq. Kvadratik o‘sish yana o‘sha o‘yinni o‘ynaydi.

Uchinchi qator jozibali, chunki u talabnomani so‘zma-so‘z bajaradi. “Xabar yo‘qolmasligi kerak” → “demak yetkazilmaganlarni saqlaymiz”. Bu mantiq to‘g‘ri, lekin u noto‘g‘ri joyda holat yaratadi. Xabar allaqachon saqlangan — kanal tarixida. Ikkinchi nusxa faqat sinxronlash muammosini qo‘shadi. Umumiy qoida: yangi holat yaratishdan oldin, mavjud holat shu ishni bajara oladimi, deb so‘rang.

To‘rtinchi qator jozibali, chunki u haqiqatan ishlaydi va tezroq. Bog‘langan foydalanuvchining holati node’da issiq, marshrutlash jadvali kerak emas. Narx esa nosozlik paytida chiqadi: node o‘lganda uning foydalanuvchilari boshqa joyga borolmaydi — ular o‘sha node’ni kutadi. Va bundan ham yomoni: kattaroq ish maydonlari bir node’ga tushib qolsa, u doimiy issiq bo‘lib qoladi.

Beshinchi qator eng xavflisi, chunki uning zarari ko‘rinmaydi. Qolgan to‘rttasi ertami-kechmi ogohlantirish beradi: xotira tugaydi, trafik portlaydi, node yiqiladi. Soat farqi esa hech qachon xato bermaydi. Foydalanuvchilar javobni savoldan oldin ko‘radi, bir-ikkisi shikoyat qiladi, siz “brauzer keshi” deb o‘ylaysiz. Va ma’lumot allaqachon shu ts bilan yozilgan — orqaga qaytarib bo‘lmaydi.

15. Trade-off‘lar

Jadvalni juftliklar bo‘yicha o‘qing. Birinchi va to‘rtinchi qator bir xil almashtirishni bajaradi: server xotirasini tarmoq trafigiga almashtirish (aniqrog‘i, teskarisi — trafikni xotiraga). Ikkinchi va beshinchi qator ham juft: ikkalasi ham serverdagi holatni mijozga ko‘chiradi (kesh mijozda, kursor mijozda). Uchinchi va oltinchi qator esa kafolatni joyga bog‘laydi: tartib kafolati bitta yozuvchiga, noyoblik kafolati bitta identifikatorga.

Bu uch naqsh — xotira/trafik almashuvi, holatni mijozga ko‘chirish, kafolatni bitta nuqtaga bog‘lash — doimiy ulanishli har qanday tizimda qayta-qayta uchraydi. Agar siz shunday tizim quryotgan bo‘lsangiz, har bir qaroringizni shu uchtadan biriga joylashtirib ko‘ring; joylashmasa, ehtimol siz muammoni noto‘g‘ri qo‘ygansiz.

16. Intervyu savollari

Uch guruh: mexanizm (ulanish va protokol), miqyos (arxitektura qarorlari), tajriba (nosozlik va operatsiya). Har bir javobda raqam yoki mexanizm bor.

16.1 Mexanizm

16.2 Miqyos

16.3 Tajriba

17. Amaliyot

To‘rt daraja. Tekshiruv mezoni har doim o‘lchangan natija. Ikkinchi daraja uchun boshlang‘ich kod docs/amaliyot/slack/ da: yuk testi va o‘lchov qismi tayyor, mantiq qismi TODO.

18. Lug‘at

19. Raqamlar manbasi

Foydalanuvchilar soni, ulanishlar soni, ish maydoni hajmi, xabarlar chastotasi, foydalanuvchi obyektining hajmi va node sig‘imi — illyustratsiya uchun taxminiy raqamlar. Ular haqiqiy tizimlarning e’lon qilingan ko‘rsatkichlariga yaqin tartibda, lekin aniq emas. Ulanish boshiga 35 KB raqami esa konfiguratsiyaga juda bog‘liq — uni albatta 1-daraja topshirig‘ida o‘z muhitingizda o‘lchang.

20. Manbalar

• RFC 6455 — The WebSocket Protocol; freym formati, qo‘l siqish, ping/pong
• Slack muhandislik blogi, “Flannel: An Application-Level Edge Cache to Make Slack Scale” — chekka kesh g‘oyasining asl bayoni
• Slack API hujjatlari, Events API va Socket Mode — ts, client_msg_id va hodisa modeli
• AWS Architecture Blog, “Exponential Backoff and Jitter” — jitter turlarining taqqoslanishi va simulyatsiyasi
• Google SRE Book, “Addressing Cascading Failures” — zanjirli nosozlik va yuk tashlash
• “The C10K problem” (Dan Kegel) va uning davomi C10M — ko‘p ulanishli serverlarning klassik tahlili
• Linux epoll va tcp man sahifalari — soket sig‘imi va bufer sozlamalari