Admission Control

Qué es

Admission Control decide si aceptar, rechazar o diferir nuevo trabajo antes de comprometer una cantidad significativa de capacidad. La decisión se aplica en una frontera identificable y debe indicar qué significa aceptar: ejecutar ahora, reservar recursos o asumir una obligación durable que se resolverá después. Poner todo en una cola sin límite no constituye una política útil de admisión.

incoming request
    -> admission decision
       -> accept and reserve
       -> reject or defer under a bounded contract

Su objetivo es evitar comprometer trabajo que no puede atenderse bajo las condiciones acordadas. Puede considerar estado actual, costo estimado y prioridad, además de políticas de uso. No requiere un controlador predictivo complejo: un límite claro de concurrencia con rechazo explícito puede ser suficiente para un recurso concreto.

Dónde decidir

La frontera debe preceder al consumo que se quiere proteger. Una comprobación después de reservar un worker y cargar un payload enorme no evita ese gasto. Puede ahorrar llamadas a Payment, pero no la memoria ya ocupada en Order. El diseño necesita especificar qué recursos se consumen antes de tomar la decisión.

El punto de entrada tiene contexto de usuario y tenant; una etapa interna conoce mejor su capacidad local. Ninguno posee necesariamente una visión completa. Una aceptación en API Gateway no garantiza que Payment aceptará más tarde. Reservar toda la cadena anticipadamente puede ser costoso y mantener capacidad ociosa; aceptar por etapas exige gestionar fallos posteriores.

AWS advierte que limitar conexiones puede resultar demasiado restrictivo o insuficiente cuando cambian el workload y las dependencias. Esa experiencia respalda escoger señales próximas al recurso que se protege, en lugar de equiparar conexiones con capacidad de servicio. Using load shedding to avoid overload.

Señales y condiciones

Señal	Qué permite evaluar	Límite de la señal
Concurrencia actual	Trabajo que ocupa slots.	Los slots pueden tener costos diferentes.
Recursos disponibles	Memoria, conexiones, workers o permisos libres.	Una medición puede quedar desactualizada.
Queue depth y edad	Trabajo pendiente y deterioro de espera.	Profundidad pequeña no implica trabajo barato.
Latencia	Dificultad para cumplir el objetivo.	Puede reaccionar tarde o mezclar causas.
Capacidad estimada	Margen frente a la mezcla de demanda.	Cambia cuando una dependencia se degrada.
Tenant quota y prioridad	Elegibilidad y reparto entre consumidores.	Política comercial no prueba capacidad física.

El resultado puede depender de varias condiciones, pero cada una debe tener una función comprensible. Rechazar por cuota de tenant y rechazar porque no quedan conexiones son motivos diferentes. Registrarlos separados permite corregir políticas sin interpretar todo rechazo como overload.

Comprobar y reservar

Leer «hay un slot libre» y aceptar después deja una carrera entre callers concurrentes. Si el límite debe ser estricto, la decisión y la reserva necesitan coordinarse con el mecanismo que contabiliza ese recurso. El permiso se libera al terminar el trabajo cubierto, también ante errores y cancelaciones.

La aceptación local no demuestra que un recurso remoto ya se liberó. Si timeout vence pero la llamada continúa, devolver el permiso puede admitir más trabajo que el límite esperado. La contabilidad debe distinguir la espera del caller, la ejecución real y el alcance de la reserva.

Un límite por instancia tampoco equivale a uno global: cinco procesos con veinte permisos pueden admitir cien ejecuciones. Coordinar globalmente introduce latencia y una dependencia adicional. Una aproximación distribuida puede ser válida si el contrato reconoce cuánto excedente tolera y qué protección local permanece.

Aceptar, rechazar o diferir

Aceptar compromete capacidad o responsabilidad según el contrato. Rechazar debe devolver una señal distinguible, sin presentar la operación como completada. Diferir necesita una espera acotada, un límite de backlog y una condición para abandonar o transferir la intención.

Si se devuelve aceptación durable, el sistema asume otra obligación: conservar y resolver el trabajo aunque cambie la conexión original. El control de admisión inicial debe contemplar espacio persistente, edad y recuperación; no puede prometer éxito futuro solo porque pudo escribir un mensaje.

El caller tampoco debe convertir cada rechazo en retry inmediato. Un rechazo por falta de capacidad suele pedir menos presión, no otra tentativa instantánea. Si esos intentos mantienen la degradación, la protección puede participar en retry-storms en lugar de conseguir recuperación. backoff, jitter y presupuestos de repetición ayudan cuando existe una condición real de progreso.

Fronteras conceptuales

Admission Control no equivale a rate-limiting. Un presupuesto de 100 req/s limita tráfico en el tiempo; puede mantenerse igual aunque hoy solo haya capacidad para 60. La admisión puede reaccionar a slots agotados, backlog o estado actual. Un rate limiter puede participar en la decisión de admisión, sin representar toda esa decisión.

Admission Control y load-shedding se superponen en el uso real de los términos. Aquí se distingue el punto de decisión sobre nuevo trabajo del propósito de sacrificar trabajo para preservar salud. Rechazar en admisión puede implementar shedding; shedding también puede retirar trabajo pendiente cuya eliminación sea válida. No existe una frontera terminológica universal.

bulkhead asigna o limita recursos entre grupos; la admisión puede hacer cumplir esos límites. circuit-breaker agrega evidencia de salud para decidir si conviene invocar una dependencia. Ninguno confirma por sí solo capacidad integral para completar una operación de negocio.

Ejemplo y evaluación

En API Gateway → Order → Payment, 100 req/s se atienden con capacidad aproximada de 120. Ante 300 req/s, Order puede rechazar solicitudes nuevas cuando no hay permisos hacia Payment, incluso si el cliente conserva cuota. Un cambio a 60 req/s de capacidad obliga a revisar la admisión aunque el tráfico permanezca en 100.

Usar esta táctica para proteger compromisos concretos bajo recursos finitos. No usar una política adaptativa compleja cuando un límite estático comprobado resuelve el problema. Señales ruidosas y umbrales sin margen pueden alternar aceptación y rechazo; demasiada prudencia desperdicia capacidad y perjudica disponibilidad.

Medir demanda ofrecida, aceptación, causa de rechazo, espera diferida y resultados de lo aceptado. Google SRE recuerda que rechazar también consume recursos, por lo que un volumen extremo puede saturar la propia protección. Handling Overload. Probar la decisión junto con queue-management y la recuperación, no únicamente en estado saludable.