Como você constrói um contador de views/likes em tempo real para posts virais?

Question

IT Interview Practice · Accepted Answer

Nunca faça `UPDATE posts SET views = views + 1` por evento em um post quente — essa única linha vira um gargalo de lock. **Incremente no Redis, faça flush em lote para o DB** a cada poucos segundos e leia a contagem do Redis. O DB armazena totais duráveis, não o tráfego ao vivo.

## Arquitetura

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

## Componentes e fluxo

- **Redis INCR** absorve a tempestade de escritas. Um único `INCR views:{post}` é atômico e lida com 100k+ ops/s em uma chave — ordens de magnitude além de uma linha do Postgres. Esse contador é a fonte de verdade para *leituras*, então os visualizadores veem o número se mover instantaneamente.
- **Dedup para likes/views únicas**: um contador cru conta refreshes em duplicidade. Use `SADD seen:{post} {userId}` e só faça `INCR` quando a adição for nova; para uniques aproximados baratos em escala massiva use **HyperLogLog** (`PFADD`/`PFCOUNT`) — alguns KB estimam milhões de uniques com ~2% de erro.
- **Flusher em lote** periodicamente drena o delta para o DB: `UPDATE posts SET views = views + delta`. Fazer flush a cada 5s ou a cada N incrementos transforma um milhão de escritas em um punhado — o DB guarda o total durável para posts frios e analytics.
- **Caminho de leitura** serve do Redis; num cache miss ele lê o total do DB e reaquece o Redis. Likes precisam de estado por usuário (foi *eu* que dei like), então armazene o conjunto (set), não apenas um número.

## Perspectiva de entrevista

Entrevistadores testam se você aceita **consistência eventual para contagens**. "Bom" é "cachear a contagem"; "excelente" é bufferizar *escritas* — reconhecer que o gargalo é contenção de escrita numa linha quente, não carga de leitura. Eles sondam o trade-off: uma contagem aproximada é aceitável? Para contagens de view, sim — ninguém percebe 1.203.428 vs 1.203.450. A armadilha é se preocupar com contagens exatas e recorrer a uma transação, reintroduzindo o lock que você estava evitando.

## Trade-offs e falhas

- **Precisão vs throughput**: contagens exatas precisam de sets de dedup (pesados em memória); o HyperLogLog aproximado é minúsculo e rápido. Escolha por funcionalidade — likes são exatos, contagens de view podem ser aproximadas.
- **Durabilidade**: o Redis é em memória. Se ele morrer antes de um flush, você perde o delta não persistido. Habilite AOF e mantenha janelas de flush curtas (segundos) para limitar a perda; o total do DB mais uma pequena diferença é aceitável para um contador de views.
- **Chave quente**: um post viral concentra todo o tráfego em uma chave do Redis. Faça sharding em `views:{post}:{0..9}` e some na leitura, ou roteie chaves quentes para um nó dedicado para que um post não sature o shard.

Arquitetura

Componentes e fluxo

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas