--- title: "Cómo cachear API de alto tráfico con Redis y Elasticsearch" description: "Mida primero el P95 y aplique después cache-aside, TTL adecuados, invalidación y protección contra estampidas con Redis y Elasticsearch. Y qué no cachear nunca." canonical: https://sdk.enterprises/es/insights/caching-high-traffic-apis language: es --- # Cómo cachear API de alto tráfico con Redis y Elasticsearch Actualizado: 2026-09-25 > Para cachear una API con mucho tráfico, mida primero y coloque después una capa cache-aside en Redis delante de los endpoints más lentos y más consultados, con TTL explícitos, invalidación en cada escritura y protección contra las estampidas de caché. Use Elasticsearch para las búsquedas y los listados filtrados que la base de datos principal gestiona mal, y no cachee nunca datos propios de cada usuario o que exijan consistencia estricta sin un diseño pensado para ello. ## Mida la latencia P95 antes de añadir ninguna caché Las medias ocultan las peticiones de las que se quejan los usuarios. Mida la latencia P95 y P99 de cada endpoint, junto con el volumen de peticiones, para ver qué rutas son a la vez lentas y muy utilizadas. Después, averigüe en qué se va el tiempo. Una traza o un simple desglose de tiempos por petición suele mostrar si el coste viene de una consulta lenta, de consultas repetidas, de una llamada a una API externa o de la serialización. Cachear una respuesta cuyo problema real es un índice que falta solo oculta ese problema hasta el siguiente fallo de caché. - Registre P50, P95 y P99 por endpoint, no una sola cifra global - Ordene los endpoints por volumen de peticiones multiplicado por latencia para ver dónde rinde más la caché - Compruebe la proporción entre lecturas y escrituras: los datos que se leen mucho más a menudo de lo que cambian son los mejores candidatos - Corrija los índices que faltan y las consultas N+1 antes de poner una caché a su alrededor ## Use cache-aside como patrón por defecto Con cache-aside, la aplicación consulta primero Redis. Si hay acierto, devuelve el valor en caché. Si hay fallo, lee de la base de datos, escribe el resultado en Redis con un TTL y lo devuelve. El patrón mantiene la base de datos como fuente de verdad y falla de forma segura. Si Redis va lento o no está disponible, la aplicación recurre a la base de datos, con un tiempo de espera corto y un circuit breaker para que una caché en apuros no ralentice todas las peticiones. Diseñe las claves con criterio. Incluya el tipo de recurso, el identificador, la versión de la API y cada parámetro que cambie la respuesta, como el idioma o la página. Un esquema de claves predecible es lo que permite más adelante una invalidación selectiva. ## Fije los TTL según la antigüedad admisible de los datos e invalide al cambiar Un TTL es una decisión de negocio escrita como un número. Pregúntese qué antigüedad pueden tener los datos antes de perjudicar a un usuario o a un sistema posterior, y fije el TTL a partir de esa respuesta. El marcador de un partido en directo y un artículo archivado toleran desfases muy distintos. Confiar solo en la caducidad significa servir datos obsoletos hasta que venza el TTL. Para los datos que modifica su propia aplicación, borre o sobrescriba la clave después de confirmar la escritura, idealmente desde un evento emitido tras la transacción, para que la caché nunca contenga datos que la base de datos ha revertido. Añada una pequeña variación aleatoria a los TTL para que las claves escritas a la vez no caduquen todas en el mismo momento. - TTL corto, de unos segundos, para datos que cambian rápido cuando un ligero desfase es aceptable - TTL más largo con invalidación en cada escritura para los datos que usted controla y que cambian poco - Claves versionadas, en las que subir un número de versión invalida de una vez todo un grupo de claves ## Proteja la base de datos de las estampidas de caché Una estampida se produce cuando caduca una clave muy consultada y muchas peticiones simultáneas fallan a la vez, todas enviando la misma consulta costosa a la base de datos. En una API con mucho tráfico, esto puede sobrecargar la base de datos justo en el momento del pico de tráfico. Combine dos o más de estas defensas en sus claves más solicitadas. - Agrupación de peticiones: una sola petición reconstruye la clave bajo un bloqueo corto en Redis, creado con NX y una caducidad, mientras las demás esperan un momento o sirven el valor anterior - Stale-while-revalidate: guarde una caducidad blanda dentro del valor, siga sirviendo la copia obsoleta una vez pasada y actualícela en segundo plano - Actualización anticipada probabilística: reconstruya de vez en cuando una clave muy solicitada antes de que caduque, con una probabilidad que aumenta a medida que se acerca la caducidad - Precalentamiento: cargue las claves más solicitadas antes de un pico de tráfico previsto, como un gran evento en directo ## Use Elasticsearch para búsquedas y listados, no como caché general Redis es ideal para consultas clave-valor: un objeto concreto, un fragmento calculado, un contador de limitación de peticiones. Elasticsearch sirve para otra cosa: búsqueda de texto completo, filtros por facetas y listados ordenados que resultan costosos de calcular en una base de datos relacional. Trate el índice de Elasticsearch como un modelo de lectura alimentado desde la base de datos principal, mediante eventos de cambio o una sincronización programada, y asuma que su consistencia es eventual. Mantenga la base de datos como referencia para las escrituras y para todo lo que deba ser exacto. En la plataforma de medios deportivos de NorthStar Network, que da servicio a 50M+ usuarios al mes, nuestros ingenieros rediseñaron la arquitectura de API críticas y la caché en Redis y Elasticsearch, lo que redujo los tiempos de respuesta P95. ## Sepa qué no debe cachear El error de caché más costoso es servir los datos de un usuario a otro. Revise en cada endpoint cacheado que la identidad forme parte de la clave, y pruébelo con dos cuentas distintas antes de publicarlo. - Respuestas que dependen de la identidad o de los permisos de quien llama, salvo que la clave incluya el usuario o el rol - Datos que deben ser estrictamente consistentes, como saldos, el stock en el momento del pago o cualquier dato usado en decisiones de autorización - Endpoints de escritura, tokens de un solo uso y todo lo que tenga efectos secundarios - Endpoints con poco tráfico, donde una caché añade complejidad y un nuevo modo de fallo a cambio de poco - Respuestas muy pesadas que expulsan muchas claves más pequeñas y más solicitadas ## Haga observable la caché, o no podrá fiarse de ella Siga en el mismo panel la tasa de aciertos por prefijo de clave, el uso de memoria y las expulsiones de Redis, la latencia de los comandos de Redis y la carga de la base de datos, junto al P95 de la API. Cuando el P95 se mueva, debería poder saber en minutos si la causa es la caché, la base de datos o un servicio del que depende. Configure alertas ante una caída brusca de la tasa de aciertos, que a menudo indica que un despliegue ha cambiado el formato de una clave, y ante un aumento de las expulsiones, que indica que la caché es demasiado pequeña para su conjunto de trabajo. Abordamos el trabajo de rendimiento de API como un bloque definido: medición, rediseño de la capa de caché y entrega de paneles y manuales de operaciones al equipo que la gestiona. ## Puntos clave - Mida el P95 por endpoint y corrija los problemas de consultas antes de añadir una caché. - Cache-aside en Redis es la opción por defecto más segura, porque la base de datos sigue siendo la fuente de verdad. - Fije los TTL según la antigüedad admisible de los datos e invalide en cada escritura los datos que usted controla. - Proteja las claves más solicitadas contra las estampidas con bloqueos, stale-while-revalidate o precalentamiento. - Use Elasticsearch como modelo de lectura con consistencia eventual para búsquedas y listados, no como caché general. ## Preguntas frecuentes ### ¿Redis o Elasticsearch para cachear las respuestas de una API? Use Redis para cachear por clave objetos, fragmentos calculados y contadores, porque las consultas por clave son rápidas y fáciles de invalidar. Use Elasticsearch cuando lo costoso sea buscar, filtrar u ordenar entre muchos registros, y trate su índice como un modelo de lectura más que como una caché. ### ¿Qué TTL conviene para las respuestas de una API? No hay un valor universal. Fije cada TTL según la antigüedad que puedan tener esos datos sin perjudicar a un usuario, use unos pocos segundos para los datos que cambian rápido y combine los TTL más largos con invalidación en cada escritura. Añada una variación aleatoria para que las claves relacionadas no caduquen a la vez. ### ¿Cómo evitar una estampida de caché en Redis? Deje que una sola petición reconstruya una clave caducada tomando un bloqueo corto con SET y la opción NX, y haga que las demás peticiones esperen un momento o sirvan el valor anterior. Stale-while-revalidate y la actualización anticipada de las claves más solicitadas reducen de entrada el número de caducidades bruscas. ## Servicios relacionados - [Software a medida](https://sdk.enterprises/es/services/product-engineering)