El 99,2 % del consumo no era demanda de usuario
Un día Isobaria agotó la cuota de sus proveedores de datos. Repartir el gasto por quién lo causó mostró que las personas eran el 0,8 %. Qué cambiamos, qué descartamos y por qué no pagar un plan era la respuesta equivocada.
El 20 de agosto, a las 06:00 UTC, Isobaria llevaba el 101 % de su presupuesto diario de Open-Meteo y el 100 % del de AEMET. El freno de llamadas, que ya existía, hizo lo que tenía que hacer: degradó y no se cayó nada. Pero un freno que funciona no responde a la pregunta incómoda: ¿quién se ha gastado esto?
Hasta entonces el presupuesto era uno solo por proveedor. Un número que sube. Y un número que sube no distingue entre una persona mirando la previsión de su pueblo y un proceso que lleva toda la noche pidiendo páginas que nadie va a leer.
Repartir el gasto por quién lo causó
Lo que hicimos fue cambiar la pregunta. En vez de "cuánto llevamos", "quién lo ha pedido". Tres clases: personas, rastreadores y trabajos programados. Con el consumo real de aquel día, para Open-Meteo:
| Quién | Llamadas al día | Proporción |
|---|---|---|
| Rastreadores | ~4.161 | 59 % |
| Trabajos programados | 2.932 | 41 % |
| Personas | ~60 | 0,8 % |
Hay que leerlo despacio: el 99,2 % de lo que gastábamos no lo había pedido ninguna persona. No era un matiz de calibración. Era el planteamiento entero.
Y conviene ser honestos con el 0,8 %, porque es una medida y las medidas tienen letra pequeña. Las ~60 llamadas salen de unas 15 fichas vistas al día, que es la media de los días en que la telemetría pudo escribir. Contando todos los días de dos semanas son 5,4. La diferencia es que varios días de esas dos semanas salen a cero porque la cuota del almacén clave-valor donde guardamos la analítica también estaba agotada y no se pudo escribir. La medición de la demanda sufría el mismo problema que intentaba medir. Con 15 o con 5,4 la conclusión es la misma, y por eso las dos cifras quedan escritas en el documento.
El caso extremo
El ejemplo que más enseña es el del mapa de confianza. Su tarea programada gastaba 2.676 llamadas al día. En catorce días la pantalla tuvo 5 visitas.
37.464 llamadas / 5 visitas = 7.493 llamadas por visita
El mapa no estaba mal hecho. Su cadencia se había fijado por la física del dato: los modelos publican cada seis horas, así que se recalculaba cuatro veces al día. Nadie había comprobado nunca si alguien lo estaba mirando. Es una forma muy natural de equivocarse: el ritmo lo marca lo que la fuente permite, no lo que el producto necesita.
La solución que parecía obvia y se descartó con aritmética
Ya existía un ticket para esto: precalcular todas las celdas pobladas en cada ciclo de los modelos, de modo que ninguna visita tuviera que esperar ni pagar. Suena a lo responsable. Y es lo que habríamos hecho sin hacer la cuenta:
748 celdas × 3 modelos × 4 ciclos = 8.976 puntos al día, haya visitas o no
Frente a una demanda de unas 60 llamadas, eso es fijar el coste en unas 150 veces lo que se pide. Cambia un desperdicio variable por uno fijo y lo llama solución.
El ticket no estaba mal. Estaba a destiempo. El documento que lo sustituye calcula además el punto de equilibrio: precalcular sale a cuenta a partir de 2.244 fichas frías al día (8.976 entre las 4 llamadas que cuesta una ficha). Hoy hay 5,4. El ticket no se cierra: se aplaza con ese número escrito como disparador. Cuando el tráfico lo cruce, se implementa sin volver a discutirlo.
Qué se decidió
El presupuesto se parte por clase, y cada consumidor que no sea una persona tiene que justificar su parte con uso medido:
- Las personas no tienen cuota propia. Su techo es el del proveedor. Si algún día las personas agotan la cuota, es un problema bueno y se resuelve pagando un plan, no degradando.
- El rastreo es una inversión elegida, no descubierta. Cuota propia de 200 peticiones de ficha al día (unas 800 llamadas), que indexa el catálogo entero en unas seis semanas. Al agotarla, la respuesta es un 503 aunque el presupuesto global vaya al 20 %.
- Cada tarea programada justifica su cadencia con su uso, no con la publicación del modelo. La rejilla del mapa pasa de cuatro pasadas diarias a una: de 2.676 llamadas a 669.
| Consumidor | Antes | Después |
|---|---|---|
| Rejilla del mapa | 2.676 | 669 |
| Precalentado | 256 | 256 |
| Rastreadores | ~4.161 | ≤ 800 |
| Personas | ~60 | ~60 |
| Total | ~7.093 | ~1.785 |
El total es el 25,5 % del presupuesto; queda libre el 74,5 %. Y la proporción de gasto útil sube del 0,8 % al 3,4 %, que sigue siendo poco porque el tráfico es poco. La diferencia es que ahora el resto está acotado y elegido por alguien.
Lo que se descartó, y por qué
Bloquear a los rastreadores de la cola larga. Contradecía una decisión ya documentada: el sitemap argumenta que las páginas de los municipios pequeños son rastreables a propósito. Renunciar a esa cola para ahorrar cuota es vender el activo para pagar el alquiler.
Pagar un plan de Open-Meteo. Resuelve el síntoma, y se descarta como primer paso, no para siempre. Pagar sin arreglar el reparto es comprar más cuota para seguir gastando el 99 % en algo que nadie pidió. Cuando las personas sean el consumidor principal, subir de plan será una decisión de crecimiento y no un parche.
Seguir con el presupuesto global. El argumento está en el propio ADR: no distingue quién gasta, así que el último en llegar paga el plato roto. El 20 de agosto, quien llegó tarde fueron las personas.
Lo que cuesta, y lo que sigue sin resolverse
La cola larga tarda semanas en indexarse, no días. Es el precio explícito de la cuota de rastreo, y es reversible subiéndola. El mapa de confianza puede envejecer hasta 24 horas, y la pantalla tiene que decirlo, porque un mapa viejo sin avisar es justo lo que el producto se prohíbe.
El contador es más complejo: tres clases donde había una, y una clasificación que no es infalible. Por eso el techo global sigue detrás, como red: el reparto por clases ordena el gasto, no es el freno de emergencia.
Y hay una limitación que el ADR deja escrita porque la descubrimos al implementarla. Para saber si una página la pidió una persona o un rastreador habría que leer las cabeceras de la petición dentro de la propia página, y en esta versión de Next.js eso la convierte en dinámica: dejaría de cachearse, que es justo lo que sostiene su coste. Cambiaríamos un gasto por otro peor. Así que las páginas cuentan como "persona" a sabiendas, y la atribución de ese tráfico se resuelve en otro sitio. Una cifra que sabes que sobrestima a las personas y que dejas escrita así es mejor que una exacta que cuesta más de lo que mide.
Y una advertencia sobre las cifras de la tabla de arriba: son las de diseño, no una medición de después. El criterio de aceptación que pide una semana medida, con la proporción de personas por encima del 1 % y el consumo total por debajo de 7.000, está en el documento como casilla sin marcar. La señal que revisa la decisión también está escrita: si las personas pasan a ser más del 50 % del consumo, el reparto por clases deja de hacer falta.
Lo que nos llevamos
Un contador total te dice cuánto, no a quién. Hasta repartir el gasto por quién lo causó, el problema parecía de umbrales: ajustar el 80 %, el 100 %. No lo era. Ningún umbral arregla que el 99 % del consumo sea de algo que nadie pidió.
La cadencia de un proceso programado hay que justificarla con su uso, no con la física del dato. Que la fuente publique cada seis horas dice cuánto puedes refrescar, no cuánto te conviene. El mapa que costaba 7.493 llamadas por visita es lo que pasa cuando nadie pone el segundo número.
Un aplazamiento sin disparador es olvidar con buena letra. Precalcular por celda no se descartó: se aplazó con una cifra, 2.244 fichas frías al día. Es una pregunta que se contesta mirando un panel, no discutiendo otra vez.
Si tu producto consume una API de terceros con cuota y no sabes qué parte de ese consumo es de usuarios de verdad, escríbeme: suele ser una tarde de medir, y casi nunca sale lo que esperabas.