30.000
Herramientas internas para una plantilla de 30.000 personas
Buscador, comunicaciones y reconocimiento entre compañeros dentro de la plataforma de empleado de una gran empresa.
- typescript
- react
- kubernetes
- redis
Redis
Redis hace una cosa muy bien: responder en microsegundos a datos que ya se han calculado. Por eso encaja en tres sitios concretos —caché, colas y sesiones— y desentona en casi todos los demás.
La decisión importante no es instalarlo, es qué se guarda y cuándo deja de ser válido. Una caché sin política de invalidación no acelera un sitio: lo convierte en un sitio que sirve datos viejos de forma impredecible. La clave tiene que incluir todo lo que cambia la respuesta —idioma, permisos, versión desplegada— o antes o después un usuario verá el contenido de otro.
La segunda decisión es qué pasa cuando no está. Una caché tiene que poder caerse sin llevarse el sitio por delante: la aplicación pierde velocidad y sigue respondiendo. Un almacén de sesiones o una cola de trabajos no admiten eso, y ahí es donde entra la topología en alta disponibilidad: réplica y Sentinel para que la promoción sea automática y la aplicación no tenga que saber qué nodo manda.
En la práctica eso se traduce en cosas poco vistosas: la versión fijada por entorno en lugar de seguir la última etiqueta, la cadena de conexión inyectada como secreto y no escrita en la imagen, y un límite de memoria con su política de expulsión decidida a propósito en vez de la que venga por defecto.
Lo que casi nadie mide es la tasa de acierto. Una caché con un 30% de aciertos añade una dependencia y una latencia de red a cambio de casi nada, y hasta que no se instrumenta parece que funciona porque el sitio no se ha roto. Medir aciertos y fallos por tipo de clave es lo que distingue una caché que sirve de una que solo ocupa memoria.
Y hay una pregunta previa que conviene hacerse antes de instalar nada: por qué es lenta la consulta que se quiere cachear. Muchas veces el motivo es un índice que falta o una consulta que trae columnas que nadie usa, y ahí una caché no arregla el problema, lo esconde y además obliga a mantenerla. Cachear una consulta que ya es rápida sí tiene sentido cuando se ejecuta miles de veces por minuto; cachear una lenta suele ser tapar el arreglo real.
Hechos concretos
Proyectos hechos así
24M
Un portal financiero con 24 millones de usuarios al año
Frontend, rendimiento y fiabilidad en producción sobre una plataforma de cotizaciones en tiempo real.
- nextjs
- typescript
- react
- kubernetes
- core-web-vitals
- gcp
- redis
Cómo trabajamos
Cuatro pasos, sin sorpresas
El mismo proceso en un encargo de tres semanas y en una plataforma de dos años.
- 01
Alcance
Una sesión para entender el proceso de negocio, no para enseñar plantillas. Salimos con prioridades y precio por fases.
- 02
Arquitectura
Modelo de datos, integraciones y presupuesto de rendimiento antes de escribir la primera pantalla.
- 03
Construcción
Entregas semanales en un entorno visitable. Lo que se aprueba se despliega, no se acumula.
- 04
Operación
Monitorización, copias verificadas y despliegues que cualquiera del equipo puede ejecutar.
Preguntas frecuentes
¿Necesito Redis o me basta con la base de datos?
Casi siempre basta la base de datos, y decirlo forma parte del trabajo. Redis entra cuando hay una consulta cara que se repite mucho, sesiones que no pueden vivir en un solo servidor, o trabajo en segundo plano que hay que encolar. Si el problema es una consulta lenta que se ejecuta una vez por página, el arreglo suele ser un índice, no una caché.
¿Qué pasa si Redis se cae?
Esa es la pregunta que decide el diseño. Una caché debe poder caerse sin llevarse el sitio: la aplicación va a la base de datos y responde más lento. Una cola o un almacén de sesiones no perdona lo mismo, y por eso ahí va con Sentinel y réplica. Convertir Redis en un punto único de fallo es el error más común, y es de diseño, no de Redis.
¿Se puede usar como base de datos principal?
Se puede, y casi nunca conviene. Redis persiste, pero su modelo de durabilidad es distinto al de una base relacional y la memoria es cara. Como caché, cola, contador o almacén de sesiones es excelente; como sistema de registro de tus facturas, no.
¿Cómo se evita servir contenido caducado?
Decidiendo la invalidación antes que la caché. Caducidad por tiempo cuando el dato tolera minutos de retraso, invalidación explícita al escribir cuando no, y una clave que incluya todo lo que cambia la respuesta: idioma, permisos y versión del despliegue. La mayoría de los fallos de caché son claves incompletas, no tiempos mal puestos.
Sigue por aquí
Siguiente paso
Hablemos de lo que tiene que hacer tu web
Respondemos en un día laborable con una propuesta de alcance por fases, o con la razón por la que creemos que no somos el estudio adecuado para el encargo.