Decisión: ¿qué estrategia de caché?
Una caché mantiene los datos leídos con frecuencia en una capa rápida delante de la base de datos (p. ej. Redis), lo que reduce la latencia y la carga de la BD. Pero no todos los datos son aptos para caché, y una invalidación incorrecta crea riesgo de datos desactualizados/incorrectos. Este árbol comprueba primero si realmente necesita una caché, luego le ayuda a elegir entre cache-aside, read-through, write-through y write-behind según el patrón de lectura/escritura, y trata la prevención de stampedes.
¿Cómo es su carga de trabajo: con lectura intensiva o con escritura intensiva?
Una caché rinde más cuando los mismos datos se leen muchas veces (lectura intensiva) y no cambian a menudo. Establezca primero el patrón general: ¿los datos se leen mucho y cambian poco, se actualizan constantemente, o no está seguro de que merezca la pena añadir una caché?
- Lectura muy intensiva, los datos cambian relativamente poco
- Las escrituras también son intensas; los datos escritos se leen de inmediato/a menudo
- No estoy seguro; ¿realmente necesito una caché?
¿Quién debe encargarse de poblar la caché?
En un escenario de lectura intensiva, la elección clave es quién puebla la caché. ¿Debe su aplicación gestionar la caché de forma explícita y recurrir ella misma a la BD (gran flexibilidad), o debe la capa de caché obtener los datos de la BD subyacente ante un fallo (miss) y devolverlos de forma transparente?
- Que la aplicación la gestione explícitamente; quiero flexibilidad y control
- Que la capa de caché obtenga los datos de la BD ante un fallo (transparente)
En las escrituras, ¿la prioridad es la consistencia o la velocidad de escritura?
Si las escrituras son intensas, debe decidir qué grado de consistencia tendrán los datos escritos entre la caché y la BD. ¿Deben actualizarse juntas la caché y la BD en cada escritura para garantizar la consistencia (escrituras algo más lentas), o deben ir las escrituras primero a la caché y aplicarse a la BD de forma asíncrona en segundo plano (escrituras muy rápidas pero con riesgo de pérdida)?
- La consistencia importa; las lecturas deben estar siempre actualizadas
- La velocidad de escritura es crítica; son aceptables una consistencia ligeramente diferida y un riesgo de pérdida
Recomendación: no añada una caché por ahora
Una caché no es gratuita: introduce un problema de consistencia (datos desactualizados), infraestructura adicional y complejidad de invalidación. Si la consulta ya es rápida o los datos cambian en cada solicitud, una caché no aporta ningún beneficio, solo superficie de fallo.
Recomendación: cache-aside (carga diferida)
Con cache-aside, la aplicación consulta primero la caché; si el dato no está (miss), lo lee de la BD, lo escribe en la caché y lo devuelve. Es el patrón más común y flexible; la caché solo se llena con los datos que realmente se solicitan.
Recomendación: caché read-through
Con read-through, la aplicación solo se comunica con la caché; ante un fallo, la propia capa de caché obtiene los datos de la BD y la puebla (mediante un provider/loader). El código de la aplicación se simplifica y la lógica de poblado reside en un solo lugar.
Recomendación: caché write-through
Con write-through, cada escritura va tanto a la caché como a la BD (de forma síncrona); ambas se actualizan juntas. Así, la caché nunca se queda por detrás de la BD y las lecturas siempre ven datos actuales.
Recomendación: caché write-behind (write-back)
Con write-behind, la escritura va primero a la caché y se devuelve al usuario de inmediato; la escritura en la BD se produce en segundo plano, de forma asíncrona (por lotes/diferida). La velocidad de escritura es la máxima, pero conlleva riesgos de durabilidad y consistencia.