¿Cómo usas caching para reducir la carga de la DB a millones de req/min?

Question

IT Interview Practice · Accepted Answer

Pon una capa **cache-aside** (Redis/Memcached) frente a la DB para que las lecturas golpeen memoria, da a las entradas un **TTL** e **invalida al escribir**, añade **protección contra stampede** para que una clave fría no desate una thundering herd sobre la DB, y reparte las **claves calientes** entre réplicas para que una clave popular no derrita un único nodo.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

En **cache-aside** la app consulta la cache; ante un miss lee la DB y puebla la cache ella misma. En **read-through** la librería de cache lo hace por ti. En ambos casos el objetivo es el mismo: convertir una query de DB de 5ms en un lookup de memoria de 0,2ms, así que una cache con un 95% de hit rate reduce el tráfico de lectura de la DB **20×**. A millones de req/min la DB simplemente no puede servir cada lectura — la cache es lo que hace que los números cuadren.

## TTL + invalidación

Dos maneras de mantener la cache fresca, y normalmente necesitas ambas. El **TTL** acota la obsolescencia — una entrada expira tras N segundos así que los datos incorrectos se auto-sanan. La **invalidación explícita** borra/actualiza la clave al escribir para una correctitud que no puede esperar al TTL. El bug clásico es cachear sin invalidación y servir datos obsoletos durante minutos; el más sutil es invalidar *y* setear en la misma escritura, lo que produce una race.

## Protección contra stampede y claves calientes

- **Stampede (thundering herd):** cuando una clave caliente expira, miles de misses concurrentes golpean la DB a la vez y pueden tumbarla. Arréglalo con un **lock por clave/single-flight** (solo una request recalcula, las demás esperan) o **refresh temprano/probabilístico** antes de expirar.
- **Claves calientes:** una clave (el perfil de una celebridad) puede saturar la CPU/red de un único nodo de Redis. Repártela — replica la clave entre nodos, o añade una pequeña cache local in-process frente a Redis para los ítems más calientes.

## Perspectiva de la entrevista

El entrevistador quiere verte pensar más allá de "añade Redis". Bueno: cache-aside con TTL. Excelente: nombras la **protección contra stampede, la estrategia de invalidación, el manejo de claves calientes, y qué pasa ante una caída de la cache**. La trampa es asumir que la cache siempre está arriba — si Redis muere y cada miss cae hacia la DB, tienes un **cache-avalanche** que tumba también la DB.

## Compensaciones y modos de fallo

- **Obsolescencia vs carga:** TTL corto = fresco pero más misses; TTL largo = menos misses pero más obsoleto. Ajusta por dato.
- **Cache avalanche:** muchas claves expirando juntas (mismo TTL) causa un pico de carga — pon **jitter** a los TTLs.
- **Consistencia:** la cache y la DB pueden divergir; para lecturas críticas de dinero, lee la DB o usa write-through.
- **Eviction de memoria:** bajo presión Redis evicta por política (LRU/LFU); una política equivocada tira en silencio tu conjunto caliente.

Cache-aside vs read-through

TTL + invalidación

Protección contra stampede y claves calientes

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas