--- title: "Cero downtime, cero gaps: cómo construimos streaming gRPC de Solana tolerante a fallos" description: "Redundancia multi-nodo, ingestión de shreds y Richat — cómo diseñamos el streaming gRPC de Solana para equipos que no pueden permitirse gaps ni spikes." --- # Cero downtime, cero gaps: cómo construimos streaming gRPC de Solana tolerante a fallos Para los equipos que construyen infraestructura de trading, buscadores de MEV, bots de liquidación e indexadores en tiempo real, sus productos son tan rápidos como los datos que los alimentan. Un stream con picos o caídas significa una operación perdida o un índice incompleto. Por eso construimos nuestro [producto de streaming gRPC para Solana](https://www.alchemy.com/solana-grpc) sobre una capa de redundancia multi-nodo, de modo que los picos y las caídas se absorban antes de llegar a tu pipeline, y no tengas que construir lógica de failover sobre un servicio que se supone que ya está administrado. Así fue como lo diseñamos. ## Por qué gRPC importa en Solana El volumen de datos de Solana es enorme: más de 4 petabytes al año en momentos de máxima velocidad. El polling tradicional sobre JSON-RPC introduce una sobrecarga innecesaria: solicitudes repetidas, ancho de banda desperdiciado y latencia inherente al ciclo de solicitud-respuesta. Para cargas de trabajo que necesitan cada actualización de cuenta o transacción en el momento en que se confirma, el polling no es suficiente. El streaming gRPC sobre Protobuf/HTTP2 invierte el modelo. El servidor envía los datos al cliente a medida que se producen. Los builders se suscriben exactamente a los datos que necesitan —cuentas específicas, programas, patrones de transacciones— y reciben un stream continuo y filtrado sin latencia de polling. Para Solana, donde los tiempos de bloque son sub-segundo y el volumen de datos es enorme, esta es la solución ideal para apps que priorizan entregar los datos más actuales a los usuarios. La interfaz Yellowstone gRPC se ha convertido en el estándar de facto para el streaming de Solana. Los builders ya cuentan con librerías cliente en Rust, TypeScript, Go, y en cualquier lenguaje que compile un archivo `.proto`. Aprovechamos ese estándar, así que migrar desde cualquier proveedor compatible con Yellowstone es un cambio de URL, no una reescritura. ## La arquitectura: de shreds a streams Nuestro pipeline de streaming tiene cuatro capas, cada una diseñada con redundancia incorporada para un rendimiento confiable a escala. ### Ingesta de shreds Los shreds son la unidad fundamental de propagación de datos en Solana: frames del tamaño de la MTU (~1,280 bytes) que contienen fragmentos de entradas de bloque. La red distribuye los shreds mediante Turbine, un protocolo multi-hop donde los validadores retransmiten datos a través de vecindarios en capas. Turbine es rápido, pero es probabilístico. La pérdida de paquetes se acumula a través de los saltos, y un nodo ubicado en una posición profunda del árbol puede esperar cientos de milisegundos para la reparación de brechas antes de ensamblar un bloque completo. Ingerimos shreds desde múltiples fuentes independientes de forma simultánea —incluyendo servicios que recolectan shreds directamente desde validadores de alto stake, evitando la latencia multi-hop de Turbine. Cada fuente cubre diferentes rutas geográficas y vecindarios de validadores. Las brechas en un stream se completan con otro, lo que significa un ensamblaje de bloques más rápido con menos ciclos de reparación. Esto importa porque un nodo necesita un número mínimo de shreds para ensamblar cada slot. Si no recibe suficientes en aproximadamente 250ms, recurre al protocolo de reparación, solicitando los shreds faltantes a sus pares, lo cual agrega una latencia considerable. Obtener suficientes shreds antes de que se active la reparación es crítico. Por eso ingerimos desde múltiples fuentes independientes: más cobertura significa que el nodo alcanza ese umbral más rápido, ensambla las entradas antes, y dispara las notificaciones de Geyser más temprano. Cada milisegundo ahorrado aquí se propaga en cascada hacia el resto del pipeline. ### El motor Richat En el núcleo de nuestro servicio de streaming está Richat, un motor de código abierto que se ejecuta como un plugin de Geyser en el nodo de Solana. Captura actualizaciones de cuentas, notificaciones de transacciones, estado de slots, metadata de bloques y actualizaciones de entradas a medida que son producidas por el cliente Agave, y luego las transmite a un servidor Richat que actúa como capa de agregación y fan-out. La decisión de diseño clave: cada servidor Richat se conecta simultáneamente a múltiples nodos de Solana upstream. Deduplica las actualizaciones entre las distintas fuentes y entrega el resultado saludable más rápido hacia el consumidor. Cuando un nodo upstream se retrasa en un slot, la capa de agregación entrega los datos desde el siguiente nodo más rápido. Esto es lo que nos da la atenuación de picos de latencia. Los despliegues de un solo nodo tienen una cola larga en la latencia p99 y p999, porque cada mal momento en el nodo upstream se propaga a cada consumidor. La agregación multi-nodo aplana esa cola: el stream del builder refleja al nodo con mejor rendimiento en cada momento, no al único disponible. ### El stream del builder Los builders se conectan con las librerías cliente estándar de Yellowstone. Una vez conectados, pueden suscribirse a actualizaciones de cuentas (con filtros de programa, owner y data-slice), actualizaciones de transacciones (con filtros de account-include/exclude y firma), y actualizaciones de slot, block, block-meta y entry. Los niveles de commitment (`processed`, `confirmed`, `finalized`), la compresión Zstd y el keepalive del lado del servidor se soportan de forma nativa. Se pueden componer múltiples suscripciones concurrentes con semántica AND/OR en una sola conexión. El streaming bidireccional permite a los builders suscribirse, modificar y cancelar sin necesidad de reconectar. ### Replay al reconectar Las desconexiones breves y los reinicios del cliente son inevitables. La pregunta es si le cuestan datos al builder. Almacenamos una ventana móvil de actualizaciones recientes en el ring buffer de Richat. Cuando un cliente se reconecta, puede suscribirse con un parámetro `from_slot` y recuperar todo lo que se perdió antes de retomar el stream en vivo. Sin un pipeline de backfill separado. Sin lógica de detección de brechas que mantener. Sin un servicio de reconciliación corriendo junto al consumidor. Este es un modelo operativo más simple para los builders que necesitan streams sin brechas durante horizontes de tiempo largos: indexadores, plataformas de analítica, y cualquiera que ejecute un consumidor con estado que no pueda permitirse perder una actualización. ## Qué sigue La arquitectura actual es la base, no el límite. Estamos trabajando activamente en: **Ventana de replay extendida.** Ampliar significativamente la ventana de backfill al reconectar, para los builders que necesitan una cobertura de recuperación más larga. **Optimizaciones de hardware y red.** Mejoras continuas de infraestructura para reducir la latencia a lo largo de la ruta crítica. **Regiones adicionales.** Ampliar la cobertura para acercar los streams a más builders y más validadores. **Despliegues dedicados.** Para el pequeño número de equipos donde la colocación y el aislamiento son requisitos, no preferencias. ## Cómo empezar [Alchemy Solana gRPC](https://www.alchemy.com/solana-grpc) está disponible hoy en todos los planes pagos desde $75/TB, sin restricción de plan y sin mínimo mensual. Si ya estás ejecutando un cliente Yellowstone, la migración es solo un cambio de URL. - [Lee la documentación](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart) - [Habla con nuestro equipo](https://www.alchemy.com/contact-sales) - [Postula al Fondo de $20M para Solana](https://www.alchemy.com/solana-20m-fund) para obtener hasta $25k en créditos y acelerar tu app en Solana.