Arquitectura auditable · Unidad 11 de 13
La admisión vive donde ve la cola
Un límite de capacidad hace dos cosas distintas que es fácil fundir en una. La primera es backpressure: bajo sobrecarga, decirle al cliente 'ahora no, reintenta' con un 503/429 y un Retry-After, en vez de encolar sin cota. La segunda es proteger un recurso escaso —típicamente el pool de conexiones a la base de datos— acotando cuántas peticiones lo tocan a la vez. Son funciones distintas: la primera da una señal al cliente; la segunda evita que un pico ya admitido reviente el motor. Un gate de admisión dentro de la aplicación hace bien la segunda, y es tentador creer que por eso hace la primera. No la hace.
Al terminar podrás
- Separar dos funciones que se confunden en 'admission control': el backpressure al cliente y la protección del recurso escaso.
- Ubicar por qué un gate dentro de la aplicación no puede rechazar la sobrecarga cuando la cola se forma antes, en el servidor.
Entender
Un límite de capacidad hace dos cosas distintas que es fácil fundir en una. La primera es backpressure: bajo sobrecarga, decirle al cliente 'ahora no, reintenta' con un 503/429 y un Retry-After, en vez de encolar sin cota. La segunda es proteger un recurso escaso —típicamente el pool de conexiones a la base de datos— acotando cuántas peticiones lo tocan a la vez. Son funciones distintas: la primera da una señal al cliente; la segunda evita que un pico ya admitido reviente el motor. Un gate de admisión dentro de la aplicación hace bien la segunda, y es tentador creer que por eso hace la primera. No la hace.
El motivo es dónde se forma la cola. En un despliegue con pool de workers (por ejemplo el modo worker del runtime, con un número fijo de procesos long-lived), cuando la carga ofrecida supera la capacidad las peticiones se encolan UPSTREAM —en el servidor, esperando un worker libre— antes de entrar a la aplicación. El gate vive DENTRO del worker, downstream de esa cola: solo ve la petición cuando un worker ya la tomó, así que nunca ve el exceso encolado y no lo puede rechazar. El síntoma es inconfundible: bajo overload el gate registra cero rechazos mientras la latencia observada trepa a segundos. El backpressure solo lo puede dar quien ve la cola, y la cola vive en el edge —un reverse-proxy que rechace rápido (503/429 sin encolar) o el propio límite de concurrencia del pool de workers. La regla: la admisión que da backpressure pertenece al edge; el gate de la aplicación se queda para proteger la base de datos de lo que ya pasó el edge.
Ver
Ver la frontera del sistema
La frontera es donde el sistema decide qué entra; el backpressure de capacidad es una decisión de frontera más —vive donde se ve la cola, no en el fondo de la aplicación.
Hacer
Ejecuta la práctica en tu checkout y conserva la salida como evidencia.
Verificar
Demuestra que puedes aplicar la unidad. El progreso solo avanza al aprobar la evaluación.
Criterios evaluados
- Distingue el backpressure (señal al cliente) de la protección del pool de conexiones (evitar que un pico reviente el motor), y di cuál da cada capa.
- Explica por qué un gate dentro de un worker registra cero rechazos bajo overload aunque la latencia trepe a segundos.
Fuentes primarias
Contenido verificado: 2026-07-23