Consultar mil patentes por día: cómo se dimensiona una integración

Mil patentes por día parece un número fácil de acomodar: repartido en todo el día, ni siquiera llega a una consulta por minuto. Sin embargo, casi ninguna integración real se comporta así. El volumen de negocio —cuántos vehículos hay que revisar— y el volumen técnico —cuántas solicitudes HTTP se van a emitir— son magnitudes distintas, y confundirlas es la causa más común de cronogramas que fallan la primera semana.

Dimensionar consiste en convertir el primero en el segundo: un presupuesto de solicitudes que diga cuántas llamadas va a generar el sistema, en qué ventana temporal, con qué margen para reintentos y bajo qué cuotas del proveedor. Ese presupuesto conviene escribirlo antes de programar el primer job, porque cambia decisiones de diseño que después son caras de revertir.

Una patente no es una solicitud

El primer multiplicador es la cobertura. Una misma patente puede requerir consultas en varias jurisdicciones, como explica la nota sobre consultas múltiples, y el caso de uso define cuántas importan. Si la API resuelve esa expansión internamente, el contrato debería decir qué fuentes cubre cada consulta; si la resuelve el cliente, cada patente se convierte en varias solicitudes desde el diseño.

A eso se suman operaciones auxiliares: renovación de credenciales, paginación de resultados largos y consultas de estado cuando el trabajo es asincrónico. Ninguna es exótica y todas consumen cuota. Un presupuesto que sólo cuenta una llamada por patente subestima el tráfico real desde el primer día.

La ventana temporal importa tanto como el total

Un lote repartido en la jornada operativa es un ritmo tranquilo; el mismo lote disparado completo a la hora en que corre el cron es un pico que puede activar límites y degradar el servicio para otros consumidores. El total diario no describe la carga: la describe el ritmo máximo sostenido.

Conviene definir una ventana explícita —por ejemplo, la franja en la que el resultado se usa para decidir— y distribuir las solicitudes dentro de ella. Si el servidor responde con Retry-After, RFC 9110 lo define como la espera indicada antes de volver a solicitar el recurso: respetarlo es parte del cronograma, no una excepción. Las técnicas para no sincronizar clientes, como el jitter, están en la nota sobre polling y se aplican igual a un lote diario.

Los reintentos se presupuestan

Alguna fracción de las solicitudes va a fallar por errores transitorios; eso no es una anomalía sino una propiedad de los sistemas distribuidos. RFC 9110 clasifica a GET como método seguro e idempotente: repetir una lectura es legítimo. Pero legítimo no significa gratis, porque cada reintento consume la misma cuota que la solicitud original.

Por eso el presupuesto incluye un margen explícito para reintentos, con espera creciente y un tope de intentos por patente. El lote además necesita poder reanudarse: si el proceso se interrumpe cerca del final, reemitir todo desde cero duplica el consumo sin aportar información. Un manifiesto por ítem, como el que describe la nota sobre lotes, permite reprocesar sólo lo pendiente.

Cuotas: planificar por debajo y leer las señales

429 Too Many Requests, definido en RFC 6585, indica que el cliente excedió una política de solicitudes; no dice nada sobre la patente consultada. Tratarlo como consulta fallida contamina los datos. Tratarlo como señal de replanificación conserva el lugar del ítem en la cola y reduce el ritmo.

El grupo HTTPAPI del IETF trabaja en campos RateLimit para comunicar políticas y cuota disponible. Al 28 de agosto de 2026 sigue siendo un Internet-Draft: si el proveedor los expone, sirven para ajustar el ritmo, pero no garantizan que la próxima solicitud sea aceptada. La regla operativa es planificar el cronograma por debajo de la cuota contratada, dejando espacio para el margen de reintentos.

La frescura también es una variable de diseño

No toda patente necesita reconsultarse todos los días. RFC 9111 formaliza una idea aplicable más allá del caché HTTP: una respuesta almacenada puede reutilizarse mientras se la considere fresca. La pregunta de diseño es cuánta antigüedad tolera cada decisión: un control previo a una entrega puede exigir datos del día, mientras un tablero de seguimiento quizá tolere más.

Cada reutilización descuenta una solicitud del presupuesto, con una condición: el sistema debe marcar el dato como reutilizado y conservar su fecha de obtención. Reutilizar sin registrarlo convierte el ahorro en un problema de auditoría.

Qué verificar antes de fijar el cronograma

Antes de comprometer un volumen diario en un contrato o un cron, asegurate de poder responder:

• cuántas solicitudes reales genera una patente en el peor caso del caso de uso;
• en qué ventana se necesita el resultado y qué ritmo máximo implica;
• qué margen de reintentos cubre el presupuesto y cómo se reanuda un lote incompleto;
• qué cuota contractual existe y qué distancia queda entre el plan y ese techo;
• qué respuestas pueden reutilizarse y por cuánto tiempo.

Con esas respuestas, el número redondo del título deja de ser una promesa y pasa a ser un plan: un presupuesto de solicitudes que se puede monitorear, auditar y renegociar con evidencia.

Metodología

Alcance

Traducción de un volumen objetivo de consultas de patentes en un presupuesto de solicitudes HTTP para una integración empresarial; no cubre precios, contratos ni la capacidad interna de un proveedor particular.

Unidad de análisis

La solicitud HTTP individual y su relación con la patente que la origina dentro de una ventana temporal.

Cobertura

Semántica de reintentos, Retry-After, 429, campos RateLimit y reutilización de respuestas según los estándares HTTP citados; el volumen de mil patentes es un ejemplo de trabajo, no una medición.

Limitaciones

• Los multiplicadores reales por jurisdicción dependen del caso de uso y de la cobertura contratada; esta nota los razona sin fijar valores.
• Los campos RateLimit siguen siendo un borrador del IETF a la fecha de verificación y cada proveedor puede exponer señales distintas.
• La frescura aceptable de una respuesta es una decisión de negocio que no puede fijarse de antemano para todos los casos.

Fuentes

• RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-28)
• RFC 9111 — HTTP Caching — RFC Editor (consultada el 2026-08-28)
• RFC 6585 — Additional HTTP Status Codes — RFC Editor (consultada el 2026-08-28)
• Internet-Draft activo — RateLimit header fields for HTTP — Internet Engineering Task Force (consultada el 2026-08-28)

Preguntas frecuentes

¿Mil patentes por día equivalen a mil solicitudes por día?

No necesariamente. Una patente puede requerir consultas en varias jurisdicciones, y a eso se suman paginación, consultas de estado y reintentos. El presupuesto de solicitudes suele ser mayor que la cantidad de patentes, y esa diferencia debe calcularse antes de fijar un cronograma.

¿Conviene consultar todas las patentes a la misma hora?

No. Concentrar el lote en un solo momento crea un pico artificial que puede activar límites del proveedor. Es preferible definir la ventana en la que el resultado realmente se necesita y distribuir las solicitudes dentro de ella, respetando las señales de espera del servidor.

¿Qué significa recibir un 429 en medio de un lote?

Significa que el ritmo del cliente excedió una política de solicitudes, no que la consulta de negocio haya fallado. El ítem conserva su lugar en la cola y se reintenta más lento; marcarlo como error contamina los datos y puede duplicar trabajo.

¿Hace falta reconsultar cada patente todos los días?

Depende de la decisión que se toma con el dato. Si una respuesta reciente sigue siendo suficientemente fresca para el caso de uso, reutilizarla descuenta solicitudes del presupuesto. La condición es registrar que el dato fue reutilizado y cuándo se obtuvo.

Notas relacionadas