16.07.2026
Caching strategies: guía para escalar tu arquitectura
Estrategias de caching, cómo escalar tu arquitectura.
Pedro Cailá
Tu producto iba bien hasta que dejó de ir bien. No porque faltara una feature crítica ni porque el equipo backend escribiera mal SQL. Suele pasar cuando el tráfico sube, el mismo dato se pide una y otra vez y la base de datos termina haciendo trabajo repetitivo que nadie le debería pedir.
En startups esto llega pronto. Primero ves picos de CPU, luego consultas lentas, después el proveedor cloud empieza a cobrarte la ansiedad y finalmente soporte recibe quejas por tiempos de carga erráticos. Si tu respuesta a todo eso es “subamos la máquina”, estás comprando tiempo, no resolviendo el cuello de botella.
Las caching strategies no son un truco de rendimiento. Son una decisión de arquitectura para proteger la base de datos, bajar latencia y mantener el producto usable mientras la empresa sigue creciendo con recursos limitados. Bien hechas, simplifican la operación. Mal hechas, introducen datos obsoletos, inconsistencias y una falsa sensación de control.
Por qué tu base de datos te pide ayuda a gritos
El patrón suele ser siempre el mismo. Una pantalla popular del producto consulta perfiles, permisos, catálogo, configuración y algún agregado. La primera versión funciona. Luego entran más usuarios, se multiplican las lecturas repetidas y la base de datos pasa de ser tu fuente de verdad a convertirse también en tu capa de serving. Ahí empiezan los problemas.
La mayoría de aplicaciones de negocio leen mucho más de lo que escriben. Un SaaS B2B consulta el mismo workspace cientos de veces. Un e-commerce pide el mismo catálogo, las mismas fichas y los mismos bloques de navegación. Una app de contenido recalcula respuestas que podrían servirse desde memoria. Si todo eso golpea directamente a PostgreSQL o MySQL, has convertido una pieza crítica en tu punto único de fatiga.
Señales de que ya vas tarde
Hay síntomas que un CTO reconoce rápido:
- Latencia irregular: una request responde bien y la siguiente tarda mucho más sin cambio aparente en lógica de negocio.
- Infraestructura sobredimensionada: añades réplicas o más CPU para sostener lecturas repetidas que no aportan valor.
- Escalado frágil: cada campaña, mención o pico de uso obliga a vigilar dashboards como si fueras un operador de bolsa.
- Equipo bloqueado: ingeniería invierte tiempo en apagar fuegos de rendimiento en lugar de construir producto.
La caché no reemplaza una base de datos mal diseñada. Pero sí evita que una base de datos bien diseñada muera por trabajo absurdo.
Aquí está la parte incómoda. Muchos equipos llegan al caching demasiado tarde porque lo ven como optimización prematura. No lo es cuando la misma información se lee sin parar y cambia poco. Ahí la caché deja de ser opcional. Es parte del diseño del sistema.
El problema real no es técnico, es de negocio
Si la aplicación tarda, el usuario no distingue entre una query lenta y una mala experiencia. Para producto es fricción. Para negocio es pérdida de confianza. Para finanzas es más gasto en cloud del necesario. Y para el equipo técnico es menos margen para iterar.
La caché introduce una capa intermedia que absorbe ese trabajo repetitivo. Redis, caché en memoria de aplicación, CDN o caché de navegador cumplen funciones distintas, pero comparten una idea simple: no recalcules ni vuelvas a pedir lo que ya sabes.
La decisión importante no es “si usar caché”. La decisión correcta es qué cachear, dónde hacerlo y cuánto riesgo de inconsistencia aceptas. Esa es la conversación madura en una startup que quiere escalar sin convertir su arquitectura en un experimento permanente.
Fundamentos de caching que de verdad importan
El lunes por la mañana entra una campaña, suben las lecturas 4x y la base de datos sigue recibiendo consultas para los mismos perfiles, la misma configuración y los mismos listados. En ese punto, hablar de caching en abstracto no sirve. Lo que decide si la arquitectura aguanta o se rompe son tres variables: hit rate, TTL y latencia observable.
Hit rate y por qué importa más que la intuición
La tasa de aciertos o hit rate mide cuántas lecturas se resuelven desde caché sin tocar la fuente original. Es una métrica de negocio disfrazada de métrica técnica, porque te dice si la inversión en Redis, memoria local o CDN realmente está comprando capacidad para crecer.
Como referencia práctica, una caché suele empezar a justificar su coste cuando resuelve la mayoría de las lecturas repetidas. Si el hit rate se mantiene bajo, el problema rara vez es “falta de caché”. Suele ser una mezcla de TTL mal elegido, claves demasiado dispersas, poco espacio asignado o datos que cambian tanto que nunca llegan a reutilizarse. Esta guía práctica sobre estrategias de caching resume bien ese punto y también ofrece rangos de TTL útiles según el tipo de dato.
En startups y scaleups, el error común es mirar el hit rate global y darlo por bueno. Eso oculta decisiones pobres. Puedes tener una media aceptable y, aun así, fallar justo en las rutas que más dinero mueven. Conviene medir por endpoint, por dominio de datos y por operación crítica. Checkout, pricing, catálogos, feeds, permisos. No todos merecen el mismo esfuerzo.
TTL bueno y TTL malo
El TTL define cuánto tiempo das por válido un dato en caché. Esa decisión no se toma en una reunión de infraestructura. Se toma entendiendo cuánto cuesta servir un dato viejo y cuánto cuesta recalcularlo una y otra vez.
Mi criterio es simple. Empieza por el impacto del dato, luego ajusta por volatilidad. Si un precio incorrecto te puede costar ingresos o soporte, el TTL debe ser corto o la invalidación muy fiable. Si un perfil de usuario tarda unos minutos en reflejar un cambio menor y eso no rompe nada, puedes alargarlo sin drama. Si un catálogo cambia poco y se consulta todo el día, conviene exprimir la caché.
Una mala práctica muy extendida en equipos pequeños es poner el mismo TTL para todo porque acelera la implementación. A corto plazo parece ordenado. A medio plazo crea dos problemas: invalidas datos que podrían vivir más tiempo y mantienes demasiado tiempo datos que ya no deberían servirse.
- Datos muy volátiles: TTL corto. Acepta más misses.
- Datos con cambios controlados: TTL medio si el coste de inconsistencia es bajo.
- Datos casi estáticos: TTL largo, siempre que la invalidación esté resuelta.
Regla práctica: el peor TTL es el que nadie puede explicar.
Si tu equipo backend todavía está afinando responsabilidades entre aplicación, servicios y datos, conviene revisar cómo se reparte el trabajo real en un backend moderno. Ayuda a decidir qué debe resolver la caché y qué sigue siendo problema de modelado, consultas o diseño de sistema.
Latencia observable, no latencia teórica
La caché no se evalúa por lo rápido que responde Redis en una prueba aislada. Se evalúa por lo que pasa en producción, con serialización, red, misses, thundering herd y claves calientes.
Por eso la métrica útil no es “la caché responde rápido”. La métrica útil es cuánto mejora una petición real cuando hay hit, cuánto empeora cuando hay miss y qué porcentaje del tráfico cae en cada caso. Si no observas esa diferencia, puedes terminar manteniendo una capa operativa extra que complica el sistema sin aliviar la ruta crítica.
He visto equipos añadir caché distribuida demasiado pronto y perder tiempo en consistencia, invalidaciones y coste operativo, cuando una caché local por proceso ya resolvía la mayor parte del problema. También he visto el caso contrario. Aplicaciones que crecieron con caché en memoria dentro del servicio, luego escalaron horizontalmente y empezaron a servir resultados incoherentes entre instancias. La decisión correcta depende del momento de la empresa. En una startup, simplicidad primero. En una scaleup, previsibilidad.
Qué medir en producción
No hace falta montar un laboratorio. Hace falta instrumentar lo suficiente para decidir bien.
- Hit rate por clave, endpoint o grupo de datos.
- Latencia real en hit frente a miss.
- Volumen de invalidaciones y motivo.
- Carga residual en base de datos después de introducir caché.
- Errores inducidos por caché, como datos obsoletos, stampedes o picos tras expiraciones simultáneas.
La caché útil no es la que se ve sofisticada en el diagrama. Es la que reduce coste, protege la base de datos y da margen al equipo para seguir entregando producto sin convertir cada pico de tráfico en una crisis.
Patrones de caching comunes y cuándo usarlos
La peor decisión aquí es buscar “el mejor patrón”. No existe. Existen patrones que encajan con la forma en que lees, escribes y toleras inconsistencias.
Para comparar de forma rápida, esta visual resume bien las opciones más habituales.
Cache aside para empezar sin complicarte la vida
Si estás montando una startup con mucho tráfico de lectura y relativamente poca escritura, Cache-Aside es casi siempre el primer patrón sensato. La aplicación pregunta a Redis. Si hay dato, lo devuelve. Si no lo hay, va a la base de datos, obtiene el valor y lo mete en caché.
Me gusta porque mantiene la lógica en la aplicación y no te obliga a introducir una capa más compleja demasiado pronto. En catálogos, perfiles, flags de configuración o resultados agregados funciona muy bien. El coste es evidente. En un miss pagas la lectura completa, y si varios procesos fallan a la vez sobre la misma clave puedes generar ráfagas a la base de datos.
Usa este patrón cuando quieres avanzar rápido, tienes control del código y necesitas una solución predecible.
Read through cuando prefieres centralizar comportamiento
En Read-Through, la aplicación siempre consulta la caché y es la propia capa de caché la que resuelve los misses contra la fuente de datos. Es más limpio desde fuera. También es más exigente desde dentro.
Lo recomiendo menos en startups tempranas porque añade sofisticación operativa antes de tiempo. Tiene sentido cuando quieres una abstracción fuerte alrededor de lecturas o cuando varios servicios deben compartir el mismo comportamiento de carga y refresco.
Si tu equipo todavía discute cómo versionar el contrato de una API, no metas un patrón de caché que esconda demasiada lógica bajo la alfombra.
Write through si la consistencia pesa más que la velocidad de escritura
Write-Through escribe en caché y en base de datos de forma síncrona. La ventaja es obvia. Reduces el riesgo de desalineación entre lo que lees y la fuente de verdad. El precio también es obvio. Cada escritura hereda la latencia del commit y la ruta de fallo se vuelve más delicada.
Esto encaja cuando el coste de leer un dato desactualizado es alto. Piensa en configuraciones sensibles, estados visibles por múltiples usuarios o información que se consulta inmediatamente después de escribirse. No lo usaría por defecto en todo el sistema. Lo usaría donde el negocio te castiga por inconsistencia.
Aquí conviene tener claro cómo se comporta tu capa de acceso, porque la elección entre lectura directa, agregación flexible y contratos más rígidos también afecta a la estrategia. Si estás valorando ese diseño, esta comparación entre REST y GraphQL da buen contexto para decidir dónde colocar responsabilidad y cacheabilidad.
Write behind solo cuando entiendes muy bien el riesgo
Hay una idea de Write Behind que resulta tentadora en cuanto aprietas latencia de escritura. La operación se reconoce primero en caché y la base de datos se actualiza después. La descripción exacta aparece en este repaso de mecanismos de caché, donde se explica que la escritura se realiza primero en la caché para que la aplicación vea el cambio de inmediato y luego se persiste pasado un tiempo.
El patrón es útil cuando absorber picos de escritura importa más que la durabilidad inmediata. Pero no lo vendería como solución general. Si la caché cae antes de vaciar cambios, puedes perder actualizaciones. Si no tienes observabilidad fuerte, colas claras y recuperación bien pensada, has ganado milisegundos y comprado un incidente.
Para aterrizar los conceptos, este vídeo resume bastante bien las diferencias de enfoque en patrones de caché.
Un marco simple para decidir
No hace falta montar una matriz enorme. Hazte estas preguntas:
- ¿Leen mucho más de lo que escriben? Empieza por Cache-Aside.
- ¿Necesitas ocultar misses a la aplicación? Considera Read-Through.
- ¿Te penaliza leer desactualizado? Evalúa Write-Through.
- ¿Tu prioridad extrema es absorber escrituras rápidas y aceptas complejidad? Solo entonces piensa en Write Behind.
La mayoría de startups no fallan por elegir mal un patrón exótico. Fallan por aplicar el mismo patrón a todos los datos como si todos tuvieran el mismo valor operativo.
Políticas de evicción y vencimiento no son lo mismo
Muchos equipos mezclan dos conceptos distintos y luego se sorprenden cuando la caché se comporta “raro”. Vencimiento no es lo mismo que evicción. El primero decide cuándo un dato deja de ser válido. El segundo decide qué dato sale cuando ya no hay espacio.
La forma más fácil de explicarlo es con comida. El TTL es la fecha de caducidad del yogur. La evicción es elegir qué sacas de la nevera cuando compras más y no cabe todo. Ambos afectan a lo que conservas, pero por motivos distintos.
TTL controla frescura
Cuando un valor alcanza su TTL, el sistema debe tratarlo como expirado. Puede recargarse, refrescarse o invalidarse según el patrón que uses. El foco aquí es la actualidad del dato.
Un error muy común es pensar que un TTL largo “optimiza” siempre. No. A veces solo esconde que tu equipo no ha diseñado una invalidación mínimamente seria. Si el dato cambia con frecuencia y el usuario nota el cambio, un TTL largo empeora el producto aunque la infraestructura parezca respirar mejor.
Evicción controla escasez
La evicción entra en juego cuando la caché está llena. Ahí ya no se debate si un dato sigue vigente. Se decide si merece ocupar memoria.
Según esta explicación sobre caching y CDN, LRU elimina los elementos menos accedidos recientemente y LFU expulsa los accedidos con menor frecuencia. La diferencia importa. LRU suele funcionar bien cuando la recencia predice valor. LFU encaja mejor cuando ciertos datos se consultan repetidamente aunque no hayan sido accedidos hace un instante.
Una caché pequeña con una política de evicción coherente suele rendir mejor que una caché grande gestionada por intuición.
Cómo elegir sin sobrepensarlo
No conviertas esto en una tesis de algoritmos. Decide por patrón de acceso:
- Usa LRU si tus usuarios siguen comportamientos recientes, como navegación por sesiones, pantallas visitadas o contenidos “calientes”.
- Usa LFU si hay claves muy populares de forma sostenida, como configuración global, catálogos o metadatos compartidos.
- Revisa tamaño y cardinalidad antes de culpar al algoritmo. Muchas veces el problema es que la caché no cabe, no que la política sea mala.
El fallo práctico no está en no saber la teoría. Está en no distinguir si pierdes rendimiento por datos caducados o por falta de espacio. Son diagnósticos distintos y requieren acciones distintas.
Implementación práctica en arquitecturas de startups
Voy a ser directo. Para la mayoría de startups que ya operan más de un servicio o más de una instancia, Redis es el punto de partida correcto. No porque sea mágico, sino porque resuelve el problema real de compartir datos en una arquitectura distribuida sin obligarte a mantener coherencia manual entre memorias locales.
La idea está alineada con esta guía sobre estrategias de caché de alto rendimiento, que sostiene que Redis es la opción adecuada para aplicaciones distribuidas con datos compartidos, mientras que la caché in-memory encaja en aplicaciones de un solo servidor con datos temporales. Esa distinción evita muchos errores de diseño tempranos.
Dónde encaja cada capa
Una estrategia seria suele combinar varias capas, cada una con una función clara.
- Caché en navegador: útil para assets estáticos y respuestas que pueden vivir en cliente.
- CDN: ideal para acercar contenido cacheable al usuario y descargar origen.
- Redis o Memcached: capa compartida para datos dinámicos reutilizables entre instancias.
- Memoria local de aplicación: válida para objetos efímeros o cálculos cortos por proceso.
Lo importante no es tener muchas capas. Es que cada una tenga una responsabilidad nítida.
Mi postura sobre in-memory
La caché local en proceso parece atractiva porque es rápida y trivial de implementar. También genera una clase de bug muy desagradable cuando escalas horizontalmente. Cada instancia guarda una versión distinta y la invalidación se vuelve una conversación entre procesos que no querías tener.
Por eso la uso solo en dos casos. Uno, cuando la aplicación vive en un único nodo. Dos, cuando el dato es puramente temporal y no importa que otra instancia no vea exactamente lo mismo. Para todo lo demás, prefiero centralizar en Redis y asumir el salto de red a cambio de consistencia operativa razonable.
Tres decisiones concretas que sí cambian el resultado
Aquí es donde muchos equipos se quedan cortos:
- Separar tipos de datos por namespace de claves. No mezcles sesiones, catálogos y resultados agregados como si fueran lo mismo.
- Definir invalidación desde el diseño. Si un dato cambia, alguien tiene que saber quién purga qué.
- Sincronizar capas cuando hay más de un nivel. La guía de la Junta de Andalucía sobre consistencia en sistemas distribuidos recuerda que la caché de primer nivel, la de segundo nivel y la base de datos deben coordinarse con una estrategia de concurrencia definida para evitar datos contradictorios.
La caché multicapa solo compensa cuando cada nivel reduce una clase concreta de coste. Si no, añade complejidad y retrasa incidentes en vez de evitarlos.
Qué pondría hoy en una scaleup pequeña
Si estuviera diseñando una arquitectura para un equipo en crecimiento, arrancaría así:
- Frontend con caché de navegador para assets versionados.
- CDN para estáticos y páginas o fragmentos claramente cacheables.
- Redis para sesiones, configuración, agregados y lecturas repetidas de dominio.
- Base de datos como única fuente de verdad, sin inventar dobles escrituras innecesarias.
- Observabilidad mínima sobre misses, expiración e invalidación.
Si el equipo además está creciendo y necesita ordenar ownership entre plataforma, backend y operaciones, este artículo sobre qué hace un ingeniero DevOps ayuda a repartir responsabilidades de infraestructura y operación sin solapar funciones.
Navegador y edge también cuentan
No toda caché vive en backend. Para estáticos, una política correcta en cliente evita viajes absurdos al servidor. Esta guía práctica sobre cache en frontend recomienda usar nombres con hash en bundles de CSS y JS con caché larga, mientras que el HTML debe preferir no-cache o tiempos cortos para actualizar rápido. Y en navegador, esta explicación sobre usos de memoria caché ilustra el uso de Cache-Control con max-age, incluyendo el ejemplo max-age=604800, equivalente a 7 días, para definir la vida de caché estática.
Ese detalle separa a los equipos que “usan caché” de los que realmente la diseñan de extremo a extremo.
Errores comunes y estrategias avanzadas a evitar al principio
Los problemas de caché más caros no aparecen por falta de herramientas. Aparecen por decisiones precipitadas. Equipos que cachean todo. Equipos que no invalidan nada. Equipos que meten una capa distribuida sin saber qué clave merece existir.
Errores que veo repetirse
- Cachear datos sin patrón de lectura claro: si algo se consulta poco o cambia constantemente, quizá no merece caché.
- Tratar la invalidación como detalle de implementación: no lo es. Es parte del modelo de consistencia.
- Copiar estrategias de empresas enormes: tu startup no necesita la misma complejidad que Amazon o Cloudflare en la fase inicial.
- No documentar ni entrenar al equipo: esta recomendación sobre patrones y operaciones de caché insiste en documentar la estrategia y entrenar al equipo para reducir riesgo operativo y acelerar la resolución de incidencias de inconsistencia.
Estrategias avanzadas que solo tienen sentido más tarde
Hay técnicas potentes que conviene conocer, pero no adoptar por ansiedad arquitectónica. Una de ellas es trabajar con TTLs duales. La idea consiste en separar un TTL blando de uno duro para seguir sirviendo datos tolerables cuando el backend falla, en lugar de tumbar todo por una expiración estricta.
AWS recoge en su documento sobre desafíos y estrategias de caching que este enfoque puede reducir errores en 40% en servicios con disponibilidad inferior al 99% durante tráfico intenso. Es valioso. También es una solución para un problema específico, no una obligación temprana.
Si aún no sabes exactamente qué claves invalidas después de una escritura, no estás listo para TTLs duales.
Otra técnica que suele llegar demasiado pronto es la invalidación distribuida compleja. También el multi-level caching lleno de reglas especiales. Ambas pueden ser correctas cuando el sistema ya ha demostrado esos límites. Antes de eso, suelen introducir más incertidumbre que rendimiento.
Checklist corto para no meterte en problemas
- Empieza por pocas claves de alto impacto.
- Define quién invalida y cuándo.
- Mide misses antes de optimizar aciertos.
- No mezcles patrones de escritura sin motivo.
- Documenta la estrategia como parte del sistema, no como nota interna.
La mejor caché inicial no es la más sofisticada. Es la que tu equipo entiende, opera y corrige sin abrir una investigación forense cada vez que un usuario ve un dato viejo.
Si estás escalando producto y equipo a la vez, el problema no es solo elegir Redis, definir TTLs o decidir quién invalida. También necesitas ingenieros capaces de tomar esas decisiones con criterio y ejecutarlas sin sobreingeniería. En Kulturo trabajamos con CTOs, founders y líderes de ingeniería que necesitan incorporar talento backend, DevOps, data o AI en startups y scaleups españolas. Si estás formando un equipo técnico para sostener el siguiente salto de arquitectura, podemos ayudarte a contratar perfiles que ya han pasado por ese punto de inflexión.
