El 2 de septiembre de 2026 la Unidad Fija de la Ciudad de Buenos Aires pasó de $949,99 a $1.173,08. Un 23,5% de una sola vez. El día anterior, la Provincia de Buenos Aires había movido la suya un 0,44%.
Los dos valores miden lo mismo: el precio de la nafta de mayor octanaje. Los dos definen cuánto sale una multa de tránsito. Y sin embargo uno saltó cincuenta veces más que el otro.
La diferencia no es económica, es de calendario. Y si te tocó alguna vez sincronizar un valor oficial que publica un tercero, ahí hay una trampa que vale la pena mirar de cerca.
Los dos relojes
- Provincia de Buenos Aires: la UF equivale a un litro de nafta premium y se ajusta cada dos meses. Sus últimos saltos: +2,53% en julio, +0,44% en septiembre.
- CABA: la UF equivale a medio litro y la fija el Instituto de Estadística de la Ciudad cada seis meses (Ley 451, art. 20). Sus últimos saltos: +19,0% en marzo, +23,5% en septiembre.
Misma variable de fondo, misma inflación, resultados completamente distintos en la pantalla. Uno reparte el aumento en pedacitos, el otro lo acumula y lo suelta entero.
Por qué esto importa si lo tenés cacheado
Acá está el punto que me interesa.
Supongamos que guardás los dos valores con la misma política. Un TTL de seis horas, un scraper diario, un fallback al último valor conocido si la fuente no responde. Suena razonable y es lo que casi todos hacemos.
El problema es que el costo de servir un dato viejo no es el mismo para los dos.
Si tu copia de la UF bonaerense se queda vieja un bimestre entero, mostrás un número con un 0,44% de error. Nadie se entera, y si se entera no le cambia la decisión.
Si tu copia de la UF porteña se queda vieja un solo día, el 2 de septiembre, mostrás un número con un 23,5% de error. Sobre la multa más cara de la Ciudad eso son $892.360 de diferencia en una sola acta.
Mismo sistema, misma política de caché, mismo tipo de dato. Dos órdenes de magnitud de diferencia en el daño.
La conclusión es incómoda para el instinto de ingeniería, que tiende a tratar uniforme lo que tiene la misma forma:
La frecuencia de actualización de un valor y su volatilidad por actualización están inversamente correlacionadas. Cuanto menos seguido cambia algo, más grande es el salto cuando cambia. Así que "cambia poco" no significa "es seguro cachearlo": puede significar exactamente lo contrario.
Lo que cambia en la práctica
Lo que sacamos de esto no fue bajar el TTL a todo, que es la respuesta perezosa y encima te tira la fuente abajo a pedradas.
Fue empezar a guardar la ventana de validez junto con el valor.
El dato oficial de CABA no viene solo. Viene con las fechas: rige del 2 de septiembre de 2026 al 1 de marzo de 2027. Esa segunda fecha es tan dato como el número, y es la que convierte una pregunta difícil en una comparación trivial.
// Antes: "¿estará viejo?" es una corazonada.
const uf = await cache.get('uf:caba');
// Después: la propia fuente te dice hasta cuándo vale.
const uf = await cache.get('uf:caba'); // { valor, desde, hasta }
if (uf && Date.now() > Date.parse(uf.hasta)) {
// no adivines: sabés que caducó
await revalidar('caba');
}
Con eso, el 2 de septiembre no dependés de que el scraper haya corrido a tiempo ni de que alguien se acuerde: el valor guardado se declara vencido solo. Y lo mismo aplica a un valor bimestral, salvo que ahí la ventana es más corta y el riesgo de equivocarse, mucho menor.
El corolario práctico, para cualquier dato oficial de este tipo (una tasa, un índice, un valor de referencia legal): si la fuente publica una fecha de vigencia, guardala. Es la diferencia entre revalidar por reloj y revalidar por contrato.
La otra mitad: qué hacés cuando sí caducó
Que el sistema sepa que el dato venció no significa que pueda conseguir el nuevo. La fuente puede no haberlo publicado todavía, o estar caída, o cambiar el HTML justo ese día.
Ahí el orden de preferencia que nos quedó es:
- Valor vivo validado. Si responde y pasa las validaciones (que sea un número, que sea positivo, que no se haya movido un 900% de golpe), ese.
- Último valor conocido, marcado como vencido. Se sigue mostrando, porque un número de hace un semestre es infinitamente más útil que un guion, pero el sistema sabe que está en deuda y lo reintenta.
- Nunca un vacío.
Y una validación que suena paranoica hasta que la necesitás: acotar el salto. Un ajuste del 23,5% es real y tiene que pasar. Uno del 2.300% es un scraper leyendo mal un separador de miles. La diferencia entre los dos es un if, y de un lado de ese if está publicar montos equivocados en una página que la gente usa para decidir si paga una multa.
Datos, por si llegaste buscando el número
| Valor de 1 UF | Cada cuánto se ajusta | Último salto | |
|---|---|---|---|
| CABA | $1.173,08 (2-sep-2026 al 1-mar-2027) | Semestral | +23,5% |
| Provincia de Buenos Aires | $2.281 (septiembre-octubre 2026) | Bimestral | +0,44% |
Un detalle lindo que salió de mirar los dos juntos: como la UF porteña es medio litro y la bonaerense un litro, la primera debería rondar la mitad de la segunda. Antes del ajuste estaba en el 41,6% de la de Provincia, o sea atrasada. Después quedó en el 51,4%. El salto del 23,5% no fue un aumento por encima de la inflación: fue ponerse al día de golpe.
- El desglose con los montos por infracción está en el aumento de multas en CABA, y el de Provincia en su propia nota.
- Si querés el concepto desde cero, qué es la Unidad Fija lo explica con el histórico de las dos jurisdicciones.
- Todo esto sale de Multita, que consulta infracciones en 32 jurisdicciones argentinas. Si lo tuyo es integrarlo, la API las devuelve en JSON con cada acta ya convertida a pesos al valor de UF vigente de su jurisdicción, que es precisamente el problema de este post resuelto del lado del servidor.
Si tenés un valor oficial cacheado en algún lado, andá a fijarte si guardás su fecha de vencimiento. Si no la guardás, tu sistema no sabe que el dato venció: se está enterando cuando alguien se queja.
