Viral gönderiler için gerçek zamanlı bir görüntülenme/beğeni sayacını nasıl inşa edersiniz?

Question

IT Interview Practice · Accepted Answer

Hot bir gönderi üzerinde her olay için asla `UPDATE posts SET views = views + 1` yapmayın — o tek satır bir lock bottleneck'i haline gelir. **Redis'te artırın, her birkaç saniyede bir DB'ye batch-flush yapın** ve sayacı Redis'ten okuyun. DB, canlı trafiği değil, dayanıklı toplamları saklar.

## Mimari

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

## Bileşenler ve akış

- **Redis INCR** yazma fırtınasını emer. Tek bir `INCR views:{post}` atomiktir ve tek bir key üzerinde 100k+ ops/s işler — bir Postgres satırının kat kat ötesinde. Bu sayaç, *okumalar* için doğruluk kaynağıdır, böylece izleyiciler sayının anında hareket ettiğini görür.
- **Beğeniler/benzersiz görüntülenmeler için dedup**: ham bir sayaç yenilemeleri çift sayar. `SADD seen:{post} {userId}` kullanın ve yalnızca ekleme yeniyse `INCR` yapın; devasa ölçekte ucuz yaklaşık benzersizler için **HyperLogLog** (`PFADD`/`PFCOUNT`) kullanın — birkaç KB, milyonlarca benzersizi ~%2 hata içinde tahmin eder.
- **Batched flusher**, delta'yı periyodik olarak DB'ye boşaltır: `UPDATE posts SET views = views + delta`. Her 5s veya her N artışta bir flush yapmak, milyon yazmayı bir avuç yazmaya dönüştürür — DB, soğuk gönderiler ve analitik için dayanıklı toplamı tutar.
- **Read path**, Redis'ten sunar; bir cache miss'te DB toplamını okur ve Redis'i yeniden ısıtır. Beğeniler kullanıcı başına state gerektirir (*ben* beğendim mi), bu yüzden sadece bir sayı değil, seti saklayın.

## Mülakat perspektifi

Mülakatı yapanlar, **sayımlar için eventual consistency**'yi kabul edip etmediğinizi test eder. "İyi", "sayımı cache'le"dir; "harika", *yazmaları* buffer'lamaktır — bottleneck'in read yükü değil, hot bir satır üzerindeki write contention olduğunu fark etmektir. Ödünleşimi yoklarlar: yaklaşık bir sayım kabul edilebilir mi? Görüntülenme sayıları için, evet — kimse 1.203.428 ile 1.203.450 arasındaki farkı fark etmez. Tuzak, tam sayımlar için endişelenip bir transaction'a başvurmak ve kaçındığınız kilidi yeniden ortaya çıkarmaktır.

## Ödünleşimler ve hata

- **Doğruluk vs throughput**: tam sayımlar dedup setleri gerektirir (bellek yoğun); yaklaşık HyperLogLog küçük ve hızlıdır. Özellik başına seçin — beğeniler tamdır, görüntülenme sayıları yaklaşık olabilir.
- **Durability**: Redis in-memory'dir. Bir flush'tan önce çökerse, flush edilmemiş delta'yı kaybedersiniz. AOF'u etkinleştirin ve flush pencerelerini kısa (saniyeler) tutun, böylece kaybı sınırlayın; DB toplamı artı küçük bir boşluk bir görüntülenme sayacı için kabul edilebilir.
- **Hot key**: viral bir gönderi tüm trafiği tek bir Redis key üzerinde yoğunlaştırır. Onu `views:{post}:{0..9}` şeklinde shard'layın ve okumada toplayın veya hot key'leri özel bir node'a yönlendirin, böylece bir gönderi shard'ı doyuramaz.

Mimari

Bileşenler ve akış

Mülakat perspektifi

Ödünleşimler ve hata

İlgili sorular