Twitter tasmasi qanday ishlaydi

Bu darsda nima o‘rganasiz

Oddiy tilda: siz har kuni ertalab o‘zingizga yoqqan 200 ta muallifning yangi maqolalarini o‘qimoqchisiz. Ikki yo‘l bor. Birinchisi — har ertalab 200 ta gazeta do‘koniga borib, har biridan oxirgi sonni olish. Ikkinchisi — mualliflar yangi maqola yozishi bilan uni sizning pochta qutingizga tashlab ketishlari, siz esa ertalab faqat qutini ochasiz. Ikkinchisi siz uchun ancha qulay. Lekin muallifning 100 million o‘quvchisi bo‘lsa, u bitta maqolani 100 million qutiga tashlashi kerak bo‘ladi.

Twitter tasmasi aynan shu ikki yo‘l orasidagi tanlov. “Twitter tasmasini loyihalang” — tizim dizayni intervyularidagi eng mashhur savol. U aldamchi: masala oddiy ko‘rinadi (“obunalarim yozgan narsalarni vaqt bo‘yicha ko‘rsat”), lekin ichida taqsimlangan tizimlarning eng nozik kelishuvlari yotadi.

Bu darsda asosiy savol bitta: ishni qachon bajaramiz — yozishda yoki o‘qishda? Javob “ikkalasida ham, lekin har xil odamlar uchun har xil” bo‘lib chiqadi. Nima uchun aynan shunday ekanini raqamda ko‘ramiz.

Dars noldan hozirgi holatigacha boradi. 2006-yildagi bitta Rails ilova va bitta MySQL bazadan boshlanadi. Keyin 2012-yilgi Redis klasteriga o‘tadi: u sekundiga 300 ming marta tasma o‘qishga xizmat qilgan. 2023-yilda Twitter o‘z tavsiya algoritmini ochiq e’lon qildi va bu algoritm kuniga milliardlab marta ishlaydi.

1. Muammo: aslida nimani qurmoqchimiz?

Oddiy tilda: tasma — sizning shaxsiy gazetangiz. Uni har kim uchun alohida, har necha soniyada yangidan “chop etish” kerak. Bunda yuzlab million o‘quvchi bor va har birining “mualliflar ro‘yxati” boshqacha.

1.1 Funksional talablar

1. Foydalanuvchi qisqa post (tweet) yozadi
2. Foydalanuvchi boshqalarga obuna bo‘ladi (bir tomonlama — do‘stlik emas)
3. Foydalanuvchi tasma ko‘radi: obuna bo‘lganlari yozgan postlar
4. Post yoqtiriladi, repost qilinadi, javob yoziladi
5. Qidiruv va xeshteglar

Bizni asosan 3-punkt qiziqtiradi. Qolgan hammasi shunga xizmat qiladi.

1.2 Nofunksional talablar

1.3 Konvert orqasidagi hisob

1.4 Bu masala qanday hal qilingan: qisqa tarix

Twitter‘ning arxitektura tarixi — bu darsdagi qarorlarning haqiqiy sabablari.

Raqamlar bilan: 2012-yilda Twitter muhandisi Raffi Krikorian QCon konferensiyasida tizimni ochiq tasvirlab berdi. O‘sha paytda 150 million faol foydalanuvchi bor edi, tasmalar sekundiga 300 ming marta o‘qilardi, kuniga 400 milliondan ortiq tweet yozilardi (o‘rtacha ~4 600 / s). Har foydalanuvchining uy tasmasi Redis klasterida ko‘pi bilan 800 ta yozuv sifatida saqlanardi. Maqsad esa “tweet 5 soniyada barcha obunachilarga yetsin” edi.

Diqqat qiling: har bir qadam oldingi qadamning muammosidan tug‘ilgan. Bu darsda ham xuddi shu yo‘ldan boramiz — chunki qarorni uning sababisiz o‘rganish yodlashdan farq qilmaydi.

2. Nol nuqta: tasma nima degan masala

Oddiy tilda: tasma uchun bor-yo‘g‘i ikki narsa kerak — postlar daftari (kim nima yozdi) va obunalar daftari (kim kimni o‘qiydi). Tasma — bu ikki daftarni “mening obunalarim yozgan oxirgi postlar” degan savol bilan birga ochish.

2.1 Ma’lumot modeli

Ikkita asosiy jadval yetarli:

CREATE TABLE tweets (
    id          BIGINT PRIMARY KEY,     -- vaqt bo'yicha tartiblanadigan ID (6-bo'lim, 7-qadam)
    author_id   BIGINT NOT NULL,
    text        VARCHAR(280) NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL,
    reply_to    BIGINT,                 -- javob bo'lsa
    quoted      BIGINT                  -- iqtibos bo'lsa
);

CREATE TABLE follows (
    follower_id  BIGINT NOT NULL,       -- kim obuna bo'ldi
    followee_id  BIGINT NOT NULL,       -- kimga
    created_at   TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (follower_id, followee_id)
);
CREATE INDEX idx_followee ON follows (followee_id);   -- "menga kim obuna?"

Diqqat: follows yo‘naltirilgan graf. Ikki xil savol beriladi va ular butunlay boshqacha ishlatiladi:

2.2 Tasma — bu bitta so‘rov

Mantiqan tasma juda oddiy:

SELECT t.*
FROM tweets t
JOIN follows f ON f.followee_id = t.author_id
WHERE f.follower_id = :men
ORDER BY t.id DESC
LIMIT 50;

Bu — butun mahsulotning yuragi. Va u ishlamaydi. Nega ishlamasligini keyingi bo‘limda raqam bilan ko‘ramiz.

2.3 Ikki yo‘l: ishni qayerda bajaramiz

Bu darsning markaziy tushunchasi. Har qanday “kim nimani ko‘radi” tizimida ikkita imkoniyat bor:

O‘qish yozishdan 100 barobar ko‘p bo‘lgani uchun intuitsiya “push” tomonga ishora qiladi. Lekin u bitta halokatli holatga uchraydi — 5.3-bo‘limda ko‘ramiz.

2.4 Graf qanchalik katta

Obunalar grafi — tizimdagi eng katta ma’lumotlardan biri va u ikki tomonlama saqlanadi.

1. following:A ga B qo'shildi     ✓
2. followers:B ga A qo'shilishi kerak... server tushdi  ✗

Natija: A o'zini B ga obuna deb ko'radi,
        lekin B ning postlari A ga tarqatilmaydi

3. v0: eng sodda ishlaydigan yechim

Oddiy tilda: har ertalab 200 ta gazeta do‘koniga borib, har biridan oxirgi sonni olish. Do‘konlar uyingiz yonida bo‘lsa va o‘quvchi siz yolg‘iz bo‘lsangiz — muammo yo‘q.

@app.post("/tweet")
def post_tweet(user_id, text):
    tweet_id = snowflake()                     # vaqt bo'yicha tartiblanadigan ID
    db.execute("INSERT INTO tweets (id, author_id, text) VALUES (%s,%s,%s)",
               (tweet_id, user_id, text))
    return tweet_id

@app.get("/timeline")
def timeline(user_id):
    return db.query("""
        SELECT t.* FROM tweets t
        JOIN follows f ON f.followee_id = t.author_id
        WHERE f.follower_id = %s
        ORDER BY t.id DESC LIMIT 50
    """, (user_id,))

Kod to‘g‘ri va kichik loyihada yillab ishlaydi. Endi uni raqamlar bilan buzamiz.

4. Nima sindi: v0 ning to‘rtta o‘limi

Oddiy tilda: endi o‘quvchi siz yolg‘iz emas — yuz million. Har biri har kuni o‘nlab marta 200 ta do‘konni aylanib chiqyapti. Do‘konlar bir shaharda ham emas, va ularning soatlari ham bir xil yurmaydi.

4.1 JOIN har safar minglab qatorni ko‘radi

4.2 Kesh yordam bermaydi

“Tasmani keshlaymiz” degan fikr birinchi bo‘lib keladi, lekin:

• Har bir foydalanuvchining tasmasi noyob (uning obunalari to‘plamiga bog‘liq)
• U doim o‘zgaradi — obunalaridan biri post yozsa, kesh eskiradi
• 500 million foydalanuvchi = 500 million alohida kesh yozuvi

Ya’ni klassik “so‘rov natijasini keshlash” bu yerda ishlamaydi. Kesh boshqacha qurilishi kerak — va bu 6-bo‘limning 1-qadami.

4.3 Postlar va obunalar bir joyda yashay olmaydi

tweets jadvali kuniga 300 million qator o‘sadi — yiliga ~110 milliard. follows jadvali esa milliardlab qator. Ikkalasi ham shardlanishi kerak, lekin turli kalitlar bo‘yicha:

• tweets — tweet ID bo‘yicha (yozish tekis taqsimlanadi)
• follows — foydalanuvchi ID bo‘yicha (bir odamning obunalari birga tursin)

Shardlangandan keyin ular orasida JOIN umuman mumkin emas — ular boshqa mashinalarda. Ya’ni 2.2-bo‘limdagi so‘rov nafaqat sekin, balki printsipial jihatdan bajarilmaydigan bo‘lib qoladi.

4.4 Tartib muammosi

ORDER BY created_at taqsimlangan tizimda ishonchsiz: turli serverlarning soatlari farq qiladi, bir xil millisekundda yozilgan postlar tartibi noaniq bo‘ladi va sahifalash (pagination) buziladi.

Bu kichik detal kabi ko‘rinadi, lekin u ID dizayni degan alohida masalaga olib keladi (6-bo‘lim, 7-qadam).

5. Ikki strategiya va ularning narxi

Oddiy tilda: yo do‘konlarni aylanish (pull), yo maqolani muallif darhol qutilarga tarqatishi (push). Birinchisi o‘quvchining vaqtini, ikkinchisi muallifning ishini yeydi. Mashhur muallif esa million qutiga tarqata olmaydi.

5.1 Fan-out on write: ishni yozishga ko‘chirish

G‘oya: post yozilganda darhol har bir obunachining tayyor tasmasiga uning ID sini qo‘shamiz. O‘qishda hech qanday hisob qolmaydi — tayyor ro‘yxat olinadi.

Post yozildi
  -> "menga kim obuna?" ro'yxatini olamiz  (200 kishi)
  -> har birining tasma ro'yxatiga ID qo'shamiz
       LPUSH timeline:<obunachi> <tweet_id>
       LTRIM timeline:<obunachi> 0 799

5.2 Fan-out on read: ishni o‘qishga qoldirish

G‘oya: hech narsa oldindan tayyorlanmaydi. Tasma so‘ralganda obunalar bo‘yicha har birining oxirgi postlari olinadi va birlashtiriladi.

Xulosa: sof pull ishlamaydi. Sof push esa ishlaydi — bitta holatdan tashqari.

5.3 Mashhur akkaunt muammosi

Obunachilar soni darajali taqsimot (power law) bo‘yicha tarqalgan: ko‘pchilikda yuzlab obunachi, bir nechtasida yuz millionlab.

Bundan ham yomoni — bu bitta post emas:

5.4 Gibrid yechim

Amaliy tizimlar ikkalasini birlashtiradi:

Yozish = Σ (obunachilar soni)  [obunachilari T dan kam bo'lgan akkauntlar bo'yicha]

O'qish = tasma_so'rovlari x (1 + o'rtacha_mashhur_obunalar_soni)

300 element, O(n log n) = 300 x 8.2 = ~2500 taqqoslash

O(n log k) = 300 x log2(6) = 300 x 2.6 = ~780 taqqoslash

6. Evolyutsiya: o‘n to‘rt qadam

Qadamlar mantiqiy tartibda: 1–5 — tasma keshi, tarqatish, gibrid, hidratsiya va o‘chirish; 6–8 — shardlash, ID va obunalar grafi; 9–12 — reyting, real vaqt, qidiruv va media; 13–14 — ko‘p mintaqa va cho‘qqidan himoya.

LPUSH  timeline:42  1712345678901234567
LTRIM  timeline:42  0 799           # faqat oxirgi 800 ta
LRANGE timeline:42  0 49            # tasmani o'qish

LRANGE timeline:42 0 49      -> 1-sahifa
LRANGE timeline:42 50 99     -> 2-sahifa

1-sahifa: oxirgi 50 ta, oxirgisining ID si = 1712345678901234567
2-sahifa: shu ID dan KICHIK bo'lgan keyingi 50 ta

def process(tweet_id, author_id):
    for chunk in graph.followers_chunked(author_id, size=1000):
        pipe = redis.pipeline()
        for follower in chunk:                 # 1000 ta obunachi
            key = f"timeline:{follower}"
            pipe.lpush(key, tweet_id)
            pipe.ltrim(key, 0, 799)
        pipe.execute()                          # BITTA tarmoq borish-kelishi
        checkpoint(tweet_id, chunk.cursor)      # to'xtasa shu yerdan davom etamiz

CELEBRITY_THRESHOLD = 100_000       # konfiguratsiyada, kodda emas

def on_new_tweet(tweet):
    n = graph.follower_count(tweet.author_id)      # keshlangan son
    if n < CELEBRITY_THRESHOLD:
        queue.publish("fanout", tweet.id)          # push
    # aks holda hech narsa — o'qishda qo'shiladi (pull)

1. LRANGE timeline:42 0 49          -> 50 ta ID
2. MGET tweet:<id1> ... tweet:<id50> -> 50 ta post (bitta komanda)
3. MGET user:<a1> ... user:<aN>      -> mualliflar (odatda 20-40 noyob)
4. Filtrlash: o'chirilganlar, bloklanganlar, yashirilganlar

tweet { id: 999, author: B, repost_of: 123 }

DELETE /tweet/123  ->  tweets jadvalida deleted = true
                   ->  tweet:123 keshi yangilanadi (yoki o'chiriladi)

Tasmalarda ID qoladi. Hidratsiya paytida:
  - post topilmadi yoki deleted = true -> ro'yxatdan tashlanadi

64 bitli butun son:

 1 bit  | 41 bit              | 10 bit      | 12 bit
 ishlatilmaydi | millisekundlar   | mashina ID  | ketma-ketlik

followers:<user>   -> ID lar to'plami (shardlangan)
following:<user>   -> ID lar to'plami
follower_count:<user> -> son (tez tekshirish uchun, 3-qadam)

Nomzodlar (300 ta ID)
  -> Xususiyatlar: muallif bilan aloqa, post yoshi, media bormi,
                   erta reaksiyalar, o'xshash postlarga munosabat
  -> Model bal beradi
  -> Yuqori 50 tasi

Post yozildi
  -> tokenizatsiya: so'zlar, xeshteglar, eslatmalar
  -> teskari indeks: so'z -> [post ID lari]
  -> real vaqtda indekslanadigan segment (xotirada)
  -> davriy ravishda diskdagi segmentga birlashtiriladi

Post: { text, media_ids: [...] }
Media: obyekt xotirada (S3 kabi), CDN orqali beriladi

7. Bitta postning hayoti

Evolyutsiyadan keyin tizim ko‘p qismli bo‘lib qoldi. Endi bitta postni yozilgan lahzadan obunachining ekraniga chiqqungacha kuzatamiz. Shunda har qism nega kerakligi va “5 soniya” va’dasi qanday bajarilishi ko‘rinadi.

7.1 Qadam-baqadam

Oddiy tilda: siz xatni pochtaga topshirdingiz va chek oldingiz. Shu lahzada xatingiz arxivga yozildi va o‘zingizning qutingizga nusxasi tushdi. Qolgan ishni pochtachilar fonda qiladi: ro‘yxatdan sizning o‘quvchilaringizni topib, minglab qutiga bir yo‘la tashlaydi.

1. ID — Snowflake (7-qadam): koordinatsiyasiz, vaqt bo‘yicha tartiblangan.
2. Saqlash — post manba bazaga yoziladi. Shu paytdan u yo‘qolmaydi.
3. O‘z tasmasi — muallif o‘z postini darhol ko‘radi (10.2 dagi yagona qat’iy talab). Bu tarqatishni kutmaydi.
4. Navbat — tarqatish vazifasi navbatga tushadi. Muallif javobni oldi.
5. Graf — “menga kim obuna?” ro‘yxati bo‘laklarda o‘qiladi.
6. Tasmalar — har bo‘lakka bitta pipelined so‘rov: LPUSH + LTRIM.
7. O‘qish — obunachi tasmani ochganda ID lar olinadi, hidratsiya va filtr qo‘llanadi, mashhurlarning postlari pull qilinib qo‘shiladi.

7.2 “5 soniya” byudjeti

7.3 Push, pull va gibrid — o‘lchovda

2-daraja amaliyotida 8 000 foydalanuvchili darajali grafda (median — 9 obunachi, eng mashhurida 6 447) bir xil yuklama turli chegaralar bilan o‘tkaziladi. Har foydalanuvchi 2 ta post yozadi va 20 marta tasma o‘qiydi:

Bu jadval 5-bo‘limdagi Deep bilan birga o‘qilishi kerak. Real tizimda gibrid narx jihatidan ham yutadi, chunki uchta omil bu modelda yo‘q:

1. Faol bo‘lmagan obunachilar — mashhur akkauntning obunachilari orasida hozir tasmani o‘qimaydiganlar ko‘p. Ularga yozish — sof isrof (6-bo‘lim 1-qadam).
2. Pull arzon o‘qish — mashhur akkauntning oxirgi postlari juda issiq kalit, u keshda va bitta MGET bilan olinadi. Bu tasmaga yozish bilan bir xil narx emas.
3. Burst — 100 mln yozuv bir lahzada tushadi va navbatni bo‘g‘adi. Narx o‘rtacha yuk bilan emas, cho‘qqi bilan to‘lanadi.

8. “Sizga tavsiya”: 2023-yilgi ochiq algoritm

8.1 Oddiy tilda: shaxsiy muharrir

Oddiy tilda: xronologik tasma — qutingizga tushgan hamma xatni vaqt bo‘yicha o‘qish. “Sizga tavsiya” esa shaxsiy muharrir. U har ertalab siz obuna bo‘lganlarning xatlaridan, boshqa minglab mualliflarning xatlaridan ham bir dasta tanlaydi va sizga eng qiziq bo‘ladiganlarini tartib bilan qo‘yadi. Muharrir sizni qanchalik yaxshi bilsa, shuncha yaxshi tanlaydi — lekin u qimmat, va har ertalab yuz million odam uchun ishlaydi.

8.2 Uch bosqich

2023-yil 31-martda Twitter “Sizga tavsiya” tasmasini tuzadigan kodning katta qismini ochiq e’lon qildi va blogda uni tasvirlab berdi. Asosiy raqamlar: quvur kuniga ~5 milliard marta ishlaydi, har safar yuzlab million postdan ~1 500 ta nomzod tanlanadi, ular ~48 million parametrli neyron tarmoq bilan baholanadi. O‘rtacha foydalanuvchi tasmasining taxminan yarmi obunalaridan, yarmi esa obunadan tashqaridan keladi.

1. Nomzodlar manbalari. Obunalardan keladiganlar — aynan shu darsda qurgan tizim (push + pull) va obunalaringiz bilan aloqangiz kuchini baholaydigan model. Obunadan tashqari nomzodlar uchun esa o‘xshash foydalanuvchilar jamoalari, siz kuzatganlar yoqtirgan postlar va embedding bo‘shliqlari ishlatiladi.
2. Reyting. Har nomzod uchun model bir necha ehtimolni bashorat qiladi: yoqtirish, javob yozish, repost, uzoq o‘qish va salbiy reaksiyalar. Yakuniy ball — ularning og‘irlikli yig‘indisi.
3. Evristika. Model yaxshi bo‘lsa ham, natija “inson qoidalari” bilan tuzatiladi: bitta muallifdan ketma-ket ko‘p post bo‘lmasin, bloklangan va ko‘rilgan postlar chiqmasin, obunalar va boshqalar muvozanatda bo‘lsin.

8.3 Narxi

9. Bugungi arxitektura

9.1 Tasma so‘rovining kechikish byudjeti

9.2 Tasma API si

Mijoz bilan shartnoma tizimning imkoniyatlarini belgilaydi — noto‘g‘ri API keyin o‘zgartirib bo‘lmaydigan cheklovlar yaratadi.

GET /v1/timeline?limit=20&cursor=1712345678901234567

{
  "items": [ { "id": "...", "author": {...}, "text": "...", "stats": {...} } ],
  "next_cursor": "1712345600000000000",
  "has_more": true
}

10. Ishonchlilik

10.1 Nosozliklar taksonomiyasi

rebuild_timeline(user_id):
    following = graph.following(user_id)          # 200 ta
    oddiy = [u for u in following if not is_celebrity(u)]
    ids = []
    for u in oddiy:
        ids += user_tweets(u, limit=100)          # profil indeksidan
    ids.sort(reverse=True)
    redis.rpush(f"timeline:{user_id}", *ids[:800])

10.2 Izchillik kelishuvlari

Bu tizimda hech narsa kuchli izchil emas va bu ongli tanlov:

Yagona qat’iy talab: o‘z posti darhol ko‘rinsin. Foydalanuvchi post yozib, o‘z tasmasida uni ko‘rmasa — “ishlamadi” deb qayta yozadi. Shuning uchun o‘z posti mahalliy ravishda, tarqatishni kutmasdan qo‘shiladi.

10.3 Degradatsiya tartibi

10.4 Javoblar: tasmadagi eng nozik qoida

Post — bu tekis ro‘yxatdagi element emas: unga javob yoziladi, javobga yana javob. Savol: javob kimning tasmasiga tushishi kerak?

Sodda javob (“muallifning barcha obunachilariga”) yomon ishlaydi:

A -> B ga javob yozdi
A ning 5000 obunachisi B ni bilmaydi
Ular kontekstsiz javobni ko'radi: "ha, roziman"

Amaliy qoida — kesishma: javob faqat ikkalasiga ham obuna bo‘lganlarga ko‘rsatiladi.

Asl post
├── javob 1
│   ├── javob 1.1
│   └── javob 1.2
└── javob 2

10.5 Bloklash, yashirish va filtrlar

Foydalanuvchi kimnidir bloklasa yoki yashirsa (mute), uning postlari tasmada ko‘rinmasligi kerak. Savol: bu qachon qo‘llanadi?

To‘g‘ri javob — o‘qish paytida, va sabab 6-bo‘limning 5-qadamidagi bilan bir xil: bloklash o‘zgarganda millionlab tasmani qayta yozib bo‘lmaydi.

11. Suiiste’mol va xavfsizlik

Ijtimoiy tarmoqda asosiy tahdid — texnik emas, ijtimoiy:

11.1 Bildirishnomalar: teskari fan-out

Tasma — “men kimni o‘qiyman”. Bildirishnomalar — “menga kim murojaat qildi”. Bu teskari yo‘nalish va u boshqacha muammo tug‘diradi.

Tasma:            1 post -> N obunachi   (fan-out)
Bildirishnoma:    N reaksiya -> 1 muallif (fan-in)

Agregatsiya oynali bo‘ladi: bir necha daqiqalik oynada bir xil turdagi reaksiyalar bitta yozuvga birlashtiriladi. Bu ham yozishni o‘qishga ko‘chirishning yana bir ko‘rinishi — faqat bu safar teskari tomonda.

Postlar:      3 500/s  -> fan-out 700 000 yozuv/s
Yoqtirishlar: 50 000/s -> fan-out 10 000 000 yozuv/s

12. Iqtisod

Diqqat: xarajatning yarmi o‘qish yo‘liga ketadi va uning katta qismi reyting. Xronologik tasma bir necha barobar arzon — bu mahsulot qarorining to‘g‘ridan-to‘g‘ri narxi.

13. Sig‘im rejalashtirish

14. Kuzatuv

15. Antinaqshlar

16. Trade-off‘lar

Butun dars o‘nta gapda

1. Tasma — “ishni qachon bajarish” masalasi: o‘qishda (pull) yoki yozishda (push); o‘qish yozishdan 65–100 barobar ko‘p bo‘lgani uchun asosiy yo‘l — push (1.3, 5).
2. JOIN bilan tasma shardlashdan keyin umuman ishlamaydi: postlar va obunalar turli kalitlar bo‘yicha turli mashinalarda yotadi (4).
3. Tasma keshi — ID lar ro‘yxati, postning o‘zi emas: 8 bayt, 800 ta chegara, faqat faol foydalanuvchilar uchun (6-bo‘lim 1-qadam).
4. Mashhur akkaunt sof push’ni buzadi: bitta post — 100 mln yozuv va butun navbatning kechikishi (5.3, 7.2).
5. Gibrid — dum uchun: amallar soni bo‘yicha push arzonroq bo‘lishi mumkin, lekin pull eng katta fan-out’ni va cho‘qqini cheklaydi (5.4, 7.3).
6. O‘qishda birlashtirish — k-way merge: tayyor tasma + mashhurlar ro‘yxatlari, faqat kerakli N tasini olish, keyin deduplikatsiya va filtr (5.4 Deep, 2-daraja amaliyot).
7. O‘chirish, bloklash, yashirish — o‘qishda filtr: millionlab tasmani qayta yozish o‘rniga tombstone va ortiqcha nomzod (6-bo‘lim 5-qadam, 10.5).
8. Snowflake — vaqt bo‘yicha tartiblangan, koordinatsiyasiz ID: kursor bilan sahifalash va shardlash shundan oson (6-bo‘lim 7-qadam).
9. Tasma — hosila ma’lumot: uni manbadan qayta qurish mumkin, va bu butun tizimning xavfsizlik to‘ri (10.1).
10. “Sizga tavsiya” — ko‘p bosqichli voronka: ~1 500 nomzod, og‘ir model va evristikalar; push/pull tasma endi nomzodlar manbalaridan biri (8).

17. Intervyu savollari

17.1 Asoslar

17.2 Ma’lumot va saqlash

17.3 Kelishuvlar

obunalar ro'yxati -> har birining oxirgi postlari -> birlashtirish -> kesh

17.4 Amaliy stsenariylar

18. Amaliyot

To‘rt daraja. Ikkinchi daraja uchun kod va avtomatik tekshiruvlar docs/amaliyot/twitter/ da: snowflake.py, timeline.py — TODO; model.py — tayyor soxta soat va darajali obunalar grafi; check.py — 13 ta tekshiruv.

19. Lug‘at

20. Raqamlar manbasi

500 mln kunlik foydalanuvchi, kuniga 300 mln post, 60 marta ochish, 200 ta o‘rtacha obuna, kesh va graf hajmlari, server soni va narxlar, kechikish byudjeti — illyustratsiya uchun taxminiy raqamlar. Ular 2012-yilgi ochiq raqamlar tartibida tanlangan (1.4 dagi hisob). Twitter (hozir X) ichki tizimi o‘sha davrdan beri ko‘p o‘zgargan va har detali ochiq emas. Asosiy xulosalar — o‘qish ustunligi, ID lar keshi, gibrid fan-out, o‘qishdagi filtrlar va ko‘p bosqichli reyting — bu raqamlarning bir necha barobarlik xatosiga ham chidamli.

21. Manbalar

• Raffi Krikorian (2012), “Timelines at Scale”, QCon San Francisco — slaydlar va video; High Scalability: “The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS…”
• Twitter Engineering (2010), “Announcing Snowflake”
• Twitter Engineering (2023), “Twitter’s Recommendation Algorithm” va the-algorithm ochiq repozitoriysi
• Martin Kleppmann (2017), Designing Data-Intensive Applications, 1-bob — Twitter tasmasi fan-out kelishuvining klassik tahlili
• Twitter Engineering, “Earlybird: Real-Time Search at Twitter” (ICDE 2012)
• Instagram Engineering, “Sharding & IDs at Instagram”
• Redis hujjatlari: LPUSH, LTRIM, LRANGE, ZADD, pipelining