La caché puede reducir tiempos de respuesta y carga sobre bases de datos o servicios externos, pero no corrige por sí sola una consulta ineficiente ni una arquitectura con límites mal definidos. Una estrategia de caché en PHP debe especificar qué se guarda, quién puede recibirlo, cuánto tiempo es válido y qué ocurre si el mecanismo de almacenamiento falla.
El criterio de éxito no es únicamente aumentar la tasa de aciertos. La aplicación debe mantener sus reglas de negocio cuando la caché está vacía, desactualizada o no disponible. Para conseguirlo, conviene empezar por medir el problema y tratar la caché como una optimización con comportamiento verificable, no como fuente primaria de verdad.
Medir antes de decidir qué almacenar
Identifica primero las rutas lentas y sus causas. Registra tiempos de respuesta por endpoint, latencia de consultas, llamadas a servicios externos, uso de CPU y volumen de peticiones. Separa promedios de percentiles altos: un promedio aceptable puede ocultar respuestas muy lentas para una parte de los usuarios.
Busca operaciones repetidas cuyo resultado cambie con menos frecuencia que la demanda: catálogos, configuración pública, contenido publicado o agregados costosos. Comprueba también si la lentitud procede de consultas sin índices, exceso de solicitudes, serialización o trabajo repetido dentro de una misma petición. Mejorar la consulta puede ser preferible a almacenar un resultado difícil de invalidar.
Define una referencia antes del cambio: rendimiento, carga y calidad de datos observada. Después compara el mismo tráfico o una prueba reproducible. Si no se puede atribuir la mejora a la caché, será difícil valorar su coste operativo y sus efectos secundarios.
Elegir entre caché de aplicación, HTTP y consultas
La caché de aplicación almacena valores que el código PHP puede reutilizar, como resultados de una consulta o una respuesta calculada. Puede residir en memoria compartida, en un servicio dedicado o en otro backend compatible con la aplicación. Es adecuada cuando varias peticiones necesitan el mismo resultado y se puede definir con precisión su alcance y vigencia.
La caché HTTP usa directivas como Cache-Control, ETag y validadores para que navegadores o intermediarios reutilicen respuestas. Resulta útil para recursos públicos o respuestas cuya política de privacidad permite almacenamiento. Las respuestas personalizadas requieren especial cuidado: una política pública puede exponer datos, mientras que una política privada o no almacenable puede reducir esa posibilidad, según el flujo y los intermediarios involucrados.
La caché de consultas puede ser una función de la base de datos, del controlador o de una capa que conserva resultados. No debe confundirse con optimizar el acceso a datos: la caché no sustituye índices, planes de consulta adecuados ni transacciones. Antes de activarla, entiende quién invalida las entradas y si las lecturas deben reflejar inmediatamente las escrituras.
Elige la capa más cercana al problema, no todas a la vez. Apilar cachés sin un modelo explícito puede hacer que distintas capas mantengan versiones diferentes del mismo dato y complicar el diagnóstico.
Diseñar claves, alcance y caducidad
Una clave debe identificar todos los factores que cambian el resultado. Por ejemplo, una respuesta de catálogo podría depender del idioma, la moneda, la región y la versión de los datos. Incluye esos elementos de forma estable y legible para facilitar el diagnóstico; evita guardar información sensible dentro de la clave.
Si el resultado depende del usuario, del rol, de permisos o de la organización, el aislamiento debe reflejarlo. Una clave que solo incluya el nombre de la ruta puede hacer que una respuesta personalizada llegue a otra persona. Verifica también cómo se comparten las entradas entre procesos y servidores. Si no puedes enumerar de manera fiable todas las dimensiones que afectan al resultado, no almacenes esa respuesta compartida.
La caducidad debe responder a una regla de negocio, no a un valor arbitrario. Una configuración que cambia pocas veces puede tolerar una ventana más larga que el saldo de una cuenta o el estado de una reserva. Define la duración máxima aceptable de la obsolescencia y considera variaciones aleatorias de expiración cuando muchas entradas similares puedan vencer al mismo tiempo.
La expiración por tiempo no reemplaza la invalidación ante cambios importantes. Es una última cota para que una entrada no permanezca indefinidamente, no una garantía de actualización inmediata.
Actualizar e invalidar cuando cambia el origen
Elige un mecanismo acorde con la necesidad de coherencia. La invalidación explícita puede ejecutarse después de una escritura; es directa, pero puede fallar si el proceso se interrumpe entre guardar el dato y borrar la caché. Una alternativa es usar versiones en las claves: cuando cambia el origen, se incrementa la versión y las entradas anteriores dejan de consultarse. Esto exige gestionar correctamente esa versión.
En sistemas con eventos, un cambio confirmado puede publicar una notificación para invalidar o recalcular datos derivados. Si la entrega de eventos no es fiable, contempla reintentos, idempotencia y una vía de reconciliación. No asumas que actualizar la base de datos y el servicio de caché constituye una operación atómica.
Para datos que admiten obsolescencia breve, puede ser apropiado servir una entrada vencida mientras se actualiza en segundo plano. Esta técnica no sirve para toda información: fija qué datos son elegibles, cuánto puede prolongarse la obsolescencia y qué sucede si la actualización falla. La decisión debe proceder del impacto de mostrar un valor anterior.
Definir un comportamiento seguro ante fallos
Prueba tres estados distintos: ausencia de entrada, entrada vencida y backend no disponible. En cada uno, decide si la aplicación recalcula desde el origen, responde con un error controlado o, cuando sea seguro, entrega un valor anterior. Una caché vacía debe ser un estado normal de arranque y no provocar resultados incorrectos.
Protege el origen ante una caída del backend. Si cada petición lanza una consulta costosa al expirar la misma clave, se puede producir una avalancha de carga. Entre las medidas posibles están limitar la concurrencia de recalculado, reutilizar temporalmente valores seguros o aplicar límites y tiempos de espera. La solución depende de si el dato puede servirse obsoleto y de la capacidad del origen.
Registra errores, latencias y fallos de lectura o escritura sin incluir valores privados. La caché suele ser una dependencia de rendimiento, no una autoridad de datos: si su indisponibilidad debe detener una operación crítica, esa decisión tiene que estar justificada explícitamente.
Validar coherencia y rendimiento con pruebas reproducibles
Compara escenarios con caché desactivada, fría y caliente. Incluye la primera petición tras una escritura, cambios de idioma o permisos, expiración simultánea y fallo del backend. Comprueba tanto el contenido como el aislamiento: dos usuarios con distintos permisos no deben recibir respuestas cruzadas.
Usa pruebas automatizadas para reglas importantes de claves e invalidación y pruebas de integración para verificar el comportamiento con el backend real o una alternativa representativa. En carga, observa aciertos y fallos, latencia de la caché, operaciones de recalculado, carga del origen y errores. Una tasa de aciertos alta no demuestra que las respuestas sean correctas.
Al desplegar un cambio, compara métricas y errores con una referencia. Mantén una forma de desactivar la optimización o volver a un comportamiento seguro si aparecen datos obsoletos, crecimiento de memoria o presión inesperada sobre la base de datos.
Lista de comprobación para operar la caché
- Problema medido: se conocen las rutas y operaciones que justifican la caché.
- Dato y fuente definidos: la caché no se trata como registro primario.
- Clave completa: incluye las dimensiones funcionales y de permisos relevantes.
- Caducidad justificada: coincide con la tolerancia de negocio a la obsolescencia.
- Invalidación prevista: se especifica qué evento actualiza o sustituye cada entrada.
- Fallos cubiertos: caché vacía, vencida e indisponible tienen comportamiento definido.
- Medición operativa: se vigilan latencia, errores, aciertos y carga sobre el origen.
- Pruebas de aislamiento: se validan usuarios, roles, idiomas y otros contextos pertinentes.
Una estrategia de caché sólida reduce trabajo repetido sin cambiar inadvertidamente el significado de los datos. Si cada entrada tiene un alcance claro, una política de vigencia y un plan de fallo comprobable, el equipo puede evaluar sus beneficios y retirar o ajustar la optimización cuando deje de ser adecuada.
