Infraestructura Web3 API

Cuando TradingView necesita datos blockchain para sus gráficos, cuando los usuarios de Osmosis revisan su portfolio, cuando CoinGecko actualiza precios de tokens: todo pasa por esta API. Montamos la capa de datos que conecta las transacciones y el estado de la blockchain con los productos que la gente realmente usa. Más de 10M de peticiones al día, p99 por debajo de 150ms, 99,99% de uptime en 18 meses. Esa clase de infraestructura que solo se nota cuando falla, y no ha fallado.

El problema real

Los nodos de blockchain podan 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 ya no existe on-chain. Los nodos conservan el estado actual y descartan el resto. Hasta las transacciones terminan desapareciendo de la mayoría de nodos.

Cuando alguien pide "muéstrame el valor de mi portfolio en USD con el cambio en 24h", no hay dónde consultarlo. Hay que capturar esos datos antes de que desaparezcan, indexarlos fuera de la cadena y calcularlos sobre la marcha: obtener balances de tokens, resolver precios cruzando múltiples DEXs, manejar tokens sin par directo a USD, todo en menos de 150ms.

Al principio, cada protocolo resolvía esto por su cuenta. Montaban sus propios feeds de precios, escribían indexadores a medida, gastaban tiempo de ingeniería en los mismos problemas de datos off-chain en vez de en su producto principal. La mayoría de esas soluciones no estaban probadas en momentos de alta volatilidad, que es justo cuando los usuarios más las necesitan. Nos especializamos en resolver ese problema, y ahora lo construimos a medida para cada cliente.

Por qué fue difícil

El estado de la blockchain cambia sin parar. No basta con consultar el "precio actual": hacen falta algoritmos propios que lo calculen a partir del estado de las pools en tiempo real. Suma más de 3.000 pools en una sola cadena grande, edge cases como baja liquidez o rutas circulares, y clientes que necesitan respuestas en milisegundos.

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

Aparte, cada cliente quería algo diferente. TradingView necesitaba datos OHLCV formateados para su motor de gráficos. 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 montar soluciones a medida para cada uno manteniendo una capa de datos compartida por debajo.

La arquitectura

Muchas piezas en movimiento, y cada una fue un proyecto en sí misma. Tres capas principales: un pipeline de ingesta que captura transacciones y estado de la blockchain antes de que los nodos los descarten, un motor de cálculo que transforma los datos indexados en las respuestas que los clientes necesitan, y una capa de fiabilidad que mantiene todo funcionando a escala.

Pipeline de ingesta

El reto fundamental es capturar el estado de la blockchain con la rapidez suficiente para que no se pierda nada, y almacenarlo de forma que permita consultas en tiempo real. Procesamos más de 1.500 bloques por minuto en más de 25 cadenas; cada bloque trae transacciones, cambios de estado y eventos que hay que parsear y guardar antes de que el nodo los descarte.

• 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 bruto no le sirven a ningún frontend. Nadie quiere parsear el estado de una pool y calcular el precio de un token a mano. No existían soluciones listas para nada de esto, así que montamos algoritmos propios que se interponen entre los datos crudos 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 con gestión de duplicados y valoración de tokens LP
• Snapshots históricos para proveedores de métricas y analíticas
• Cualquier cálculo personalizado que un cliente pueda necesitar

Haciéndolo fiable

Si esto se cae, los traders ven precios desfasados y las UIs se rompen. Servimos el frontend de protocolos donde se mueve dinero real cada segundo; la fiabilidad no es negociable. 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 migraron a nosotros tras comparar
• 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 operando esto me enseñaron que la fiabilidad a escala es, sobre todo, trabajo aburrido. Buen caching. Failover adecuado. Saber qué cálculos se pueden hacer en batch y cuáles exigen computación en tiempo real. Los algoritmos propios por los que todo el mundo pregunta representan quizá el 20% del trabajo. El otro 80% es infraestructura que simplemente sigue corriendo. A nadie le apasionan las estrategias de invalidación de caché, pero eso es lo que mantiene 10M de peticiones diarias fluyendo sin que nadie lo note.

El mayor acierto arquitectónico fue entender 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 la tratamos como una vista diferente sobre el mismo motor, 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 recién explotada: ahí es donde vive el trabajo real. 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, al final, un registro de cada cosa rara que hemos visto on-chain.

Tampoco se puede subestimar cuánto importó la monitorización. Rastreamos la latencia p99 por endpoint, por cliente, por cadena. Cuando redujimos los costes de base de datos un 70%, no fue una sola gran optimización: fueron cientos de pequeñas reescrituras de queries, cada una guiada por patrones reales de producción. La infraestructura de monitorización tardó casi tanto en construirse como la propia API, y se amortizó en el primer mes.