Reddit qanday ishlaydi

Bu darsda nima o‘rganasiz

Reddit tashqaridan oddiy: postlar bor, ularga ovoz beriladi, eng yaxshisi yuqorida turadi. Lekin “eng yaxshisi” degan so‘z ichida butun bir matematika yashiringan — va u aynan formulada yozilgan, ML modelida emas.

Bu dars ikkita savol atrofida quriladi:

1. Reytingni qanday hisoblaymiz? Ovozlar soni yetarli emas — 5 yil oldingi 10 000 ovozli post bugungi 50 ovozlidan yuqori turmasligi kerak
2. Reytingni qachon hisoblaymiz? Har so‘rovda hisoblash imkonsiz; har ovozda qayta tartiblash ham qimmat

Twitter darsida savol “ishni qachon bajarish” edi. Bu yerda u aniqroq shaklga kiradi: tartiblangan ro‘yxatni qachon yangilash.

1. Muammo: aslida nimani qurmoqchimiz?

1.1 Funksional talablar

1. Foydalanuvchi post joylaydi (matn, havola, rasm)
2. Postga ijobiy yoki salbiy ovoz beriladi
3. Postlar tartiblangan ro‘yxatda ko‘rsatiladi: hot, new, top, controversial
4. Postga kommentariya yoziladi; kommentariyaga javob yoziladi (ichma-ich)
5. Kommentariyalar ham ovoz oladi va tartiblanadi
6. Hamma narsa jamoa (subreddit) ichida bo‘ladi

1.2 Nofunksional talablar

1.3 Konvert orqasidagi hisob

Ikkita nisbat darhol ko‘zga tashlanadi:

O‘qish / yozish = 100:1. Twitter darsidagi bilan bir xil — demak xulosa ham bir xil: ishni o‘qish paytiga qoldirmaslik kerak, ro‘yxatlar oldindan tayyorlanadi.

Ovoz / post = 100:1. Bu esa yangi muammo: har bir ovoz reytingni o‘zgartiradi, ya’ni sekundiga 2315 marta tartiblangan ro‘yxatni yangilash kerak bo‘lishi mumkin. 6-bo‘limda buni qanday yengillashtirish mumkinligini ko‘ramiz.

2. Nol nuqta: ma’lumot modeli

CREATE TABLE posts (
    id          BIGINT PRIMARY KEY,       -- vaqt bo'yicha tartiblanadigan
    subreddit_id BIGINT NOT NULL,
    author_id   BIGINT NOT NULL,
    title       TEXT NOT NULL,
    body        TEXT,
    created_at  TIMESTAMPTZ NOT NULL,
    ups         INT NOT NULL DEFAULT 0,   -- denormallashtirilgan
    downs       INT NOT NULL DEFAULT 0,
    comment_count INT NOT NULL DEFAULT 0,
    deleted     BOOLEAN NOT NULL DEFAULT false
);

CREATE TABLE votes (
    user_id     BIGINT NOT NULL,
    thing_id    BIGINT NOT NULL,          -- post yoki kommentariya
    direction   SMALLINT NOT NULL,        -- +1, -1
    created_at  TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (user_id, thing_id)       -- bir odam bir marta ovoz beradi
);

CREATE TABLE comments (
    id          BIGINT PRIMARY KEY,
    post_id     BIGINT NOT NULL,          -- ildiz post
    parent_id   BIGINT,                   -- NULL bo'lsa — birinchi daraja
    author_id   BIGINT NOT NULL,
    body        TEXT NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL,
    ups         INT NOT NULL DEFAULT 0,
    downs       INT NOT NULL DEFAULT 0
);

Uchta qaror darhol e’tiborni tortadi:

votes jadvalida birlamchi kalit (user_id, thing_id). Bu “bir odam — bir ovoz” qoidasini baza darajasida ta’minlaydi. Ilovada tekshirish poyga holatiga olib keladi (2-darsdagi maxsus kalitlar bilan bir xil muammo).

ups va downs postda saqlanadi. Bu denormalizatsiya: har safar votes dan COUNT(*) qilish imkonsiz bo‘lardi. Narxi — izchillikni qo‘lda ta’minlash.

comments.post_id va parent_id alohida. post_id bo‘lmasa, butun suhbatni olish uchun rekursiv so‘rov kerak bo‘lardi; u bilan esa bitta so‘rovda hammasi olinadi va daraxt ilovada quriladi (7-bo‘lim).

+1  ijobiy ovoz
-1  salbiy ovoz
 0  ovoz bekor qilingan (yoki yozuv o'chiriladi)

3. Reyting matematikasi: darsning yuragi

3.1 Nega oddiy hisoblagich yetarli emas

Postlarni ups - downs bo‘yicha tartiblasak, uchta muammo chiqadi:

Kerak bo‘lgan narsa: ovozlar soni ham, postning yoshi ham hisobga olinadigan bitta son. Va u shunday bo‘lsinki, yangi postlar eskilarini asta-sekin surib chiqarsin.

3.2 “Hot” formulasi

Reddit‘ning tarixiy “hot” formulasi ochiq va uni to‘liq tushunish mumkin:

t = post yaratilgan vaqt (belgilangan boshlanish nuqtasidan soniyalarda)
x = ups - downs
y = sign(x)                      -- +1, 0 yoki -1
z = max(|x|, 1)

hot = log10(z) + (y * t) / 45000

Ikki qismdan iborat: ovozlar qismi (log10(z)) va vaqt qismi (t / 45000).

Bu jadval formulaning butun mohiyatini ochadi. Uni konkret misolda ko‘ramiz:

3.3 Salbiy ballar va sign(x)

Formuladagi y = sign(x) ko‘pchilikni chalkashtiradi. U shu uchun kerak: agar post salbiy ballga ega bo‘lsa, vaqt qo‘shiluvchisi ham manfiy bo‘ladi.

Ijobiy post (x = +100):  hot = 2 + t/45000    -> vaqt YORDAM beradi
Neytral post (x = 0):    hot = 0 + 0          -> vaqt umuman ta'sir qilmaydi
Salbiy post (x = -100):  hot = 2 - t/45000    -> vaqt ZARAR qiladi

Natijasi qiziq: yangi salbiy post eski salbiy postdan pastroq turadi. Ya’ni yomon qabul qilingan yangi kontent tezda pastga tushadi va u yerda qoladi.

3.4 Boshqa tartiblash usullari

controversial formulasi qiziq: u ovozlar ko‘p va teng taqsimlangan bo‘lganda yuqori bal beradi.

magnitude = ups + downs
balance = min(ups, downs) / max(ups, downs)
controversy = magnitude ^ balance

500/500 taqsimotda balance = 1 va bal 1000 bo‘ladi; 990/10 da esa balance ≈ 0.01 va bal deyarli 1 ga tushadi. Ya’ni formula “ko‘p odam qarama-qarshi fikrda” degan holatni topadi.

Har bir tartib alohida ro‘yxat demak — va bu 6-bo‘limdagi asosiy xarajat manbai.

3.5 Kommentariyalar uchun boshqa formula: Wilson intervali

Kommentariyalarda vaqt unchalik muhim emas (ular baribir bitta post ichida), lekin boshqa muammo bor: kam ovozli kommentariyalar.

Wilson intervali savolni boshqacha qo‘yadi: “mavjud ma’lumotga asoslanib, bu kommentariyaning haqiqiy ijobiylik ulushi kamida qancha bo‘lishi mumkin?”

p = ups / n              -- kuzatilgan ulush
n = ups + downs          -- jami ovoz
z = 1.96                 -- 95% ishonch darajasi

           p + z²/2n − z·√( (p(1−p) + z²/4n) / n )
score = ────────────────────────────────────────────
                        1 + z²/n

4. v0: eng sodda ishlaydigan yechim

@app.post("/vote")
def vote(user_id, thing_id, direction):
    old = db.query_one("SELECT direction FROM votes WHERE user_id=%s AND thing_id=%s",
                       (user_id, thing_id))
    db.execute("""INSERT INTO votes (user_id, thing_id, direction) VALUES (%s,%s,%s)
                  ON CONFLICT (user_id, thing_id) DO UPDATE SET direction = %s""",
               (user_id, thing_id, direction, direction))
    # hisoblagichlarni tuzatamiz
    db.execute("UPDATE posts SET ups = ups + %s, downs = downs + %s WHERE id = %s",
               (delta_ups(old, direction), delta_downs(old, direction), thing_id))

@app.get("/r/<sub>/hot")
def hot_listing(sub):
    return db.query("""
        SELECT *, LOG(10, GREATEST(ABS(ups - downs), 1))
                  + SIGN(ups - downs) * EXTRACT(EPOCH FROM created_at) / 45000 AS hot
        FROM posts
        WHERE subreddit_id = %s AND NOT deleted
        ORDER BY hot DESC
        LIMIT 25
    """, (sub,))

Kod to‘g‘ri va kichik jamoada yaxshi ishlaydi. Endi uni buzamiz.

5. Nima sindi

5.1 Har so‘rovda butun jamoani hisoblash

Indeks ham yordam bermaydi: hot — bu hisoblanadigan qiymat va u vaqt bilan uzluksiz o‘zgaradi. Uni indekslash uchun har soniyada butun indeksni qayta qurish kerak bo‘lardi.

5.2 Ovoz — bu bitta qatorga yozish

Mashhur post sekundiga 500 ovoz olsa, bu bitta qatorga sekundiga 500 ta UPDATE. Tranzaksiyalar navbatga tizilib, qulf raqobati boshlanadi va ovoz javobi sekundlarga cho‘ziladi.

Bu — Redis darsidagi issiq kalit muammosining bazadagi ko‘rinishi.

5.3 Beshta tartib — beshta muammo

hot, new, top, rising, controversial — va top uchun yana vaqt oynalari (kun, hafta, oy, yil, butun vaqt). Jami bitta jamoa uchun 10 dan ortiq ro‘yxat. Har birini har so‘rovda hisoblash imkonsiz.

5.4 Kommentariya daraxti rekursiv

-- Bitta postning barcha kommentariyalari, daraxt shaklida
WITH RECURSIVE tree AS (...)

Rekursiv so‘rov 500 000 kommentariyali postda daqiqalar ishlaydi. Va natija baribir kerak emas — foydalanuvchi birinchi 200 tasini ko‘radi.

5.5 Ovozni kim berganini tekshirish

Foydalanuvchi ro‘yxatni ochganda, u qaysi postlarga allaqachon ovoz berganini ko‘rishi kerak (o‘q rangi o‘zgaradi). Bu 25 ta post uchun 25 ta so‘rov degani — klassik N+1 muammosi.

6. Evolyutsiya: o‘n to‘rt qadam

-- Davriy tekshiruv (kechasi, kichik paketlarda)
UPDATE posts p SET ups = v.up_count, downs = v.down_count
FROM (SELECT thing_id,
             COUNT(*) FILTER (WHERE direction = 1)  AS up_count,
             COUNT(*) FILTER (WHERE direction = -1) AS down_count
      FROM votes WHERE thing_id = ANY(%s) GROUP BY thing_id) v
WHERE p.id = v.thing_id;

ZADD listing:r/programming:hot  <hot_bali>  <post_id>
ZREVRANGE listing:r/programming:hot 0 24     -- ro'yxatni o'qish

1. ZREVRANGE listing:r/x:hot 0 24        -> 25 ta ID
2. MGET post:<id1> ... post:<id25>        -> mazmun
3. MGET user:<a1> ... user:<aN>           -> mualliflar
4. HMGET votes:user:42 <id1> ... <id25>   -> mening ovozlarim (bitta so'rov!)

ko'rsatiladigan_son = haqiqiy_son + shovqin(post_id, vaqt_oynasi)

7. Kommentariya daraxti

Postlar ro‘yxati — tekis ro‘yxat. Kommentariyalar esa daraxt, va bu butunlay boshqa masala.

7.1 Daraxtni qanday saqlash

Uchinchisi amaliy g‘olib va sabab shundaki, u saqlash strukturasini so‘rov naqshiga moslaydi:

SELECT * FROM comments WHERE post_id = 8891 ORDER BY id;
-- bitta indeks bo'yicha ketma-ket o'qish, rekursiya yo'q

Barcha kommentariyalar bitta so‘rovda keladi (ular bitta shardda yotadi), daraxt esa ilovada O(n) da quriladi: har bir kommentariyani parent_id bo‘yicha xaritaga joylash yetarli.

def build_tree(comments):
    by_id = {c.id: {**c, "children": []} for c in comments}
    roots = []
    for c in by_id.values():
        if c["parent_id"] is None:
            roots.append(c)
        else:
            parent = by_id.get(c["parent_id"])
            if parent:
                parent["children"].append(c)
            else:
                roots.append(c)      # ota o'chirilgan yoki yuklanmagan
    return roots

7.2 500 000 kommentariyani qanday ko‘rsatasiz

Hech qanday tarzda — va bu to‘g‘ri javob.

Tanlash strategiyasi:

1. Birinchi daraja kommentariyalaridan eng yaxshi 50 tasi (Wilson bo‘yicha)
2. Har birining ostidan eng yaxshi 3–5 ta javob, 3-darajagacha
3. Qolgani “ko‘proq ko‘rsatish” tugmasi ostida yashiriladi
4. Chuqurroq shoxlar “davomini ko‘rish” havolasi bilan alohida sahifada ochiladi

Post
├── Kommentariya (bal 0.94)
│   ├── javob (0.81)
│   ├── javob (0.77)
│   └── [ yana 43 ta javob ]        <- lazy yuklash
├── Kommentariya (0.89)
│   └── javob (0.66)
│       └── [ davomini ko'rish ]     <- alohida so'rov
└── [ yana 1 247 ta kommentariya ]

7.3 Sahifalash: daraxt uchun kursor ishlamaydi

Tekis ro‘yxatda kursor oddiy (2-darsdagi kabi). Daraxtda esa “keyingi 50 ta” degan tushuncha noaniq: keyingi nimaning ostida?

Amaliy yechim — har bir yashirilgan tugun uchun alohida so‘rov:

GET /post/8891/comments?parent=45678&sort=best&limit=50

Ya’ni sahifalash butun daraxt bo‘yicha emas, har bir tugun ichida amalga oshiriladi. Bu mahsulot uchun ham tabiiy: foydalanuvchi “keyingi 50 ta kommentariya” emas, “shu suhbatning davomi” ni so‘raydi.

7.4 Kommentariyalarni tartiblash

Muhim tafsilot: tartiblash har bir daraja ichida alohida qo‘llanadi. Ya’ni birinchi daraja Wilson bo‘yicha tartiblanadi, har bir kommentariyaning javoblari ham o‘z ichida — lekin daraxt strukturasi buzilmaydi.

8. Bugungi arxitektura

8.1 Ro‘yxat so‘rovining kechikish byudjeti

Bu jadval 6-bo‘limning 3-qadamini oqlaydi: ro‘yxatni oldindan hisoblaganimiz uchun eng qimmat qism (tartiblash) butunlay yo‘qolgan. Qolgan hamma narsa — ma’lumotni yig‘ish, va u parallel bajariladi.

9. Ishonchlilik

9.1 Nosozliklar taksonomiyasi

9.2 Ro‘yxatni qayta qurish

Ro‘yxatlar — hosila ma’lumot, ularni har doim postlar jadvalidan tiklash mumkin:

def rebuild_listing(subreddit_id, kind="hot", limit=1000):
    posts = db.query("""SELECT id, ups, downs, created_at FROM posts
                        WHERE subreddit_id = %s AND NOT deleted
                          AND created_at > now() - interval '30 days'""",
                     (subreddit_id,))
    scored = [(hot_score(p), p.id) for p in posts]
    scored.sort(reverse=True)
    redis.zadd(f"listing:{subreddit_id}:{kind}",
               {pid: s for s, pid in scored[:limit]})

30 kunlik chegara muhim: hot ro‘yxatiga eski postlar baribir tushmaydi, ularni hisoblash esa vaqt oladi. Bu — ishni kerakli qismi bilan cheklash naqshi.

1. listing:r/x:hot:rebuild ga to'liq yangi ro'yxatni yozing
2. RENAME listing:r/x:hot:rebuild listing:r/x:hot

9.3 Degradatsiya tartibi

Bu tartibning mantig‘i: o‘qish yozishdan muhimroq, va reyting aniqligi mavjudlikdan muhimroq emas. Foydalanuvchi ro‘yxat 5 soniya eskirganini sezmaydi; sahifa ochilmaganini esa darhol sezadi.

10. Xavfsizlik: ovoz manipulyatsiyasi

Reyting tizimining xavfsizlik yuzasi boshqa tizimlarnikidan tubdan farq qiladi. Bank tizimida hujumchi pulni o‘g‘irlashga harakat qiladi va buni aniq ko‘rsatib bo‘ladi: hisobdan pul ketdi. Reyting tizimida hujumchi e’tiborni o‘g‘irlaydi — va bu o‘g‘irlikning “jabrlanuvchisi” yo‘q. Hech kim shikoyat qilmaydi, chunki hech kim o‘zi ko‘rmagan postni sog‘inmaydi.

Shuning uchun bu bo‘limni “qo‘shimcha” deb o‘ylamang. Reyting tizimida manipulyatsiyaga qarshi himoya — mahsulotning o‘zi, keyin qo‘shiladigan qatlam emas. Agar birinchi sahifani pul bilan sotib olish mumkin bo‘lsa, sizda reyting tizimi yo‘q, sizda reklama platformasi bor — faqat pul sizga tushmaydi.

10.1 Hujum turlari

Diqqat qiling: jadvalning yuqori qismidagi hujumlarni texnik aniqlash mumkin (bir IP, bir qurilma barmoq izi), pastki qismidagilarni esa faqat naqsh orqali. Bu ikki xil mudofaa demakdir — va ular bir-birini almashtira olmaydi. Sock puppet uchun qurilma identifikatsiyasi kerak; vote ring uchun grafik tahlili kerak. Agar sizda faqat birinchisi bo‘lsa, siz eng arzon hujumni to‘xtatib, eng samaralisini o‘tkazib yuborasiz.

Ikkinchi diqqat: oxirgi qatorni qarang. Vaqt hujumi formulaning o‘zidan kelib chiqadi. 3.2-bo‘limda ko‘rgan edik: 45 000 soniya = 1 ball = 10 barobar ovoz. Demak yangi postga berilgan 60 ovoz, 12 soat oldingi 600 ovozga teng. Bu xato emas, bu — dizayn qarori; lekin har bir dizayn qarori o‘z hujum yuzasini yaratadi. Yangilikni mukofotlaysizmi? Unda hujumchi yangilik oynasiga hujum qiladi.

10.2 Nima uchun oddiy chegara ishlamaydi

Birinchi g‘oya har doim bitta: “bitta IP dan soatiga 10 tadan ko‘p ovoz qabul qilmaymiz”. Buni raqam bilan tekshiraylik.

Bu — chegaraga asoslangan har qanday himoyaning umumiy kasalligi: halol foydalanuvchilarning taqsimoti hujumchi taqsimoti bilan kesishadi. Agar kesishmasa, chegara ishlaydi (masalan, sekundiga 1000 so‘rov — hech bir odam buni qo‘lda qilmaydi). Kesishsa — chegara faqat qaysi tomonni qurbon qilishni tanlaydi.

Shuning uchun jiddiy tizimlar chegara emas, ishonch ballari bilan ishlaydi: har bir ovozning og‘irligi 0 dan 1 gacha bo‘lgan son, akkaunt tarixiga bog‘liq.

def vote_weight(user, post):
    w = 1.0
    age_days = (now() - user.created_at).days
    if age_days < 1:   w *= 0.0     # bugun ochilgan akkaunt — ovoz sanalmaydi
    elif age_days < 7: w *= 0.3
    elif age_days < 30: w *= 0.7

    if user.karma < 10:  w *= 0.5   # hech qanday hissa qo'shmagan
    if user.email_verified is False: w *= 0.5

    # Bu foydalanuvchi shu muallifga necha marta ovoz bergan?
    affinity = redis.get(f"aff:{user.id}:{post.author_id}") or 0
    if affinity > 20:   w *= 0.2    # "do'stlar guruhi" belgisi

    return w

Bu kodning eng muhim qismi — oxirgisi. Birinchi to‘rtta shart akkauntning o‘zini baholaydi; oxirgisi munosabatni baholaydi. Vote ring aynan shu yerda ochiladi: har bir akkaunt alohida mukammal ko‘rinadi, lekin ular doim bir-biriga ovoz beradi.

10.3 Vote ring ni grafik sifatida ko‘rish

Vote ring ni topishning eng ishonchli usuli — ovozlarni ikki tomonlama graf deb ko‘rish: bir tomonda foydalanuvchilar, ikkinchi tomonda postlar, qirralar — ovozlar. Halol foydalanuvchilar grafi tarqoq bo‘ladi; ring esa zich klaster hosil qiladi.

Oxirgi eslatma — bu bo‘limning eng muhim jumlasi. Agar siz kesishuvni butun sayt bo‘yicha hisoblasangiz, r/uzbekistan ning 200 ta doimiy o‘quvchisi ham “ring” bo‘lib chiqadi: ular tabiiy ravishda bir xil postlarni ko‘radi. Baseline har doim kontekst ichida hisoblanishi kerak — aks holda siz o‘z eng sodiq foydalanuvchilaringizni jazolaysiz.

def ring_score(user_a, user_b, window_days=7):
    a = set(redis.smembers(f"voted:{user_a}:{window_days}d"))
    b = set(redis.smembers(f"voted:{user_b}:{window_days}d"))
    if len(a) < 10 or len(b) < 10:
        return 0.0                       # ma'lumot yetarli emas
    jaccard = len(a & b) / len(a | b)
    # Jamoa ichidagi o'rtacha kesishuv — baseline
    return jaccard / (baseline_jaccard(user_a.top_sub) + 1e-9)

Amalda bu hisob real vaqtda emas, kunlik batch vazifada bajariladi: 200 million ovozdan graf qurish sekundlar emas, daqiqalar ishi. Natija — shubhali juftliklar ro‘yxati — moderatsiya navbatiga tushadi. Avtomatik blok yo‘q. Sababi oddiy: yolg‘on pozitiv narxi bu yerda juda yuqori, chunki bloklangan halol foydalanuvchi qaytib kelmaydi.

10.4 Ovoz raqamlarini “xiralashtirish”

6-bo‘limda ovoz raqamlarini biroz tasodifiy o‘zgartirish (vote fuzzing) haqida qisqa aytdik. Endi sababini to‘liq ochamiz, chunki bu — noaniq ko‘rinadigan, lekin chuqur qaror.

Agar interfeys aniq raqam ko‘rsatsa (1 247), hujumchi mukammal qayta aloqa halqasiga ega bo‘ladi: u ovoz beradi, sahifani yangilaydi, raqam o‘zgardimi — ko‘radi. Bir necha urinishda u sizning barcha filtrlaringizni teskari muhandislik qiladi: qaysi akkaunt sanaladi, qaysi sanalmaydi, chegara qayerda.

Bu — kriptografiyadan tanish naqsh: oracle ni yo‘q qilish. Siz hujumni imkonsiz qilmaysiz, uni qimmat qilasiz. 25 barobar qimmat hujum ko‘p hollarda umuman bo‘lmaydigan hujumdir.

Narxi ham bor va uni ochiq aytish kerak: foydalanuvchilar raqamlarga ishonmay qo‘yadi, “nega mening postimda 3 ovoz kamayib qoldi” degan savollar paydo bo‘ladi, va sizning o‘z analitikangiz ham xiralashadi. Shuning uchun ikkita raqam saqlanadi: haqiqiy (ichki, analitika va reyting uchun) va ko‘rsatiladigan (shovqin bilan). Reyting doim haqiqiysidan hisoblanadi — aks holda siz o‘z tizimingizga shovqin kiritgan bo‘lasiz.

11. Iqtisod: bitta ro‘yxat ko‘rinishi qancha turadi

Reyting tizimining iqtisodi noodatiy: eng ko‘p pul ovozga emas, o‘qishga ketadi. Bu intuitiv emas, chunki ovoz “yozish” bo‘lib tuyuladi va yozish qimmat deb o‘rgatilgan. Keling, hisoblaymiz.

Oxirgi qatorda ataylab to‘xtadik. 10.8 petabayt chiqish trafigi AWS narxlarida oyiga 500 000 dollardan ortiq turadi — ya’ni butun qolgan infratuzilmadan 10 barobar qimmat. Bu — yangi boshlanuvchilar hisobda deyarli har doim o‘tkazib yuboradigan raqam, va u mahsulot qarorlarini butunlay o‘zgartiradi.

Jadval bitta narsani aytadi: siz optimallashtirishni noto‘g‘ri joydan boshlaysiz. Muhandisning tabiiy instinkti — SQL so‘rovni tezlashtirish, kesh urish darajasini 94% dan 97% ga chiqarish. Bu 4% li moddaning ichida qo‘lga kiritilgan 20% — ya’ni umumiy xarajatning 0.8% i. Bir kunlik CDN sozlash esa 91% li moddani uchdan biriga tushiradi.

Bundan uchta amaliy qaror chiqadi:

Birinchi qaror: media hech qachon sizning serverlaringizdan o‘tmaydi. Rasm va video to‘g‘ridan-to‘g‘ri obyekt saqlashdan, CDN orqali beriladi. Ilova faqat URL qaytaradi. Bu 40 KB li javobni 4 KB ga tushiradi.

Ikkinchi qaror: JSON javobini qisqartirish haqiqiy pul. Ro‘yxat javobida har bir post uchun to‘liq matn emas, 200 belgilik parcha qaytariladi. 25 ta post × 2 KB tejash = 50 KB. Bu “mikro-optimallashtirish” emas — bu oyiga o‘n minglab dollar.

Uchinchi qaror: sahifa hajmi mahsulot emas, iqtisod qarori. Sahifada 25 ta post ko‘rsatasizmi yoki 50 tami — bu chiqish trafigini ikki barobar o‘zgartiradi. To‘g‘ri javob foydalanuvchilarning nechtasi ikkinchi sahifaga o‘tishiga bog‘liq: agar 30% o‘tsa, 25 tadan berish arzonroq; agar 80% o‘tsa, 50 tadan berish arzonroq (chunki ikkinchi so‘rovning o‘z qo‘shimcha narxi bor).

12. Sig‘im rejalashtirish

Sig‘im rejalashtirish — bu “qancha server kerak” degan savol emas. Bu qachon arxitekturani o‘zgartirish kerak degan savol. Har bir arxitektura o‘z diapazonida to‘g‘ri; muammo shundaki, diapazondan chiqqaningizni odatda ishlamay qolganda bilasiz.

Quyidagi jadval — shu darsda qurgan tizimning bosqichlari. Har bir qatorda “nima ishlaydi” va “qaysi signal keyingi qatorga o‘tish vaqti kelganini aytadi”.

Jadvalning eng muhim ustuni — oxirgisi. Diqqat qiling, hech bir signal “foydalanuvchilar soni 1 000 000 dan oshdi” emas. Foydalanuvchi soni yomon signal: 1 000 000 passiv o‘quvchi 50 000 faol muhokamachidan kamroq yuk beradi. Signallar tizimning o‘z o‘lchovlari bo‘lishi kerak — kechikish, CPU, replikatsiya lagi, shardlar nomutanosibligi.

Ikkinchi diqqat: signallar oldindan ishlaydi. “p99 > 200 ms” — bu hali buzilmagan tizim; foydalanuvchi buni sezmaydi. Agar siz signalni “sahifa ochilmayapti” deb qo‘ysangiz, o‘tish migratsiyasini panika ichida qilasiz. Migratsiya esa haftalar oladi — demak signal haqiqiy chegaradan kamida bir chorak oldin yonishi kerak.

Bu hisobning oxirgi ikki qatori — sig‘im rejalashtirishning butun mohiyati. “Qachon to‘yadi” savoli emas, “qachon ishni boshlash kerak” savoli. Formulasi oddiy: to‘yish vaqtidan migratsiya davomiyligini ayiring, keyin xavfsizlik uchun yana yarmini ayiring.

13. Kuzatuv: reyting buzilganini qanday bilasiz

Reyting tizimining kuzatuvi klassik tizimlardan bitta muhim jihati bilan farq qiladi: buzilish jim bo‘ladi. Agar Redis o‘lsa, siz buni 30 soniyada bilasiz — xatolik darajasi sakraydi, pager jiringlaydi. Agar reyting formulasi noto‘g‘ri ishlay boshlasa — masalan, ovoz ishchisi ba’zi guruhlarni tashlab ketsa — hech qanday xatolik yo‘q. Sahifa ochiladi, postlar chiqadi, hamma yashil. Faqat noto‘g‘ri postlar chiqadi.

Shuning uchun bu yerda ikki qatlam kuzatuv kerak: infratuzilma sog‘lig‘i (hammaga tanish) va reyting sog‘lig‘i (bu domenga xos).

13.1 Infratuzilma metrikalari

Bu jadvalda diqqat qilinadigan narsa — vote_queue_lag va vote_queue_depth alohida turishi. Ular bir xil emas: chuqurlik katta bo‘lib, lag kichik bo‘lishi mumkin (cho‘qqi paytida navbat to‘ldi, lekin ishchilar tez ishlayapti), va aksincha — chuqurlik kichik bo‘lib, lag katta bo‘lishi mumkin (bitta bo‘lim tiqilib qolgan, qolganlari bo‘sh). Ikkinchisi ancha yomon holat, va faqat chuqurlikni kuzatsangiz, uni ko‘rmaysiz.

shard_write_skew — 12-bo‘limdagi Zipf muammosining bevosita o‘lchovi. Uni kuzatmaslik odatiy xato: sizda 10 ta shard bor, o‘rtacha yuk 40%, hammasi joyida ko‘rinadi — lekin bittasi 85% da va u birinchi bo‘lib yiqiladi.

13.2 Reyting sog‘lig‘i metrikalari

Bu jadval oldingisidan tubdan boshqacha: unda hech bir chegara qattiq raqam emas, hammasi trend. Sababi shundaki, bu metrikalarning “to‘g‘ri” qiymati yo‘q — sizning jamoangizda hot_top10_churn 40% bo‘lishi normal, boshqasida 15%. Muhimi — u kecha 40% bo‘lib, bugun 3% bo‘lib qolganmi.

Eng qimmatli metrika — oxirgisi. listing_position_ctr normal tizimda keskin pasayuvchi egri chiziq bo‘ladi: 1-pozitsiya 2-dan ancha ko‘p bosiladi, 25-si deyarli bosilmaydi. Agar bu egri tekislashsa, demak tartiblash endi foydalanuvchi qiziqishi bilan bog‘liq emas — ya’ni reyting ishlamayapti, garchi barcha texnik metrikalar yashil bo‘lsa ham.

Bu hisobning amaliy xulosasi: kichik yo‘qotishlarni real vaqtda tutib bo‘lmaydi. Shuning uchun vote_apply_ratio ga qo‘shimcha ravishda kunlik yarashtirish (reconciliation) vazifasi kerak: navbatdagi barcha ovoz identifikatorlarini va bazadagi barcha ovozlarni solishtirish. Bu sekin, lekin aniq. Real vaqt metrikasi katta buzilishni tutadi; yarashtirish sizilishni tutadi.

13.3 Sintetik nazorat

Eng kuchli vosita — o‘z tizimingizga soxta post joylash. Har 10 daqiqada kanareyka post yaratiladi, unga ma’lum sonli ovoz beriladi va kutilgan pozitsiya hisoblanadi.

def canary_check():
    post = create_post(sub="r/system_design_canary", title=f"canary {now()}")
    for u in canary_users[:40]:
        vote(u, post.id, +1)
    sleep(30)                            # navbat qo'llashini kutamiz
    expected = hot_score(ups=40, downs=0, created_at=post.created_at)
    rank = redis.zrevrank(f"listing:{post.sub_id}:hot", post.id)
    stored = redis.zscore(f"listing:{post.sub_id}:hot", post.id)

    emit("canary_rank", rank)
    emit("canary_score_error", abs(stored - expected))
    if rank is None or rank > 3:
        alert("Kanareyka post ro'yxatga tushmadi")

Bu test uchta bosqichni birdan tekshiradi: ovoz qabul qilindimi, ishchi uni qo‘lladimi, ro‘yxat yangilandimi. Uchtasidan bittasi buzilsa — signal keladi, va hech bir foydalanuvchi shikoyat qilmaguncha. Sintetik nazoratning qiymati shunda: u passiv metrikalar ko‘rmaydigan “jim buzilish” ni ko‘radi.

14. Antinaqshlar

Quyidagi to‘rt qaror birinchi qarashda mantiqiy ko‘rinadi. Har biri haqiqiy loyihalarda uchraydi va har biri o‘z narxini kech ko‘rsatadi. Har birida avval nima uchun jozibali ekanini tushuntiramiz — chunki xatoni faqat “noto‘g‘ri” deb belgilash uni takrorlashdan saqlamaydi.

Birinchi qator — eng keng tarqalgan xato, va u eng jozibali, chunki u to‘g‘ri. Reytingni o‘qishda hisoblash aniqroq natija beradi va kesh muammolarini butunlay yo‘q qiladi. U faqat bitta sabab bilan ishlamaydi: miqyos. 100 foydalanuvchida bu eng yaxshi arxitektura; 100 000 da — halokat. Bu yerdagi dars “hech qachon o‘qishda hisoblamang” emas, balki “qaysi miqyosda ekaningizni biling”. v0 ni to‘g‘ri qurgan odam D bosqichida boshqa narsa qurishi kerakligini oldindan biladi.

Ikkinchi qator jozibali, chunki u eng sodda mustahkamlik hikoyasini beradi: ovoz keldi — ro‘yxat yangilandi, orada hech narsa yo‘q, yo‘qotish imkoni yo‘q. Narxi esa taqsimotda yashiringan: ovozlar postlar bo‘yicha tekis tarqalmaydi. Bir vaqtning o‘zida trend bo‘layotgan bitta post butun ovozlarning 5–10% ini oladi, va u bitta ZSET a’zosiga aylanadi. Yechim — 6-bo‘limdagi guruhlash; lekin uni birinchi kundan qurish shart emas, faqat qachon kerak bo‘lishini biling (12-bo‘lim, C bosqichi).

Uchinchi qator jozibali, chunki rekursiv CTE chiroyli SQL. Va u 200 ta kommentariyada mukammal ishlaydi — ya’ni sizning barcha testlaringizda. Muammo faqat AMA postida, kechqurun, 500 000 kommentariyada ko‘rinadi. Bu — test ma’lumotlari taqsimoti ishlab chiqarish taqsimotidan farq qilishi ning klassik namunasi. 7.2-bo‘limda buni raqam bilan ko‘rdik.

To‘rtinchi qator jozibali, chunki u “bitta haqiqat manbai” tamoyiliga mos keladi — bu odatda yaxshi tamoyil. Lekin bu yerda shovqin ataylab kiritilgan yolg‘on; uni haqiqat manbaiga aylantirish — yolg‘onni tizimning ichkarisiga tarqatish. Qoida: himoya uchun kiritilgan buzilish faqat chiqish chegarasida bo‘lsin.

15. Trade-off‘lar

Jadvalni ustunlar bo‘yicha emas, juftliklar bo‘yicha o‘qing. Birinchi ikki qator bir xil narsani aytadi: ikkalasi ham yangilikni aniqlikka almashtiradi. Uchinchi va oltinchi qator ham juft: ikkalasi ham hisoblash narxini foydalanuvchi tajribasiga almashtiradi. To‘rtinchi va beshinchi qator esa yolg‘iz — ular boshqa o‘lchamdagi qarorlar (taqsimlanish va xavfsizlik).

Bu naqsh tasodifiy emas. Reyting tizimida deyarli barcha qarorlar bitta o‘qda yotadi: qanchalik eski ma’lumot bilan yashay olasiz? Ro‘yxat 1 soniya eskimi yoki 5 soniyami; ovoz darhol qo‘llanadimi yoki 100 ms kechmi; daraxt keshi 10 s yashaydimi yoki 60 s. Har bir javob narxni o‘nlab barobar o‘zgartiradi va foydalanuvchi tajribasini deyarli o‘zgartirmaydi — chegaraga yetgunicha.

16. Intervyu savollari

Savollar uch guruhga bo‘lingan: mexanizm (formula va ma’lumot modeli), miqyos (arxitektura qarorlari), va tajriba (nosozlik va operatsiya). Har bir javobda raqam yoki mexanizm bor — “kesh ishlatamiz” tipidagi javob intervyuda ball bermaydi.

16.1 Mexanizm

16.2 Miqyos

16.3 Tajriba

17. Amaliyot

To‘rt daraja. Har birida tekshiruv mezoni o‘lchangan natija — “ishladi” emas. Ikkinchi daraja uchun boshlang‘ich kod docs/amaliyot/reddit/ da: o‘lchov va grafik qismi tayyor, mantiq qismi TODO.

18. Lug‘at

19. Raqamlar manbasi

Foydalanuvchi soni, kunlik post va ovozlar soni — illyustratsiya uchun taxminiy raqamlar. Ular Reddit ning e’lon qilingan ko‘rsatkichlariga yaqin tartibda, lekin aniq emas; darsdagi barcha hisoblar shu farazlardan kelib chiqadi va ularni o‘z loyihangiz raqamlari bilan almashtirishingiz kerak.

20. Manbalar

• Reddit ochiq kodi, r2/lib/db/_sorts.pyx — hot, confidence (Wilson) va controversy funksiyalarining asl matni
• Amir Salihefendic, “How Reddit ranking algorithms work” — formulalarning batafsil tahlili
• Evan Miller, “How Not To Sort By Average Rating” — Wilson intervali nima uchun kerakligi haqida asosiy maqola
• Edwin B. Wilson (1927), “Probable Inference, the Law of Succession, and Statistical Inference” — intervalning dastlabki ta’rifi
• Redis hujjatlari, Sorted Sets — ZSET operatsiyalari va murakkabligi
• Reddit muhandislik blogi — sharding, kesh va ro‘yxatlar haqidagi yozuvlar
• Hacker News reyting formulasi (news.arc) — taqqoslash uchun soddaroq model