Reducción de 8 veces en la latencia p95 de la API de un SaaS B2B con una capa de caché Redis en producción

El reto

Un SaaS B2B de rápido crecimiento había chocado con un muro. Su API Python/FastAPI alimentaba paneles para miles de cuentas basadas en puestos, y la ruta de lectura se había convertido en una maraña de consultas ORM N+1, comprobaciones de permisos repetidas y búsquedas de feature flags en cada solicitud. La latencia p95 en los endpoints más concurridos había pasado de 380 ms en el lanzamiento a 1.8 s, la CPU de RDS estaba al 80% durante el horario laboral y el equipo de ingeniería ya estaba presupuestando una mejora vertical de RDS que habría añadido unos $3,400/mes a la factura.

Peor aún, la lentitud era invisible para la mitad de la base de clientes porque el panel se renderiza progresivamente — para cuando los clientes se quejaron, el equipo ya había perdido una renovación empresarial por "el panel parece roto". El equipo necesitaba una solución en semanas, no una replataformización de seis meses.

Nuestra solución

Colocamos una capa de caché Redis de tres niveles y bien disciplinada delante de las rutas de lectura más exigidas y reformamos el modelo de datos para que pudiera almacenarse en caché de forma segura. La inversión estuvo en el diseño de las claves de caché, los contratos de invalidación y la observabilidad — no en arrojar memoria al problema.

Nivel 1: memoización por solicitud dentro del contenedor de dependencias de FastAPI, eliminando las consultas duplicadas dentro de una misma solicitud. Nivel 2: un clúster Redis 7 compartido (modo clúster, AWS ElastiCache) que contiene las lecturas más frecuentes — conjuntos de permisos, feature flags, metadatos de cuentas, agregados de paneles — con TTL explícitos y un sobre Pydantic tipado para que las cargas en caché estén versionadas y puedan evolucionar con seguridad. Nivel 3: un worker de Celery fuera de banda que precalienta los agregados más solicitados inmediatamente después de las escrituras, de modo que la siguiente solicitud del usuario ya sea un acierto de caché.

Cada clave de caché lleva el espacio de nombres inquilino + entidad + versión, cada lectura registra un acierto/fallo en Datadog y cada escritura pasa por un único módulo de invalidación para que un futuro ingeniero no pueda saltárselo en silencio.

• Caché de tres niveles: memoización en proceso, clúster Redis y workers Celery de precalentamiento
• Sobres de caché Pydantic tipados con campo de versión explícito para una evolución segura del esquema
• Claves con espacio de nombres (inquilino + entidad + versión) para que los despliegues nunca sirvan datos de formas mezcladas
• Módulo único de invalidación — todas las rutas de escritura pasan por él; sin saltos silenciosos
• Despliegue con lecturas en sombra y comparación caché-vs-BD en el 10% del tráfico real antes del corte
• Paneles de Datadog para tasa de aciertos, p95, tasa de desalojo y margen de memoria de Redis
• Alertas de PagerDuty por caída de la tasa de aciertos, picos de desalojo y conmutación del primario de Redis
• Pruebas de carga con k6 que reproducen 3 veces el tráfico pico, con un modelo de capacidad documentado