Flow Control

Qué es

Flow Control es un mecanismo que regula cuánto trabajo o dato puede mantenerse en tránsito entre participantes, según la capacidad del receptor o una ventana acordada. El emisor puede avanzar mientras dispone de autorización; cuando la agota, debe esperar una actualización o aplicar una salida definida por el contrato.

receiver grants capacity / window
    -> sender transmits within allowance
    -> receiver consumes or completes covered work
    -> allowance becomes available again

«En tránsito» necesita una definición concreta. Puede representar bytes enviados y aún no confirmados, elementos autorizados para entrega o llamadas pendientes de finalización. Un límite solo tiene sentido si aclara unidad, frontera y evento de liberación. Controlar veinte mensajes no equivale a controlar veinte megabytes ni veinte transacciones costosas.

Mecanismos y contabilidad

Créditos otorgan autorización consumible. Receive windows anuncian el espacio o intervalo que el receptor admite. Permits pueden acotar operaciones simultáneas hacia un destino. Todos requieren contabilidad coherente: lo autorizado no puede gastarse dos veces y la capacidad se devuelve conforme al evento cubierto.

Una ventana de veinte llamadas hacia Payment permite nuevas llamadas mientras queden permisos. Si el permiso cubre ejecución, se libera al finalizarla; si solo cubre una entrega, el trabajo posterior queda fuera de ese límite. Confundir ambos alcances puede permitir un backlog interno enorme aunque el contador de tránsito nunca supere veinte.

La concesión también consume margen: créditos que el emisor aún no utilizó representan capacidad prometida. Reducir un límite no retira automáticamente autorizaciones ya enviadas. El receptor debe contemplar lo previamente permitido y los mensajes que todavía pueden llegar durante la propagación del cambio.

Relación con Backpressure

backpressure describe presión o disponibilidad limitada que afecta a upstream. Flow Control describe el mecanismo de regulación en una frontera. Reducir créditos cuando el consumidor se satura puede implementar backpressure; mantener una ventana fija también regula tránsito aunque no exista una señal adaptativa de saturación.

La distinción es útil para analizar diseño, pero no constituye una taxonomía universal. En streaming se habla de demanda, en messaging de créditos o prefetch y en networking de ventanas. Algunas fuentes incluyen regulación y feedback dentro de una misma noción de flow control. Conviene conservar la semántica concreta del protocolo antes de trasladar nombres entre áreas.

Una frontera regulada no asegura control end-to-end. Un intermediario puede consumir inmediatamente créditos recibidos y guardar todo en una cola propia. Para propagar presión, su autorización upstream debe reflejar también ese almacenamiento y la ejecución downstream. queue-management ayuda a revisar esa capacidad pendiente.

Ejemplos de protocolos

TCP anuncia una ventana de recepción vinculada al espacio que puede aceptar el receptor. Su control de congestión agrega otra restricción sobre el envío; disponibilidad del receptor y capacidad de la red son preguntas diferentes. La recepción de bytes tampoco prueba un commit de negocio. RFC 9293, Managing the Window.

HTTP/2 dispone de ventanas de flow control por conexión y por stream, aplicadas a frames DATA. Funcionan entre extremos de un hop: no autorizan por sí mismas toda la cadena de procesamiento ni cubren cualquier frame. RFC 9113, Flow Control.

Reactive Streams utiliza demanda del subscriber: un publisher no puede emitir más elementos que los solicitados. Esa cantidad limita emisiones autorizadas; no certifica finalización de un efecto externo ni convierte cada elemento en una unidad homogénea de recursos. Reactive Streams JVM specification.

Estos ejemplos ilustran fronteras y unidades diferentes. No implican que una aplicación tenga que adoptar TCP windows como modelo de admisión de pedidos ni que todo protocolo permita devolver créditos del mismo modo.

Diferencias con otros controles

rate-limiting restringe consumo durante un período o presupuesto temporal. Una ventana de veinte operaciones simultáneas puede producir muchas más de veinte operaciones por segundo si terminan rápido, y muchas menos si tardan. Es necesario distinguir autorización por ocupación de autorización por tasa.

bulkhead protege capacidad para grupos o dependencias. Un conjunto de permisos puede servir como mecanismo de flow control y hacer cumplir una partición, pero su propósito de aislamiento añade una pregunta diferente: qué capacidad conserva otro grupo cuando este se satura.

admission-control decide si comprometer nuevo trabajo. Obtener un crédito puede ser una de sus condiciones; la decisión también puede considerar prioridad, cuota y obligaciones. Ninguno de esos nombres implica automáticamente que una operación sea segura para retry.

Ejemplo transversal

En API Gateway → Order → Payment, el tráfico normal es 100 req/s y la capacidad aproximada, 120. Supongamos, solo para ilustrar, que Order tiene veinte permisos para llamadas a Payment. A 100 ms por llamada, el límite permitiría hasta unos 200 inicios por segundo con ocupación continua y costos uniformes; no garantiza ese throughput real.

Si la duración pasa a un segundo, esos mismos veinte permisos permiten aproximadamente veinte finalizaciones por segundo. El límite de tránsito sigue siendo veinte, pero ya no admite el tráfico normal. Una cuota de 100 req/s no sustituye esa protección; tampoco una ventana de veinte resuelve cómo atender la demanda restante.

timeout local no demuestra que Payment dejó de ejecutar. Liberar permisos sin aclarar esa incertidumbre puede romper el límite que se quería mantener. La ventana debe representar el trabajo realmente cubierto o reconocer explícitamente el excedente remoto posible.

Fallos, trade-offs y uso

Ventanas pequeñas pueden dejar capacidad ociosa durante el tiempo que tarda en volver una autorización. Ventanas grandes permiten más trabajo pendiente, memoria ocupada y demora antes de observar presión. El valor debe probarse con tamaños, latencias y costos realistas, no derivarse solo de una tasa promedio.

Créditos duplicados, perdidos o asociados a una conexión anterior requieren reglas de protocolo para evitar exceso o bloqueo permanente. También hay que permitir progreso de mensajes de control: HTTP/2 explica que no leer actualizaciones de ventana puede producir deadlock. RFC 9113, Appropriate Use of Flow Control.

Usarlo entre participantes cooperativos cuando sea importante acotar recursos en tránsito. No tratarlo como defensa suficiente frente a emisores que ignoran el protocolo o frente a trabajo interno fuera de su ventana. Observar autorizaciones, ocupación, demora de devolución, buffers y progreso permite comprobar qué frontera se protege y si el mecanismo implementa backpressure útil.