¿Qué es una caché distribuida y cómo gestionas sus fallos?

Question

IT Interview Practice · Accepted Answer

**Una caché distribuida permite que varias instancias reutilicen datos por red.** Evita trabajo caro repetido con reglas claras de frescura y fallos.

Tres instancias leen el mismo catálogo. Con caché dentro de cada proceso mantienen copias propias. Una caché compartida permite que una cargue un valor reutilizado por las demás. El servicio puede tener varios nodos.

## 1. Decide qué puede cachearse

Empieza por coste de producción y antigüedad tolerable. Una descripción admite demora; comprobar existencias al comprar puede exigir fuente autoritativa.

La clave debe identificar todo el resultado, incluido tenant, idioma y entradas pertinentes. Si no, una caché rápida puede entregar datos de otro cliente. Mantén la base como autoridad de registros duraderos: los valores cacheados desaparecen.

## 2. Entiende lectura antes de actualización

En cache-aside, la aplicación consulta caché, lee base ante un miss y guarda el resultado con caducidad TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Reduce lecturas repetidas del mismo dato, pero añade llamadas de red y dependencia. Lo evitado debe superar esos costes. Véase [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Define visibilidad de actualizaciones

Para el catálogo, una base práctica es confirmar la escritura e invalidar después el producto cacheado. El siguiente lector recarga. Persiste una carrera: un lector obtiene el valor anterior antes del commit y lo inserta después de invalidar.

TTL limita cuánto vive esa nueva copia, no garantiza leer inmediatamente la última escritura. Si permisos, precios o saldos antiguos violan reglas, verifica la fuente autoritativa o diseña actualizaciones versionadas con garantías explícitas. Elige consistencia por operación, no suponiendo que Redis la resuelve.

## 4. Evita que un miss provoque una caída

Al caducar una entrada popular, muchos lectores pueden ir simultáneamente a la base: cache stampede. Un fallo de caché puede hacerlo con muchas entradas.

- Agrupa cargas concurrentes por clave y aclara si coordina un proceso o todas las instancias.
- Varía caducidades para repartir recargas. No soluciona todos los problemas de claves calientes.
- Sirve datos anteriores durante actualización solo cuando el negocio lo admita.
- Usa timeouts cortos y limita el fallback a la base. Rechazar parte puede ser mejor que saturarla y fallar todo.

Prueba estas rutas. Un hit rate alto normalmente dice poco sobre el comportamiento sin caché.

## 5. Escala según el cuello real

Sharding reparte claves; replicación mantiene copias para disponibilidad o lectura. Resuelven problemas diferentes. Redis Cluster usa hash slots, por lo que añadir nodos no divide automáticamente una clave caliente. Véase [especificación Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Vigila aciertos, latencia, timeouts, memoria, expulsiones y carga de base. Una expulsión por memoria puede ocurrir antes del TTL. No trates la caché como almacenamiento duradero garantizado de negocio o tareas pendientes.

Empezaría con cache-aside, claves explícitas, política de frescura y fallback protegido. Añadiría nodos solo ante un problema medido que la distribución resuelva. **Un buen diseño explica valores presentes, ausentes e incorrectos.**

1. Decide qué puede cachearse

2. Entiende lectura antes de actualización

3. Define visibilidad de actualizaciones

4. Evita que un miss provoque una caída

5. Escala según el cuello real

Preguntas relacionadas