El síntoma

Durante varias semanas la plataforma se saturaba de forma recurrente en las franjas de mayor actividad: la CPU se mantenía alta de forma sostenida y había degradación del servicio justo cuando más gente lo estaba usando. Se notaba en la experiencia y llegaban quejas.

Lo fácil habría sido subir la instancia y seguir. Pero sin entender la causa, escalar solo compra tiempo y tapa el problema. Lo que quería era explicar la sobrecarga con datos, antes y después de tocar nada.

Cómo lo abordé

La API corría detrás de un balanceador, así que activé los logs del ALB, que se van guardando en S3. El problema es que ese volumen no hay quien lo lea a mano, así que monté un pequeño flujo para tratarlos:

• Descarga de los logs del ALB desde S3 al equipo local.
• Agregación con scripts que agrupan las peticiones y sacan lo relevante: volumen, errores, reintentos y endpoints más usados.
• Visualización en dashboards para ver patrones de carga, horas críticas, latencia p95 y los endpoints calientes.

Todo salió de datos reales de tráfico que ya registraba la infraestructura, no de suposiciones.

Lo que encontré

Al cruzar los logs se vio que, en las horas punta, una sola acción del usuario no generaba una única petición: la aplicación lanzaba en paralelo varias peticiones de fondo (notificaciones, chat, tareas pendientes) aunque el usuario ni tocara esos módulos, solo por tener la sesión abierta. Multiplicado por mucha gente a la vez, eso disparaba el número de peticiones y ahogaba la API.

De los datos a las decisiones

• Mejoras de software: se reportaron incidencias concretas para reducir esas peticiones de fondo (notificaciones, chat, tareas) y se limpiaron datos antiguos que metían carga de más.
• Escalado justificado: como medida inmediata, y mientras llegaban los cambios de software, se subió el tipo de instancia. El efecto fue claro: el sistema se estabilizó y dejaron de aparecer las incidencias en horas punta.
• Cierre del círculo: una vez estable, profundicé con los registros de actividad de la aplicación para cruzar lo que hacían los usuarios con los picos de infraestructura, y tener una foto completa de punta a punta.

Conclusión

La sobrecarga no era un fallo puntual, sino la suma de un crecimiento real del uso y un patrón de peticiones internas que multiplicaba la carga, sobre una infraestructura que se había quedado sin margen. Juntar análisis de logs, mejoras de software y un escalado justificado devolvió la estabilidad y, sobre todo, dejó datos sólidos para decidir capacidad y optimización más adelante.

Es observabilidad puesta al servicio de decisiones reales: no "la CPU está alta", sino "este tráfico, a estas horas, por este motivo; y esto se arregla así".