El tráfico se dobla y tu servicio empieza a encolar peticiones hasta que todo agota el timeout. ¿Qué haces?

Aplica contrapresión en vez de acumular. Acota todas las colas, descarta carga pronto con un 429 o un 503 cuando se alcanzan los límites de concurrencia, y rechaza las peticiones cuyo plazo ya ha vencido en vez de trabajar en ellas. Las colas sin límite convierten una sobrecarga en un colapso de latencia, porque cada petición espera detrás de trabajo que ya no espera nadie. Prioriza por tipo de tráfico si unas cosas importan más que otras, y autoescala con una señal que se adelante, como la profundidad de la cola.

El instinto es poner una cola más grande, pero eso solo convierte una sobrecarga en un fallo lento, porque cada petición se sienta detrás de un atasco y, cuando por fin se atiende, el cliente ya se ha rendido. Así que lo primero que hago es acotar la cola y añadir un límite de concurrencia, y cuando se llena devuelvo un 503 con retry after inmediatamente. Rechazar rápido es más amable que agotar el timeout despacio, tanto para el usuario como para el sistema. Segundo, compruebo el plazo antes de hacer el trabajo: si la petición lleva esperando más que su presupuesto, la descarto, lo que libera capacidad para las que todavía pueden salir bien. Ese cambio por sí solo es el que recupera el rendimiento de forma visible durante un incidente. Después la priorización, porque no todo el tráfico es igual; en un sistema descartábamos primero el tráfico de sincronización en segundo plano y manteníamos fluidas las peticiones interactivas. Y escalo con la profundidad de cola o la concurrencia en vez de con la CPU media, porque la CPU se aplana cerca de la saturación y reacciona demasiado tarde para servir de algo.