¿Cómo construyes un contador de vistas/likes en tiempo real para posts virales?

Question

IT Interview Practice · Accepted Answer

Nunca hagas `UPDATE posts SET views = views + 1` por evento en un post caliente — esa única fila se convierte en un cuello de botella de locks. **Incrementa en Redis, haz flush por lotes a la DB** cada pocos segundos, y lee el conteo desde Redis. La DB almacena los totales duraderos, no el tráfico en vivo.

## Arquitectura

```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 y flujo

- **Redis INCR** absorbe la tormenta de escrituras. Un único `INCR views:{post}` es atómico y maneja 100k+ ops/s sobre una clave — órdenes de magnitud por encima de una fila de Postgres. Este contador es la fuente de verdad para las *lecturas*, así que los espectadores ven el número moverse al instante.
- **Dedup para likes/vistas únicas**: un contador crudo cuenta dobles los refrescos. Usa `SADD seen:{post} {userId}` y solo haz `INCR` cuando el add es nuevo; para únicos aproximados baratos a escala masiva usa **HyperLogLog** (`PFADD`/`PFCOUNT`) — unos pocos KB estiman millones de únicos con ~2% de error.
- **El flusher por lotes** drena periódicamente el delta a la DB: `UPDATE posts SET views = views + delta`. Hacer flush cada 5s o cada N incrementos convierte un millón de escrituras en un puñado — la DB guarda el total duradero para posts fríos y analítica.
- **La ruta de lectura** sirve desde Redis; ante un cache miss lee el total de la DB y re-calienta Redis. Los likes necesitan estado por usuario (¿le di *yo* like?), así que almacena el set, no solo un número.

## Perspectiva de la entrevista

Los entrevistadores prueban si aceptas la **eventual consistency para los conteos**. "Bueno" es "cachea el conteo"; "excelente" es bufferizar las *escrituras* — reconocer que el cuello de botella es la contención de escritura sobre una fila caliente, no la carga de lectura. Sondean la compensación: ¿es aceptable un conteo aproximado? Para conteos de vistas, sí — nadie nota 1.203.428 vs 1.203.450. La trampa es preocuparse por conteos exactos y recurrir a una transacción, reintroduciendo el lock que estabas evitando.

## Compensaciones y fallos

- **Precisión vs throughput**: los conteos exactos necesitan sets de dedup (pesados en memoria); el HyperLogLog aproximado es diminuto y rápido. Elige por característica — los likes son exactos, los conteos de vistas pueden ser aproximados.
- **Durabilidad**: Redis es en memoria. Si muere antes de un flush, pierdes el delta no volcado. Habilita AOF y mantén las ventanas de flush cortas (segundos) para acotar la pérdida; el total de la DB más un pequeño hueco es aceptable para un contador de vistas.
- **Clave caliente (hot key)**: un post viral concentra todo el tráfico en una única clave de Redis. Fragméntala en `views:{post}:{0..9}` y suma al leer, o enruta las claves calientes a un nodo dedicado para que un post no pueda saturar el shard.

Arquitectura

Componentes y flujo

Perspectiva de la entrevista

Compensaciones y fallos

Preguntas relacionadas