Jak zbudować licznik wyświetleń/polubień w czasie rzeczywistym dla wiralowych postów?

Question

IT Interview Practice · Accepted Answer

Nigdy nie wykonuj `UPDATE posts SET views = views + 1` na zdarzenie dla gorącego postu — ten jeden wiersz staje się wąskim gardłem blokad. **Inkrementuj w Redis, wsadowo zrzucaj (batch-flush) do DB** co kilka sekund i odczytuj licznik z Redis. DB przechowuje trwałe sumy, a nie ruch na żywo.

## Architektura

```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)
```

## Komponenty i przepływ

- **Redis INCR** absorbuje burzę zapisów. Pojedyncze `INCR views:{post}` jest atomowe i obsługuje ponad 100 tys. operacji/s na jednym kluczu — o rzędy wielkości więcej niż wiersz Postgres. Ten licznik jest źródłem prawdy dla *odczytów*, więc oglądający widzą, jak liczba rośnie natychmiast.
- **Dedupikacja polubień/unikatowych wyświetleń**: surowy licznik podwójnie liczy odświeżenia. Użyj `SADD seen:{post} {userId}` i wykonuj `INCR` tylko wtedy, gdy dodanie jest nowe; do tanich przybliżonych unikatów w ogromnej skali użyj **HyperLogLog** (`PFADD`/`PFCOUNT`) — kilka KB szacuje miliony unikatów z błędem ~2%.
- **Wsadowy flusher** okresowo zrzuca deltę do DB: `UPDATE posts SET views = views + delta`. Flushowanie co 5 s lub co N inkrementacji zamienia milion zapisów w garstkę — DB przechowuje trwałą sumę dla zimnych postów i analityki.
- **Ścieżka odczytu** obsługuje z Redis; przy cache miss odczytuje sumę z DB i ponownie rozgrzewa Redis. Polubienia wymagają stanu per użytkownik (czy *ja* to polubiłem), więc przechowuj zbiór, a nie tylko liczbę.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówcy testują, czy akceptujesz **spójność ostateczną (eventual consistency) dla liczników**. „Dobrze" to „zbuforuj licznik"; „świetnie" to buforowanie *zapisów* — rozpoznanie, że wąskim gardłem jest rywalizacja o zapis na gorącym wierszu, a nie obciążenie odczytami. Sondują kompromis: czy przybliżony licznik jest akceptowalny? Dla liczników wyświetleń tak — nikt nie zauważy 1 203 428 vs 1 203 450. Pułapką jest zamartwianie się o dokładne liczniki i sięganie po transakcję, co przywraca blokadę, której unikałeś.

## Kompromisy i awarie

- **Dokładność vs throughput**: dokładne liczniki wymagają zbiorów dedupikacji (pamięciożerne); przybliżony HyperLogLog jest maleńki i szybki. Wybieraj per funkcja — polubienia są dokładne, liczniki wyświetleń mogą być przybliżone.
- **Trwałość**: Redis jest in-memory. Jeśli padnie przed flushem, tracisz niezrzuconą deltę. Włącz AOF i trzymaj okna flushu krótkie (sekundy), aby ograniczyć stratę; suma z DB plus mała luka jest akceptowalna dla licznika wyświetleń.
- **Gorący klucz**: wiralowy post koncentruje cały ruch na jednym kluczu Redis. Rozdziel go (shard) na `views:{post}:{0..9}` i sumuj przy odczycie, albo kieruj gorące klucze do dedykowanego węzła, aby jeden post nie wysycił sharda.

Architektura

Komponenty i przepływ

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i awarie

Powiązane pytania