¿Cómo manejas una hot key o hot row bajo alta contención?

Question

IT Interview Practice · Accepted Answer

**Deja de canalizar todo el tráfico hacia una única clave: divide la clave caliente en N sub-claves (sharded counters), coalesce las lecturas duplicadas, sirve desde una cache local, y agrupa las escrituras para que una fila no se actualice en cada request.** Un único contador de "likes" en un post viral puede recibir 50k escrituras/seg — una fila se convierte en un cuello de botella de serialización cuando cada transacción pelea por el mismo lock.

## Fan-out en lugar de una fila con contención

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## Técnicas

- **Sharded counter / key splitting.** Escribe en `likes:123:{0..N}` elegido al azar; el conteo verdadero es el `SUM`. Esto convierte una fila caliente en N filas más frías, reduciendo la contención de locks en ~N. Las lecturas pagan un pequeño coste de fan-in.
- **Request coalescing (single-flight).** Si 10k requests quieren la misma clave a la vez, deja que **una** golpee la DB y haz que el resto espere ese resultado en vuelo. Evita que un stampede de cache-miss aplaste la fila.
- **Cache local (in-process).** Cachea el valor caliente en cada nodo de la app durante un TTL corto (p. ej. 1s). Para una clave read-hot, eso colapsa miles de lecturas/seg en un solo refresh — aceptando ligera obsolescencia.
- **Write batching.** Bufferiza los incrementos en memoria y haz flush de `+= 500` una vez por segundo en lugar de 500 updates individuales. Un update de fila por segundo en vez de 500 elimina la contención por completo.

## Perspectiva de la entrevista

El entrevistador quiere verte diagnosticar **dónde está la contención** y ajustar el arreglo a read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counters + batching. Una buena respuesta lista técnicas; una excelente nota que el sharding intercambia **coste de lectura por escalabilidad de escritura**, y que el batching/caching intercambian **frescura por throughput**.

**Compensaciones y trampas:** los sharded counters hacen más difíciles los totales exactos en tiempo real (sumas los shards) y complican la lógica de "decrementar por debajo de cero". Las caches locales derivan entre nodos — bien para un conteo de likes, mal para un saldo bancario. El batching arriesga perder escrituras bufferizadas si un nodo se cae antes del flush, así que conviene a contadores idempotentes/aproximados, no a dinero. Elige la mitigación que las necesidades de consistencia de los datos permitan.

Fan-out en lugar de una fila con contención

Técnicas

Perspectiva de la entrevista

Preguntas relacionadas