Miten rakennat reaaliaikaisen katselu-/tykkäyslaskurin viraaleille julkaisuille?

Question

IT Interview Practice · Accepted Answer

Älä koskaan tee `UPDATE posts SET views = views + 1` per tapahtuma kuumalle julkaisulle — tuosta yhdestä rivistä tulee lukkopullonkaula. **Inkrementoi Redisissä, batch-flushaa DB:hen** muutaman sekunnin välein ja lue määrä Redisistä. DB tallentaa pysyvät kokonaissummat, ei live-liikennettä.

## Arkkitehtuuri

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

## Komponentit ja tietovirta

- **Redis INCR** imee kirjoitusmyrskyn. Yksittäinen `INCR views:{post}` on atominen ja käsittelee 100k+ ops/s yhdellä avaimella — suuruusluokkia enemmän kuin Postgres-rivi. Tämä laskuri on totuuden lähde *lukemisille*, joten katsojat näkevät luvun liikkuvan välittömästi.
- **Dedup tykkäyksille/uniikeille katseluille**: raaka laskuri laskee päivitykset kahdesti. Käytä `SADD seen:{post} {userId}` ja `INCR` vain kun lisäys on uusi; halvalle likimääräiselle uniikkien laskennalle massiivisessa mittakaavassa käytä **HyperLogLogia** (`PFADD`/`PFCOUNT`) — muutama kilotavu arvioi miljoonia uniikkeja ~2 % virheellä.
- **Eräluonteinen flusher (batched flusher)** tyhjentää deltan ajoittain DB:hen: `UPDATE posts SET views = views + delta`. Flushaus 5 s välein tai N inkrementin välein muuttaa miljoona kirjoitusta kourallisiksi — DB pitää pysyvän kokonaissumman kylmille julkaisuille ja analytiikkaan.
- **Lukupolku** palvelee Redisistä; cache missin sattuessa se lukee DB-kokonaissumman ja lämmittää Redisin uudelleen. Tykkäykset tarvitsevat per-käyttäjä-tilan (tykkäsinkö *minä* siitä), joten tallenna joukko (set), ei vain lukua.

## Haastattelunäkökulma

Haastattelijat testaavat, hyväksytkö **eventual consistencyn laskureille**. "Hyvä" on "cachea laskuri"; "loistava" on *kirjoitusten* puskurointi — sen tunnistaminen, että pullonkaula on kirjoituskilpailu kuumalla rivillä, ei lukukuorma. He tutkivat kompromissia: onko likimääräinen laskuri hyväksyttävä? Katselulaskureille kyllä — kukaan ei huomaa 1 203 428 vs 1 203 450. Ansa on murehtia tarkoista luvuista ja tarttua transaktioon, tuoden takaisin sen lukon, jota yritit välttää.

## Kompromissit ja virhetilanteet

- **Tarkkuus vs throughput**: tarkat luvut tarvitsevat dedup-joukot (muistiraskaita); likimääräinen HyperLogLog on pieni ja nopea. Valitse per ominaisuus — tykkäykset ovat tarkkoja, katselulaskurit voivat olla likimääräisiä.
- **Kestävyys (durability)**: Redis on muistissa. Jos se kaatuu ennen flushia, menetät flushaamattoman deltan. Ota käyttöön AOF ja pidä flush-ikkunat lyhyinä (sekunteja) rajataksesi menetyksen; DB-kokonaissumma plus pieni aukko on hyväksyttävä katselulaskurille.
- **Kuuma avain (hot key)**: viraali julkaisu keskittää kaiken liikenteen yhteen Redis-avaimeen. Sharddaa se muotoon `views:{post}:{0..9}` ja summaa lukiessa, tai reititä kuumat avaimet omalle nodelleen, jottei yksi julkaisu voi saturoida shardia.

Arkkitehtuuri

Komponentit ja tietovirta

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset