Load and Flow Control

Este mapa organiza decisiones sobre demanda, capacidad, espera y propagación de presión. Empezar por la pregunta que describe el problema observado; no recorrer los controles como una arquitectura obligatoria. Las definiciones y condiciones de corrección permanecen en los canónicos.

Preguntas para navegar

Primary question	Trigger	Action	Scope	Failure mode si se configura mal
¿La demanda supera nuestra capacidad? → overload	Espera creciente, saturación o pérdida de trabajo útil.	Diagnosticar demanda efectiva y capacidad sostenible.	Etapa, dependencia o cadena.	Confundir alta utilización con fallo o mirar solo promedios.
¿Debemos aceptar nuevo trabajo? → admission-control	Un nuevo compromiso necesita recursos.	Aceptar, rechazar o diferir con límites.	Frontera de aceptación.	Aceptar antes de reservar capacidad o decidir demasiado tarde.
¿Qué trabajo sacrificamos para sobrevivir? → load-shedding	Riesgo de agotamiento y sacrificios permitidos.	Rechazar o retirar trabajo elegible de forma observable.	Clases, prioridades y obligaciones.	Descartar silenciosamente una intención durable.
¿Cómo hacemos que upstream desacelere? → backpressure	Downstream no sostiene la emisión.	Propagar presión y reducir producción.	Participantes y etapas cooperativas.	Mover el backlog a un buffer ilimitado.
¿Cuánto trabajo permitimos en tránsito? → flow-control	Se agota una ventana o permiso.	Respetar créditos y su liberación.	Una frontera y unidad concretas.	Devolver autorización antes de liberar el recurso cubierto.
¿Cómo gestionamos trabajo esperando? → queue-management	Burst, backlog, envejecimiento o contención.	Acotar, seleccionar y resolver pendientes.	Colas visibles e implícitas.	Agrandar el buffer como respuesta a un déficit sostenido.
¿Cuánto tráfico admitimos por unidad de tiempo? → rate-limiting	Se consume una cuota temporal.	Regular paso según tasa y burst.	Usuario, tenant, cliente, endpoint o total.	Confundir presupuesto de tasa con límite de concurrencia.

Recorrido: demanda superior al servicio

Leer Overload para separar utilización de demanda insostenible. Seguir hacia Queue Management si crece la espera y hacia Admission Control si el sistema sigue comprometiendo trabajo. Load Shedding permite revisar qué sacrificios son válidos; Backpressure permite preguntar si la presión puede llegar al productor.

Si hay más llamadas que operaciones originales, revisar retry, backoff y jitter. Espaciar intentos y evitar sincronización no crea capacidad. bulkhead puede preservar otros flujos mientras una dependencia está saturada; cada intento sigue consumiendo recursos.

Ejemplo transversal

API Gateway -> Order Service -> Payment Service
 
normal incoming = 100 req/s
useful capacity ~= 120 req/s
spike incoming = 300 req/s

Las cifras son ilustrativas y dependen de la mezcla de trabajo. Sin otra salida y con capacidad estable, se acumulan aproximadamente 180 pendientes por segundo. Los controles responden a preguntas diferentes:

• Rate Limiting puede restringir ingreso a un presupuesto temporal, con un burst explícito.
• Admission Control puede rechazar ahora por recursos agotados, aunque el cliente conserve cuota.
• Bulkhead puede limitar a veinte llamadas concurrentes a Payment para preservar otras categorías.
• Queue Management decide cuánto espera y qué prioridad, edad o resolución corresponde.
• Backpressure puede pedir a Order y Gateway que reduzcan producción, si cooperan.
• Flow Control puede permitir envío solo mientras queden créditos o permisos acordados.
• Load Shedding puede retirar trabajo opcional o rechazar demanda no asumida, preservando obligaciones.

No es necesario incorporar los siete controles. Primero identificar qué recurso, contrato y comportamiento se necesita proteger; después probar cada interacción, incluyendo rechazo y recuperación. Si Payment pierde capacidad, una tasa fija anterior puede dejar de ser segura.

Recorrido: backlog durable

reliable-messaging organiza publicación y procesamiento; retry-topologies explica dónde espera un mensaje y quién reprograma su entrega. Conectar ese recorrido con Queue Management para evaluar edad total y con Backpressure para revisar adquisiciones y prefetch.

No confundir frenar consumo con resolver obligaciones. dead-letter-queue separa casos bajo una política; no añade throughput ni autoriza pérdida silenciosa. La recuperación necesita conservar intención, responsabilidad y un ritmo atendible.

Puente hacia Reliability

resilience-patterns organiza presupuestos de tiempo, repetición, aislamiento y alternativas. timeout puede terminar la espera local sin detener el trabajo remoto; circuit-breaker evalúa salud, no toda la capacidad disponible. fallback requiere un resultado alternativo válido y capacidad propia.

failure-dynamics permite seguir qué ocurre cuando las protecciones no contienen la presión: retry-storms amplifica trabajo, cascading-failures propaga degradación y metastable-failures puede impedir recuperar el régimen saludable. thundering-herd ayuda a revisar liberación simultánea de pendientes y blast-radius evalúa el alcance del impacto. Son preguntas relacionadas, no pasos inevitables.

Las conexiones ayudan a elegir preguntas complementarias. Este MOC ofrece una vista global de navegación; su ruta física no forma parte de la identidad de ninguno de los documentos.