Plataforma de campañas de alto tráfico
Plataforma de campañas y participación de usuarios, con picos de acceso concentrados en ventanas cortas y plazos de campaña innegociables.
Case study anonimizado: nombres de cliente, datos de infraestructura y detalles sensibles se han omitido por confidencialidad.
Contexto
Plataforma digital de campañas y participación de usuarios. Su patrón de carga es el opuesto al tráfico constante: largos periodos de calma seguidos de picos concentrados cuando una campaña sale al aire.
Desafío
Una campaña tiene fecha y hora. Si la plataforma cae en el pico, no hay segunda oportunidad. El plazo es del negocio, no de ingeniería. El sistema tiene que absorber el pico o degradarse de forma controlada.
Mi papel
Senior Software Engineer, centrado en rendimiento de backend, servicios Node.js, base de datos y respuesta a incidentes.
Responsabilidades
- Rendimiento de backend bajo carga concentrada.
- Servicios en Node.js.
- Consultas y modelado en MongoDB.
- Monitorización, uptime y respuesta a incidentes.
Restricciones
- Plazos de campaña innegociables y anunciados públicamente.
- Carga muy irregular: dimensionar para el pico es caro, dimensionar para la media es fallar.
- Un fallo durante la campaña es visible para el usuario final y para el cliente.
Arquitectura
- Caché en los caminos de lectura más calientes, para que el pico no llegue entero a la base de datos.
- Revisión de las consultas del camino crítico de participación.
- Enrutamiento y supervisión de los procesos Node.js.
- Monitorización con atención especial a las ventanas de campaña.
Principales decisiones técnicas
Optimizar el camino crítico de lectura antes de escalar infraestructura.
Por qué
Escalar máquina para compensar una consulta mala multiplica el coste y solo aplaza el problema. El camino de participación es corto y conocido, y se podía abaratar.
Trade-offs
- El trabajo de optimización es más lento que levantar instancias.
- La caché introduce la invalidación, que debe resolverse explícitamente.
- La ganancia, en cambio, permanece cuando el pico ya pasó.
Implementación
- Ajustes de rendimiento en servicios Node.js.
- Revisión de consultas e índices en MongoDB.
- Capa de caché en los endpoints más accedidos.
Operación en producción
- Seguimiento en tiempo real durante las ventanas de campaña.
- Respuesta a incidentes con la campaña en el aire.
- Uptime seguido como métrica de negocio, no solo técnica.
Resultados
- Sostuvo la operación de la plataforma durante los picos de campaña.
- Redujo la carga que llegaba a la base de datos en los endpoints más accedidos.
- Hizo que los incidentes durante campaña fueran diagnosticables desde la monitorización, y no por ensayo y error.
Stack
- Node.js
- MongoDB
- NGINX
- Redis
- Linux