Cómo llevé Swapstracker de una estimación de un año con mi primera versión en TypeScript a una sincronización de 20 días con una reescritura en Go y TimescaleDB en una Radxa ROCK 5C.
Swapstracker sigue el trading en DEX de cadenas EVM. Lee eventos de swap de pools estilo Uniswap V2, V3 y V4, calcula el precio en USD de cada trade y sirve trades, estadísticas de pares y velas OHLCV mediante una API. Los trades nuevos llegan en vivo a un frontend SvelteKit.
Este texto cubre dos cadenas, Ethereum y BSC, con dos años de histórico.
La plataforma admite más cadenas EVM. Todas las cifras de esta página se refieren solo a Ethereum y BSC.
Escribí la primera versión de Swapstracker como un conjunto de microservicios TypeScript que escribían en MongoDB. Cada servicio tenía sentido por separado. Juntos gastaban buena parte de la CPU y la memoria convirtiendo objetos en mensajes y mensajes otra vez en objetos, solo para pasar los datos al siguiente servicio.
Mido el avance en bloques por segundo, registrados de forma continua. Al ritmo que sostenía mi primera versión, los logs proyectaban alrededor de un año para sincronizar dos años de ambas cadenas. Esa cifra es una proyección: no dejé correr la primera versión un año para confirmarla.
No es un resultado de Go contra TypeScript. Cambiaron a la vez la arquitectura, el acceso a datos y el almacenamiento.
El indexador es un proceso; la plataforma no. La API, Redis, la base de datos y el frontend corren como servicios propios.
Dentro del indexador, un asignador reparte rangos de bloques consecutivos, con el tamaño que decide el optimizador de lotes. Varios workers toman rangos a la vez. Cada uno descarga sus logs y después resuelve en paralelo los metadatos de los pares y los timestamps de los bloques, mirando la caché local antes de preguntar a la red.
Los workers terminan en el orden que permite la red, así que sus lotes pasan por un buffer de reordenamiento. Un único committer calcula precios y los escribe estrictamente en orden de bloques, de modo que el histórico crece sin huecos aunque la extracción corra en paralelo.
Un número fijo de lotes en vuelo limita cuántos lotes preparados pueden esperar a la vez. Si un rango va lento, los demás workers dejan de tomar trabajo nuevo en lugar de llenar la memoria.
El número de workers se ajusta en ejecución. El orden no depende de él: solo el committer escribe.
Una ilustración del diseño, hecha con un modelo de imágenes a partir de mi descripción del indexador. No es una captura.
Con esos cambios, la sincronización de dos años de ambas cadenas terminó en 20 días. El histórico guarda ahora más de 3.100 millones de trades en cerca de 1 TB comprimido, y el indexador usa alrededor de un 80% menos de RAM que mi primera versión.
También vi bajar la temperatura de la CPU unos 15 °C. La temperatura depende de la carga y del ambiente, así que la dejo como observación, no como resultado.
| más de 3.100 millones | de trades guardados, dos años de Ethereum y BSC | observado |
|---|---|---|
| 1 TB | de histórico comprimido, en un SSD de 2 TB | observado |
| 20 días | para sincronizar esos dos años, ambas cadenas juntas | observado |
| ≈ 1 año | lo que proyectaba mi primera versión para el mismo trabajo | estimación a partir de bloques/s registrados |
| 80% menos | RAM después de la reescritura | reportado, aún sin benchmark reproducible |
Todo esto corre en una computadora de placa única Radxa ROCK 5C con un SSD Samsung T7 de 2 TB conectado por USB. El histórico comprimido ocupa cerca de la mitad de ese disco. La misma placa sirve también HabitsFlow y GroupBrain, y las tres apps llegan a internet mediante Cloudflare Tunnel.
La placa no ejecuta nodos EVM completos. Los datos de las cadenas vienen de proveedores RPC; el trabajo del indexador es sacar el máximo de cada petición y hacer el resto en local.
singleflight de Go. Agrupa lecturas en curso; no deduplica trades
guardados.Digo que la latencia OHLCV es baja. Aún no he publicado un p95, así que aquí no hay cifra en milisegundos.
Los endpoints RPC públicos varían mucho. Algunos no guardan histórico antiguo, otros agotan el tiempo, otros devuelven logs incompletos. El indexador hace failover entre proveedores, y los endpoints candidatos se comparan con baselines, resultados conocidos para rangos de bloques fijos, antes de confiar en ellos.
El cálculo de precios es matemática en memoria sobre el estado de los pools. El RPC hace falta para logs, metadatos de tokens y timestamps de bloques, y estos dos últimos se cachean en local. El tamaño de los lotes se adapta a la densidad de logs: el optimizador apunta a unos 35.000 logs por lote y reduce cuando un proveedor tiene problemas.
35.000 es un objetivo de tamaño de lote, no una cifra de rendimiento ni un límite fijo.
Las cifras de arriba salen de mis propios logs. Para que otro ingeniero pueda reproducirlas, esto es lo siguiente:
Llegarán a esta página, con el método, cuando los tenga.