Publicación
Reducción del costo marginal por visita en el Observatorio de Leyes
Cómo pasar de un servicio que se acercaba al límite operativo a un modelo de costo acotado mediante caché, compresión e invalidación selectiva.
Un análisis de la arquitectura que elevaba el costo por visita en un servicio público de datos legislativos y de las intervenciones que redujeron transferencias, renderizados e invalidaciones innecesarias.
Antes de abrir el paper
- Problema
- Con 8.034 normas y 90.945 artículos, el Observatorio sufría suspensiones por costo operativo. El backend recibía cerca de 1.600 solicitudes por hora frente a 46 visitas: el costo no era una función del tráfico, sino del diseño.
- Resolución
- Se restauró la entrega cacheable desde CDN, se comprimieron respuestas con Brotli/gzip, se reemplazó la invalidación total por deltas y se precalculó en servidor la resolución de referencias.
- Qué vas a encontrar
- El PDF documenta el modelo de costo, el diagnóstico experimental, las intervenciones, la verificación con huella de enlaces y los resultados. Incluye límites y proyecciones, sin prometer una factura futura antes del ciclo posterior al despliegue.
01Cuando el costo no sigue al tráfico
Cuando el costo no sigue al tráfico
El punto de partida fue un ciclo de agosto de 2026 con USD 18,98 consumidos sobre un tope de USD 20. Los tres rubros atacados representaban el 78 % del total, pero el tráfico por sí solo no explicaba esa presión operativa.
El sistema atendía aproximadamente 46 visitas por hora mientras el backend recibía cerca de 1.600 solicitudes por hora. La diferencia reveló que páginas aparentemente estáticas se regeneraban y transferían datos mucho más de lo necesario.
02Diagnóstico por capas
Diagnóstico por capas
La jerarquía de caché impedía servir páginas desde CDN. Además, cada página incluía un diccionario completo de normas: en un caso llegó a 1.100 kB y representó el 94,6 % del HTML. Las actualizaciones invalidaban todo el sitio, y el backend entregaba respuestas sin compresión.
La resolución parcial de citas en el cliente sumaba descargas perezosas adicionales. Medir cada una de estas capas evitó tratar el costo como un síntoma único y permitió priorizar cambios que reducían trabajo repetido.
03Intervenciones sobre transferencia y trabajo
Intervenciones sobre transferencia y trabajo
La primera intervención restauró la cacheabilidad y la entrega desde CDN. Luego se negoció compresión Brotli/gzip y se eligió Brotli en calidad 5 como el punto de equilibrio entre reducción y CPU.
La invalidación total salió del protocolo y fue reemplazada por actualizaciones incrementales mediante deltas. Finalmente, la resolución de referencias pasó a precalcularse en servidor; el diccionario completo quedó como una carga perezosa para los casos que realmente lo requieren.
04Resultados y verificación
Resultados y verificación
En una muestra de doce páginas, el HTML bajó de 47.523 kB a 14.924 kB: 68,6 % menos. Una página de artículo pasó de 2.796 kB a 65 kB y la portada de 2.830 kB a 95 kB. El endpoint de navegación se redujo de 2.492.565 B a 7.147 B en crudo y a 2.520 B con Brotli.
La proyección de un rastreo completo cayó de aproximadamente 57 GB a 3 GB. Para detectar regresiones silenciosas, una huella de enlaces verifica la resolución de citas y conserva correctamente las autorreferencias. El paper distingue estos resultados medidos de la validación final de facturación, que corresponde al ciclo siguiente al despliegue.
Proyecto relacionado
Observatorio de Leyes ArgentinasEl contenido describe decisiones técnicas publicables. No incluye datos privados, credenciales ni detalles de seguridad explotables.
Para la gestión de normativa local, conocé FARO, digesto digital para municipios.
Descargar PDF