Backpressure: cuando entran más patentes de las que se procesan

Un servicio de consultas vehiculares recibe trabajo desde varios lugares a la vez: lotes de flotas, consultas interactivas, reescaneos programados y reintentos de entrega de eventos. Todo compite por la misma capacidad finita, que además depende de fuentes externas cuyo ritmo no manejamos.

Mientras entra menos de lo que sale, nada se nota. Cuando la relación se invierte —una jurisdicción lenta, una ola de reescaneo de patentes, un cliente que estrena su integración—, la diferencia se acumula en algún lado.

Llamamos backpressure a la señal que ese punto de acumulación devuelve hacia quien produce el trabajo, para que baje el ritmo o espere. Sin esa señal el sistema no deja de aceptar: sigue diciendo que sí hasta que algo se rompe.

La cola es la diferencia entre dos tasas

Entre la puerta de entrada y el trabajo real casi siempre hay una cola. Su tamaño no es una decisión de diseño: es la resta de dos tasas a lo largo del tiempo, y crece al ritmo de esa diferencia.

Una cola sin tope parece prudente porque nunca rechaza nada. En la práctica convierte la falta de capacidad en dos problemas peores: una latencia que crece sin límite y, más tarde, una caída por memoria agotada, con trabajos aceptados que nadie puede rehacer.

El tope sale de una pregunta operativa: cuánto atraso tolera la promesa que le hicimos al consumidor. Si alguien espera en el mostrador el resultado de una patente, una cola que tarda horas en drenar no guarda trabajo útil.

Backpressure no es un rate limit

Un límite de solicitudes es un acuerdo previo sobre cuántas llamadas entran por ventana y en simultáneo: estable, documentado y planificable, como desarrolla rate limits interpretables.

El backpressure describe la capacidad de este momento. Un cliente puede estar dentro de su cuota y aun así recibir un freno porque el portal de una jurisdicción se degradó o porque otro proceso ocupó la capacidad compartida. El borrador del grupo HTTPAPI del IETF define campos RateLimit para publicar política y cuota disponible: anticipan el freno, pero describen un acuerdo, no la capacidad instantánea.

Los productores internos también cuentan, y suelen ser los más pesados: olas de reescaneo de flotas, reintentos de avisos de actas y reconsultas programadas compiten con las consultas de personas. Un freno que se aplica sólo a los clientes externos no es backpressure; es priorizar el trabajo propio sin decirlo.

429, 503 y 202 no dicen lo mismo

Cuando el freno viaja por HTTP, el vocabulario importa. 429 Too Many Requests, definido en RFC 6585, indica que el cliente envió demasiadas solicitudes en un período. 503 Service Unavailable dice otra cosa: el servidor no puede atender ahora por una sobrecarga temporal o un mantenimiento, y Retry-After señala cuánto se espera que dure. Uno habla del cliente; el otro, del servicio.

202 Accepted confirma que el trabajo fue aceptado para procesar, no que esté terminado, y su representación debería describir el estado, como detalla cuándo responder 202. Aceptar todo con un 202 es la forma más silenciosa de romper una promesa: el cliente escucha un sí y el atraso queda del lado de adentro.

Rechazar también se diseña: conviene definir qué trabajo se frena primero —el reescaneo nocturno de la flota antes que la consulta que alguien espera— y registrar cada rechazo con su causa. Un descarte sin rastro no reduce carga: la traslada a soporte.

Medir el atraso, no el caudal

El caudal engaña: un tablero puede mostrar un procesamiento parejo mientras la cola crece, porque el sistema trabaja a pleno y aun así por debajo de lo que entra. Hacen falta dos métricas: la profundidad, que cuenta trabajos pendientes, y la antigüedad del más viejo, que mide cuánto lleva esperando el primero de la fila.

Se mueven distinto: la profundidad puede bajar mientras la antigüedad sube, si un subconjunto queda trabado esperando a una jurisdicción puntual. La antigüedad es la que se compara contra la promesa.

Las recomendaciones públicas de nombres de métricas sugieren unidades base y un sufijo que las nombre, así que la antigüedad se publica en segundos. La misma guía advierte que cada combinación de etiquetas crea una serie nueva: un motivo más para etiquetar la cola por tipo de trabajo, nunca por patente ni por CUIT.

Qué verificar antes de aceptar más trabajo

Antes de sumar volumen conviene poder responder cuatro preguntas:

• si cada cola tiene un tope explícito y una conducta definida al alcanzarlo;
• si el rechazo sale como 429 o 503 según corresponda, con causa registrada;
• si hay una métrica de antigüedad del trabajo más viejo, con alerta propia;
• si los productores internos se frenan con el mismo criterio que los externos.

La prueba que ordena todo es sostener un ingreso por encima de la capacidad conocida y mirar qué pasa. Si la antigüedad se estabiliza en un valor tolerable y los rechazos quedan registrados, hay backpressure. Si crece sin techo hasta que algo falla, hay una cola larga y una promesa que todavía no se rompió.

Metodología

Alcance

Diseño del tramo interno de una integración de infracciones cuando la demanda supera la capacidad: colas acotadas, criterio de rechazo y métricas de atraso. No cubre el dimensionamiento de infraestructura ni la configuración de un motor de colas particular.

Unidad de análisis

Una cola entre dos etapas del procesamiento, con su tasa de ingreso, su tasa de salida y la antigüedad del trabajo más viejo que contiene.

Cobertura

Semántica de los códigos 202, 429 y 503 según los estándares HTTP citados, campos RateLimit todavía en estado de borrador y convenciones públicas de nombres de métricas.

Limitaciones

• Los topes de cola, los umbrales de alerta y el orden de rechazo dependen de la capacidad y la latencia reales de cada servicio; no existen valores universales que se puedan copiar.
• El backpressure sólo reduce carga si el productor respeta la señal: un cliente que reintenta de inmediato ante un 503 agrega trabajo en lugar de sacarlo.
• Los campos RateLimit citados provienen de un Internet-Draft vigente al cierre de esta nota y pueden cambiar antes de publicarse como RFC.

Fuentes

• RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-29)
• RFC 6585 — Additional HTTP Status Codes — RFC Editor (consultada el 2026-08-29)
• Internet-Draft activo — RateLimit header fields for HTTP — Internet Engineering Task Force (consultada el 2026-08-29)
• Recomendaciones de nombres y etiquetas de métricas — Prometheus (consultada el 2026-08-29)

Preguntas frecuentes

¿Backpressure y rate limit son lo mismo?

No. El límite de solicitudes es un acuerdo previo y estable sobre cuántas llamadas entran por ventana y en simultáneo. El backpressure refleja la capacidad disponible en este momento. Un cliente puede estar dentro de su cuota y aun así recibir una señal de freno porque el sistema está drenando un atraso.

¿Conviene responder 429 o 503 cuando el sistema está saturado?

Depende de quién causó la condición. 429, definido en RFC 6585, informa que el cliente excedió una política de solicitudes. 503 corresponde cuando el servicio no puede atender por una sobrecarga temporal o un mantenimiento, y admite `Retry-After` para indicar cuánto se espera que dure. El código elegido cambia lo que el cliente debería hacer después.

¿Una cola sin límite no es más segura que rechazar trabajo?

No necesariamente. Una cola sin tope no resuelve la falta de capacidad: la transforma en latencia creciente y, más tarde, en una caída con trabajo aceptado que nadie puede rehacer. Un tope adelanta la decisión a un momento en que todavía se puede avisar y reprogramar.

¿Qué métrica muestra que el procesamiento no da abasto?

La antigüedad del trabajo más viejo que sigue en la cola. El caudal procesado puede verse parejo mientras el atraso crece, porque el sistema trabaja a pleno pero por debajo de lo que entra. La profundidad dice cuánto falta; la antigüedad dice cuánto lleva esperando el primero de la fila.

Notas relacionadas