როგორ ამუშავებთ 5M ხმას 10 წუთში მასშტაბით?

Question

IT Interview Practice · Accepted Answer

ნუ ჩაწერთ თითო ხმას პირდაპირ მონაცემთა ბაზის მწკრივში — **ბუფერიზება გაუკეთეთ write-ებს, დაანაწილეთ (shard) counter-ები და მიიღეთ eventual tally**. 5M ხმა 10 წუთში საშუალოდ ~8,300 ხმა/წამია, spike-ებით ბევრად მაღალი (ცოცხალი ტელე-მომენტმა შეიძლება 10-ჯერ გაზარდოს). ხრიკი არის ცხელი ერთ-მწკრივიანი update-ის ბევრ დამოუკიდებელ, პარალელურ increment-ად ქცევა.

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## რატომ უნდა ბუფერიზება write-ებს

queue-ი, როგორიც **Kafka**-ა, მიჯნავს ingestion-ს tally-სგან. კლიენტის write იაფი append-ია; თუ consumer-ები spike-ის დროს ჩამორჩნენ, event-ები ლოგში ელოდებიან DB-ს გადატვირთვის ნაცვლად. Kafka ასევე იძლევა **replay**-ს — თუ consumer ჩავარდა, ბოლო committed offset-იდან ხელახლა ამუშავებთ ხმების დაკარგვის გარეშე.

## Sharded counter-ები კლავს hotspot-ს

თუ ყოველი ხმა "Option A"-სთვის აკეთებს `UPDATE counter SET n=n+1 WHERE id='A'`, ეს ერთი მწკრივი lock-contention bottleneck-ად იქცევა — ათასობით transaction ერთ მწკრივზე სერიალიზდება. ამის ნაცვლად, დაყავით თითო option **N shard მწკრივად** (`A:0 … A:63`). თითო increment შემთხვევით shard-ს ხვდება, ასე რომ write-ები N მწკრივზე ნაწილდება და პარალელურად სრულდება. საჩვენებელი ჯამი არის `SUM(shards)`, გამოთვლილი aggregator-ის მიერ ყოველ წამში ან ორში. Redis-ში ეს უბრალოდ N `INCR` გასაღებია; DynamoDB-ში — N partition key.

## One-vote dedup

დააწესეთ "ერთი ხმა თითო მომხმარებელზე" idempotency key-ით: `SADD voted:{pollId} {userId}` (ან conditional put). თუ მომხმარებელი უკვე არსებობს, ჩამოაგდეთ event increment-მდე. ეს გააკეთეთ consumer-ში, არა კლიენტში — კლიენტები ტყუიან და ხელახლა ცდილობენ.

## ინტერვიუს პერსპექტივა

ინტერვიუერი ამოწმებს, ცნობთ თუ არა **single-hot-key პრობლემას** და მიდიხართ თუ არა ბუფერიზება + sharding-კენ, და არა "დაამატე მეტი DB replica"-კენ (replica-ები read-ს მასშტაბირებენ, არა ამ write-ს). კარგი: "გამოიყენე queue და cache." შესანიშნავი: ასახელებთ **eventual-consistency ტრეიდ-ოფს** — ცოცხალი ციფრი წამით ჩამორჩება რეალობას — და ამტკიცებთ, რომ ეს კარგია ხმების დათვლისთვის, მაგრამ *არა* საბოლოო სერტიფიცირებული შედეგისთვის, რომელსაც ავტორიტეტულად თავიდან გამოთვლით გამოკითხვის დახურვის შემდეგ.

**გავრცელებული ხაფანგი:** მონაცემთა ბაზის transaction-ის გამოყენება თითო ხმაზე "სიზუსტისთვის". ამ მასშტაბზე სწორედ ეს დნება.

## ტრეიდ-ოფები და ჩავარდნის რეჟიმები

- **Eventual tally:** shard ჯამები ჩამორჩება; მისაღებია ცოცხალი counter-ისთვის, შეაჯერეთ დახურვისას.
- **At-least-once delivery:** Kafka-მ შეიძლება ხელახლა მიაწოდოს — dedup increment-ებს idempotent-ს ხდის, თორემ ორმაგად ითვლით.
- **Hot shard skew:** ცოტა shard და მაინც contention გაქვთ; ბევრი და ჯამვა ძვირდება. 32–128 shard ტიპურია.
- **Fairness/fraud:** rate-limit თითო IP/მოწყობილობაზე; one-vote SET არის თქვენი მთლიანობის საზღვარი. მისი დაკარგვა ნიშნავს ballot stuffing-ს, არა crash-ს — სავარაუდოდ უარესია.

რატომ უნდა ბუფერიზება write-ებს

Sharded counter-ები კლავს hotspot-ს

One-vote dedup

ინტერვიუს პერსპექტივა

ტრეიდ-ოფები და ჩავარდნის რეჟიმები

დაკავშირებული კითხვები