Costo de infraestructura por consulta de multas
La infraestructura no cobra por consulta: cobra por tiempo, por volumen y por byte. Entre esas unidades hay un modelo que conviene construir con mediciones y no con intuiciones.
Una integración de flota se contrata por consulta, pero la infraestructura no cobra por consulta: cobra por tiempo de cómputo, por volumen almacenado y por byte transferido. Entre esas dos unidades hay un modelo, que se construye con mediciones o se improvisa con intuiciones.
El costo de infraestructura por consulta es el gasto de un período dividido por las consultas atendidas en ese mismo período, con las dimensiones que expliquen por qué una salió barata y otra cara. No es un precio: es una medición interna para dimensionar capacidad, elegir qué optimizar y sostener con evidencia los límites que se publican.
El error más común es tratarlo como un número único. Una consulta que resuelve una jurisdicción rápida no consume lo mismo que otra que abre cinco fuentes lentas, reintenta dos veces y termina parcial. En el tablero, las dos se esconden detrás del mismo promedio.
Qué entra en la unidad de costeo
Antes de dividir hay que decidir qué cuenta como una consulta. Una definición operativa razonable es el trabajo disparado por una solicitud de negocio hasta su estado terminal: el fan-out a las jurisdicciones, los reintentos internos, la normalización, la escritura del resultado y las lecturas de estado mientras el cliente espera.
Con esa unidad, el gasto se reparte en componentes que se miden por separado:
- cómputo del proceso que orquesta, espera y normaliza;
- transferencia de salida hacia el cliente y hacia terceros;
- almacenamiento del resultado y su historial, multiplicado por el tiempo de retención;
- telemetría de esa misma consulta: trazas, métricas y registros.
El último renglón se olvida seguido: observar también consume. Una traza por fuente y un registro por reintento crecen con el mismo factor que el trabajo que describen.
Cada proveedor factura con su propia estructura. El modelo sirve cuando sus renglones se pueden reconciliar con los del resumen que después hay que pagar.
Magnitudes primero, tarifas después
Medimos por consulta las magnitudes físicas —duración, jurisdicciones consultadas, reintentos, bytes escritos y transferidos— y aplicamos las tarifas recién en el análisis. Guardar un importe junto a cada consulta parece cómodo, pero deja el histórico inconsistente apenas cambia una tarifa.
Las recomendaciones de nombres y etiquetas de Prometheus sugieren instrumentar en unidades base, segundos y bytes, y dejar las conversiones para la presentación. Es lo que necesita un modelo de costos: una serie estable de magnitudes y una capa de tarifas encima, editable sin tocar la historia.
El promedio borra la distribución
Un promedio puede bajar porque llegó un lote de patentes triviales, no porque la consulta cara haya mejorado. Para decidir hacen falta la forma de la distribución y los cortes por dimensión.
La especificación del SDK de métricas de OpenTelemetry define vistas que permiten cambiar la agregación o descartar atributos antes de exportar. Una agregación de histograma con buckets explícitos conserva la distribución; un promedio la reduce a un punto. Los buckets se eligen sobre el tramo donde vive la consulta cara.
Etiquetas que explican sin exponer
Cada combinación de valores de etiqueta crea una serie temporal nueva, y esa cardinalidad tiene su propio costo. La lista de dimensiones se elige, no se improvisa: credencial o cliente, jurisdicción, resultado —completo, parcial o fallido— y origen del pedido.
Patente, CUIT o identificadores de persona no son dimensiones de costo: son datos personales dentro de un sistema de métricas, con las consecuencias que describimos en trazas y métricas sin patentes ni CUIT.
Palancas que mueven el número
RFC 9110 define las solicitudes condicionales: si la representación no cambió, el servidor puede confirmarlo sin reenviar el cuerpo. Eso recorta transferencia y serialización, no la recepción ni la autenticación del pedido; el ahorro es real pero parcial, como se detalla en polling sin saturar la API.
RFC 9111 va un paso más: una respuesta almacenada y todavía fresca puede reutilizarse sin llegar al origen. Sobre resultados por patente o por persona la palanca está limitada, porque el estándar restringe la reutilización compartida de respuestas a solicitudes autenticadas. Rinde en catálogos, documentación y metadatos no personales.
Quedan dos palancas menos vistosas y a menudo más efectivas. La ventana de deduplicación hace que dos consultas de la misma patente, cercanas en el tiempo, compartan una ejecución. La retención multiplica volumen por tiempo, así que acortarla mueve el almacenamiento tanto como una optimización de código.
Qué verificar antes de comprometer un número
Revisá que el período de medición cubra un ciclo completo, con sus picos y sus lotes nocturnos. Dejá explícito si los costos fijos —capacidad reservada, licencias, guardia— se prorratean o se excluyen, porque a bajo volumen dominan el resultado. Confirmá que las dimensiones del tablero coincidan con las del modelo.
Y volvé a medir después de cada palanca: una optimización que baja bytes puede subir cómputo, y el balance sólo se ve en la unidad completa.
Un costo por consulta vale cuando se puede reproducir: misma unidad, mismas dimensiones, mismo período. Sin eso es una cifra que cambia de significado cada vez que alguien la calcula.
Metodología
- Alcance
- Modelo de costeo unitario para una API de consultas de infracciones, del lado de quien opera el servicio. No incluye tarifas de proveedores, estructura comercial ni cifras propias.
- Unidad de análisis
- Una consulta de negocio desde que se acepta hasta su estado terminal, con su fan-out a fuentes, reintentos internos, escrituras y lecturas de estado.
- Cobertura
- Semántica de RFC 9110 y RFC 9111 para las palancas de revalidación y reutilización, y recomendaciones de instrumentación de Prometheus y OpenTelemetry para la medición y la agregación.
Limitaciones
- Las tarifas, la estructura de facturación y el prorrateo de costos fijos dependen de cada proveedor y contrato; la nota no los estima.
- La nota describe cómo construir la medición, no publica su resultado: no incluye valores de costo propios.
- Las palancas de caché y revalidación se comportan distinto sobre datos públicos que sobre resultados por patente o por persona.
Fuentes
- RFC 9110 — HTTP Semantics — RFC Editor (consultada el )
- RFC 9111 — HTTP Caching — RFC Editor (consultada el )
- Recomendaciones de nombres y etiquetas de métricas — Prometheus (consultada el )
- Especificación del SDK de métricas de OpenTelemetry — OpenTelemetry (consultada el )
Preguntas frecuentes
¿El costo por consulta es lo mismo que el precio por consulta?
No. El costo es una medición interna de recursos consumidos. Un precio incorpora además costos fijos, soporte, riesgo y decisiones comerciales que no salen de la infraestructura.
¿Conviene guardar el importe en pesos junto a cada consulta?
Suele ser preferible guardar las magnitudes físicas —duración, bytes, fuentes consultadas, reintentos— y aplicar las tarifas en el análisis. Si se persiste un importe, cualquier cambio de tarifa deja el histórico inconsistente y difícil de recalcular.
¿Una respuesta sin cuerpo elimina el costo de esa consulta?
No. Una revalidación condicional evita transferir una representación que no cambió, pero la solicitud igual se recibe, se autentica y se evalúa. El ahorro es de transferencia y serialización, no de atención.
¿Alcanza con mirar el promedio de costo por consulta?
Como control de tendencia puede servir. Para decidir no alcanza, porque el promedio baja cuando llega un lote de consultas triviales aunque la consulta cara siga igual. Hace falta la distribución y los cortes por dimensión.
Notas relacionadas
Consultar mil patentes por día: cómo se dimensiona una integración
Mil patentes por día no equivalen a mil solicitudes: cada dominio puede requerir varias jurisdicciones, reintentos y reconsultas. Dimensionar es convertir ese volumen en un presupuesto verificable.
Polling de consultas de multas sin saturar la API: Retry-After y ETag
Consultar el estado cada segundo no hace que una búsqueda termine antes. Un contrato con Retry-After, ETag y una espera aleatoria reduce solicitudes repetidas, bytes y picos de clientes sincronizados.
Convivencia de dos proveedores durante una migración
Durante una migración hay semanas en las que dos fuentes describen la misma realidad. Conviene decidir por fuente cuál gobierna la respuesta publicada y cómo se clasifica cada diferencia.