¿Cómo añadirías una capa de caché delante de un endpoint con muchas lecturas sin servir datos muy desactualizados?

Elige el TTL más corto que aun así mueva la aguja, y luego invalida al escribir borrando o sobrescribiendo la clave en el mismo camino que muta la fila. Indexa por cada entrada que cambie el resultado, incluidos el inquilino y una versión de esquema. Añade un bloqueo de vuelo único para que un fallo de caché no provoque una estampida contra la base de datos. Acepta desfase explícito donde sea inofensivo, y sigue la tasa de acierto para saber que funciona.

Antes de añadir nada, compruebo si la consulta simplemente se puede hacer rápida, porque una caché delante de una consulta mala esconde el problema hasta que la caché falla en el peor momento. Suponiendo que de verdad tiene muchas lecturas, voy con cache aside en Redis. La clave incluye el id del inquilino, los parámetros reales de la consulta y un prefijo de versión que puedo subir en cada despliegue para que una forma de respuesta cambiada nunca se sirva desde entradas viejas. El TTL es la red de seguridad y no el mecanismo: invalido de forma explícita al escribir, en el mismo camino de código que actualiza la fila, así que la ventana de desfase es de milisegundos en el caso normal. El modo de fallo que planifico es la estampida, donde una clave caliente expira y doscientas peticiones fallan a la vez y golpean la base de datos, así que uso un bloqueo de vuelo único y dejo que los perdedores esperen al ganador. Después exporto la tasa de acierto como métrica, porque una caché que pasó del 95 por ciento al 10 tras un refactor no se nota hasta que la base de datos se cae.