Datos que cambian mientras los mirás
El problema
Hay información que pierde todo su valor si llega tarde. Una noche de elecciones, el lector quiere ver el escrutinio moverse. Quien sigue el dólar quiere la cotización de ahora, no la del cierre de ayer.
Publicar eso como una nota estática no funciona: habría que reescribirla cada cinco minutos.
Qué construí
Dos sistemas con la misma arquitectura de fondo:
- Elecciones 2025 — resultados del escrutinio, tomados de la API oficial.
- Mercados — cotizaciones desde varias fuentes: Finnhub, la Bolsa de Comercio de Rosario y Yahoo Finance.
En los dos casos la estructura es la misma: un Worker Service de .NET que sondea las fuentes de forma programada y guarda lo que recibe, una API propia que sirve esos datos ya procesados, y widgets de React que se embeben en cualquier nota y se actualizan solos.
Cómo viaja el dato
- Origen Fuente API oficial o mercado. Se sondea de forma programada; el sistema no depende de que esté disponible en el momento de la visita.
- Persistencia Base propia Cada lectura se guarda procesada. Es lo que permite responder rápido y no depender de la latencia de la fuente.
- Exposición API propia El frontend nunca habla con la fuente original, sólo con esta capa.
- Consumo Widget Componentes React embebibles que se actualizan solos dentro de cualquier nota.
Vista ilustrativa · el mapa del escrutinio
Lista ALista BLista COtras
Resultados · país
- Lista A34,21 %
- Lista B28,74 %
- Lista C19,05 %
- Otras18,00 %
Del país al municipio, en dos clics
Vista ilustrativa · bancas y mercados
Las decisiones que costaron
El worker va aparte de la API. Recolectar y servir son dos trabajos con ritmos distintos: uno corre según un cronograma y puede tardar o fallar, el otro tiene que responder ya. Separarlos en dos servicios significa que un sondeo lento nunca se lleva puesta la respuesta a un lector.
Base propia, no proxy a la fuente. Lo fácil es reenviar la consulta a la fuente oficial cuando alguien abre la nota. Guardar cada lectura en base propia cuesta más espacio, y a cambio da dos cosas: respuestas rápidas y desacople del servicio oficial — dejás de depender de su latencia y de que aguante tu tráfico.
Si la fuente no responde, se sirve el último dato guardado. Es la consecuencia directa de la decisión anterior, y es la que se nota. Una noche de elecciones, cuando la API oficial se pone lenta o se cae, el widget no muestra un error: muestra el último resultado bueno que llegó. El lector ve un dato viejo por unos minutos en lugar de una pantalla rota.
Resultado
Ambos sistemas salieron a producción y funcionaron en sus ventanas críticas. Los widgets se siguen usando.