Infraestructura Web3 API

Cuando TradingView necesita datos de blockchain para sus gráficos, cuando los usuarios de Osmosis revisan su portfolio, cuando CoinGecko actualiza precios de tokens, pasa por esta API. Construimos la capa de datos que se sitúa entre las transacciones y el estado de la blockchain y los productos que la gente usa. Más de 10M de peticiones al día, p99 por debajo de 150ms, 99,99% de uptime durante 18 meses. El tipo de infraestructura que solo se nota cuando se rompe, y no se ha roto.

El problema real

Los nodos de blockchain eliminan el estado. Los balances de ayer, los precios de las pools de la semana pasada, la transacción que hiciste hace tres meses. La mayor parte de esos datos ya no existe on-chain. Los nodos mantienen el estado actual y descartan el resto. Incluso las transacciones acaban siendo eliminadas de la mayoría de nodos.

Así que cuando alguien pide "muéstrame el valor de mi portfolio en USD con el cambio en 24h", no hay dónde buscarlo. Esos datos hay que capturarlos antes de que desaparezcan, indexarlos fuera de la cadena, y luego calcularlos: obtener balances de tokens, resolver precios en múltiples DEXs, gestionar tokens sin par directo a USD, todo en menos de 150ms.

Cuando empezamos, cada protocolo estaba resolviendo esto por su cuenta. Construyendo sus propios feeds de precios, programando indexadores a medida, invirtiendo tiempo de ingeniería en los mismos problemas de datos off-chain en lugar de en su producto principal. La mayoría de esas soluciones no estaban probadas en periodos de alta volatilidad, que es justo cuando los usuarios más las necesitan. Nos especializamos en resolver este problema, y ahora lo construimos a medida para cada cliente.

Por qué fue difícil

El estado de la blockchain cambia constantemente. No puedes simplemente consultar el "precio actual". Necesitas algoritmos personalizados que lo calculen a partir del estado de las pools en tiempo real. Añade más de 3.000 pools en una sola cadena grande, casos extremos como baja liquidez o rutas circulares, y clientes que necesitan respuestas en milisegundos.

La parte más complicada es que la mayoría de respuestas útiles requieren mezclar estado actual de la cadena con datos históricos. Los cálculos de APR necesitan los balances actuales de las pools más semanas de eventos pasados de comisiones e incentivos. Las posiciones de liquidez concentrada necesitan el rango de tick actual más el historial de acumulación de comisiones para mostrar los retornos reales. El seguimiento de portfolio necesita balances en vivo pero también cada swap, stake y claim pasado para construir el historial de transacciones. Nada de esto está en un solo sitio, y las partes actuales e históricas vienen de sistemas completamente distintos.

Además, cada cliente quería algo diferente. TradingView necesitaba datos OHLCV formateados para plataforma. CoinMarketCap quería metadatos de tokens estandarizados. DexScreener necesitaba actualizaciones de pools en tiempo real. Osmosis requería seguimiento de portfolio con historial de transacciones. Tuvimos que construir soluciones a medida para cada uno manteniendo una capa de datos compartida por debajo.

La arquitectura

Muchas piezas en movimiento, y sinceramente cada una fue un proyecto en sí mismo. Tres capas principales: un pipeline de ingestion que captura las transacciones y el estado de la blockchain antes de que los nodos los eliminen, pipelines de datos que transforma los datos indexados en las respuestas que los clientes realmente necesitan, y una capa de fiabilidad que mantiene todo funcionando a escala.

Pipeline de ingestion

El reto fundamental es capturar el estado de la blockchain lo suficientemente rápido como para que no se pierda nada, y almacenarlo de forma que las consultas en tiempo real sean posibles. Procesamos más de 1.500 bloques por minuto en más de 25 cadenas, cada bloque con transacciones, cambios de estado y eventos que hay que parsear y almacenar antes de que el nodo los elimine.

• Nodos propios para captura fiable de datos de blockchain
• Pub/Sub para streaming de eventos con reintentos automáticos y dead-letter queues
• BigQuery y DBT para historial complejo no en tiempo real
• Cluster de ClickHouse para datos de series temporales en tiempo real
• PostgreSQL para estado de entidades en vivo: pools, tokens, validadores
• Despliegue multi-región en Cloudflare con caché dinámica compleja

Motor de cálculo personalizado

Los datos indexados en crudo no le sirven a un frontend. Nadie quiere parsear el estado de un pool y calcular el precio de un token por su cuenta. No existían soluciones listas para nada de esto, así que construimos algoritmos personalizados que se sitúan entre los datos en crudo y las respuestas del API:

• Pricing de tokens en más de 3.000 pools por cadena con resolución de rutas multi-hop
• Cálculos de APR/APY contabilizando incentivos, comisiones y compounding
• Balances históricos de usuario para seguimiento de portfolio
• Análisis de profundidad de liquidez para estimación de slippage
• Agregación de TVL gestionando duplicados y valoración de tokens
• Snapshots históricos para proveedores de métricas y analíticas
• Cualquier cálculo personalizado que un cliente pueda necesitar

Haciéndolo fiable

Cuando esto se cae, los traders ven precios obsoletos y las UIs se rompen. Servimos el frontend de protocolos donde se mueve dinero real cada segundo, así que la fiabilidad no es opcional. Las optimizaciones que nos llevaron al 99,99% de uptime:

• Caché inteligente que redujo latencia y coste 5x, sabiendo qué datos pueden estar obsoletos
• Optimización SQL que redujo los costes de base de datos en un 70%
• Protección DDoS para picos de más de 100K peticiones/seg
• Rate limiting por cliente con degradación gradual en lugar de fallos duros

Resultados

Tras 18 meses en producción:

• 99,99%+ de uptime, menos de 4 minutos de downtime al mes
• Más de 10M de peticiones diarias, latencia p99 por debajo de 150ms
• Más de 500K usuarios diarios en todas las plataformas integradas
• Más de $100M/día de volumen de trading fluyendo por estos endpoints
• Eficiencia de costes 5x frente a competidores. Cuatro protocolos han migrado con nosotros
• Cero incidentes de seguridad

Quién lo usa

Dos categorías de clientes con necesidades diferentes:

• Proveedores de datos: TradingView, CoinMarketCap, CoinGecko, DexScreener, DefiLlama, Token Terminal. Necesitan feeds estandarizados para charting y analíticas.
• Frontends de protocolos: Osmosis, Neutron, Xion, Quasar. Necesitan endpoints personalizados para seguimiento de portfolio, historial de transacciones y métricas DeFi.

También construimos un SDK para partners que redujo el tiempo de integración de semanas a horas. Antes, el onboarding era un proyecto de varias semanas. Ahora es una tarde.

Lo que aprendí

Dieciocho meses manteniendo esto me han enseñado que la fiabilidad viene sobre todo trabajo aburrido. Buen caching. Failover adecuado. Saber qué cálculos se pueden hacer en batch y cuáles necesitan computación en tiempo real. Los algoritmos personalizados por los que todo el mundo pregunta son el 20% del trabajo. El otro 80% es infraestructura que simplemente sigue funcionando. A nadie le entusiasman las estrategias de invalidación de caché, pero es lo que mantiene 10M de peticiones diarias fluyendo sin que nadie se dé cuenta.

La mayor victoria arquitectónica fue darnos cuenta de que cada cliente cree que su caso de uso es único, pero el modelo de datos por debajo no lo es. TradingView quiere velas OHLCV. CoinGecko quiere metadatos de tokens. Osmosis quiere valores de portfolio. Todos necesitan lo mismo: precios de tokens precisos calculados a partir del estado de las pools en tiempo real. Cuando dejamos de tratar cada integración como un proyecto a medida y empezamos a tratarla como una vista diferente sobre la misma base, el onboarding pasó de meses a semanas.

Si tuviese que señalar una cosa que define este sistema, son los edge cases. Calcular el precio de un token cuando hay un par limpio a USD es trivial. Calcularlo cuando necesitas enrutar a través de tres pools, una con $500 de liquidez y otra que acaba de ser explotada, ahí es donde vive el trabajo de verdad. Nuestro algoritmo de pricing gestiona miles de estos casos. Cada uno fue un incidente en producción que rompió algo para un usuario real. El algoritmo es básicamente un registro de cada cosa rara que hemos visto on-chain.

Tampoco se puede obviar lo mucho que importa la monitorización. Hacemos seguimiento de la latencia p99 por endpoint, por cliente, por cadena. Cuando redujimos los costes de base de datos en un 70%, no fue una gran optimización. Fueron cientos de pequeñas reescrituras de queries, cada una informada por observar patrones reales de producción. La infraestructura de monitorización tardó casi tanto en construirse como la propio API, y se amortizó en el primer mes.