როგორ ააგებთ real-time view/like counter-ს ვირუსული პოსტებისთვის?

Question

IT Interview Practice · Accepted Answer

არასდროს გააკეთოთ `UPDATE posts SET views = views + 1` თითო event-ზე ცხელ პოსტზე — ის ერთი მწკრივი lock-ის bottleneck-ად იქცევა. **გაზარდეთ Redis-ში, batch-ით ჩააფლაშეთ DB-ში** ყოველ რამდენიმე წამში და წაიკითხეთ count Redis-იდან. DB durable ჯამებს ინახავს, არა ცოცხალ ტრაფიკს.

## არქიტექტურა

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## კომპონენტები და ნაკადი

- **Redis INCR** შთანთქავს write-ის ქარიშხალს. ერთი `INCR views:{post}` ატომურია და 100k+ ops/s ამუშავებს ერთ გასაღებზე — რიგებით მეტი, ვიდრე Postgres-ის მწკრივი. ეს counter არის source of truth *წაკითხვისთვის*, ასე რომ მაყურებლები ციფრს მყისვე ხედავენ.
- **Dedup like-ებისთვის/უნიკალური view-ებისთვის**: უბრალო counter refresh-ებს ორმაგად ითვლის. გამოიყენეთ `SADD seen:{post} {userId}` და `INCR` მხოლოდ მაშინ, როცა დამატება ახალია; მასიური მასშტაბით იაფი მიახლოებითი უნიკალურებისთვის გამოიყენეთ **HyperLogLog** (`PFADD`/`PFCOUNT`) — რამდენიმე KB აფასებს მილიონობით უნიკალურს ~2% ცდომილებით.
- **Batch-ური flusher** პერიოდულად აცლის delta-ს DB-ში: `UPDATE posts SET views = views + delta`. ყოველ 5 წამში ან ყოველ N increment-ზე ჩაფლაშვა მილიონ write-ს რამდენიმედ აქცევს — DB ინახავს durable ჯამს ცივი პოსტებისა და ანალიტიკისთვის.
- **Read path** Redis-იდან ემსახურება; cache miss-ის დროს DB ჯამს კითხულობს და Redis-ს ხელახლა ათბობს. like-ებს სჭირდება per-user მდგომარეობა (მოვიწონე *მე* თუ არა), ამიტომ შეინახეთ set, არა უბრალოდ ციფრი.

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

ინტერვიუერები ამოწმებენ, იღებთ თუ არა **eventual consistency-ს count-ებისთვის**. "კარგი" არის "დააქეშე count"; "შესანიშნავი" არის *write*-ების ბუფერიზება — იმის აღიარება, რომ bottleneck არის write contention ცხელ მწკრივზე, არა read load. ისინი ამოწმებენ ტრეიდ-ოფს: მიახლოებითი count მისაღებია? view count-ისთვის — კი, არავინ ამჩნევს 1,203,428 vs 1,203,450-ს. ხაფანგია ზუსტი count-ებზე ფიქრი და transaction-ისკენ წვდომა, რაც ხელახლა ამატებს lock-ს, რომელსაც არიდებდით.

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

- **Accuracy vs throughput**: ზუსტ count-ებს სჭირდება dedup set-ები (მეხსიერების ხარჯი); მიახლოებითი HyperLogLog პატარა და სწრაფია. აირჩიეთ თითო feature-ზე — like-ები ზუსტია, view count-ები შეიძლება მიახლოებითი იყოს.
- **Durability**: Redis in-memory-ია. თუ ის ჩაფლაშვამდე მოკვდა, ჩაუფლაშავ delta-ს კარგავთ. ჩართეთ AOF და შეინახეთ flush ფანჯრები მოკლე (წამები), რომ დანაკარგი შემოსაზღვროთ; DB ჯამი პლუს პატარა ხარვეზი მისაღებია view counter-ისთვის.
- **Hot key**: ვირუსული პოსტი მთელ ტრაფიკს ერთ Redis გასაღებზე აგროვებს. დაყავით `views:{post}:{0..9}`-ად და შეაჯამეთ წაკითხვისას, ან მიმართეთ ცხელი გასაღებები გამოყოფილ node-ზე, რომ ერთმა პოსტმა shard ვერ გაჯერდეს.

არქიტექტურა

კომპონენტები და ნაკადი

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

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

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