--- title: "Zero downtime, zero gaps: como construímos o streaming gRPC fault-tolerant para Solana" description: "Redundância multi-node, ingestão de shreds e Richat — como arquitetamos o streaming gRPC para Solana para times que não podem ter gaps ou picos." --- # Zero downtime, zero gaps: como construímos o streaming gRPC fault-tolerant para Solana Para equipes que constroem infraestrutura de trading, MEV searchers, bots de liquidação e indexadores em tempo real, seus produtos só são tão rápidos quanto os dados que os alimentam. Um stream que oscila ou cai significa um trade perdido ou um índice incompleto. Por isso construímos nosso [produto de streaming gRPC para Solana](https://www.alchemy.com/solana-grpc) sobre uma camada de redundância multi-node, para que picos e quedas sejam absorvidos antes de chegar ao seu pipeline, e você não precise construir lógica de failover em cima de um serviço que deveria ser gerenciado. Foi assim que arquitetamos isso. ## Por que gRPC importa na Solana O volume de dados da Solana é enorme: mais de 4 petabytes por ano em picos de velocidade. O polling tradicional via JSON-RPC introduz overhead desnecessário: requisições repetidas, banda desperdiçada e latência inerente ao ciclo de request-response. Para workloads que precisam de cada atualização de conta ou transação no momento em que é confirmada, polling não resolve. O streaming gRPC sobre Protobuf/HTTP2 inverte o modelo. O servidor envia os dados ao cliente assim que são produzidos. Os builders se inscrevem exatamente nos dados de que precisam — contas específicas, programas, padrões de transação — e recebem um stream contínuo e filtrado, sem latência de polling. Para a Solana, onde os tempos de bloco são sub-segundo e o volume de dados é enorme, essa é a solução ideal para apps que priorizam entregar aos usuários os dados mais atuais. A interface gRPC Yellowstone se tornou o padrão de fato para streaming na Solana. Os builders já têm bibliotecas cliente em Rust, TypeScript, Go, e em qualquer linguagem que compile um arquivo `.proto`. Aproveitamos esse padrão, então a migração de qualquer provedor compatível com Yellowstone é uma mudança de URL, não uma reescrita. ## A arquitetura: de shreds a streams Nosso pipeline de streaming tem quatro camadas, cada uma projetada com redundância embutida para performance confiável em escala. ### Ingestão de shreds Shreds são a unidade fundamental de propagação de dados na Solana — frames do tamanho do MTU (~1.280 bytes) contendo fragmentos de entries de bloco. A rede transmite shreds via Turbine, um protocolo multi-hop onde validadores repassam dados através de vizinhanças em camadas. O Turbine é rápido, mas probabilístico. A perda de pacotes se acumula ao longo dos hops, e um node no fundo da árvore pode esperar centenas de milissegundos por reparo de gaps antes de montar um bloco completo. Ingerimos shreds de múltiplas fontes independentes simultaneamente — incluindo serviços que coletam shreds diretamente de validadores de alto stake, contornando a latência multi-hop do Turbine. Cada fonte cobre caminhos geográficos e vizinhanças de validadores diferentes. Gaps em um stream são preenchidos por outro, o que significa montagem de blocos mais rápida com menos ciclos de reparo. Isso importa porque um node precisa de um número mínimo de shreds para montar cada slot. Se não recebe o suficiente em cerca de 250ms, ele recorre ao protocolo de reparo — solicitando shreds faltantes a peers, o que adiciona latência significativa. Obter shreds suficientes antes que o reparo entre em ação é crítico. É por isso que ingerimos de múltiplas fontes independentes: mais cobertura significa que o node atinge esse limiar mais rápido, monta entries mais cedo e dispara notificações Geyser mais cedo. Cada milissegundo economizado aqui se propaga adiante. ### O engine Richat No núcleo do nosso serviço de streaming está o Richat, um engine open-source que roda como um plugin Geyser no node Solana. Ele captura atualizações de conta, notificações de transação, status de slot, metadados de bloco e atualizações de entry conforme são produzidas pelo cliente Agave, e então as transmite para um servidor Richat que atua como camada de agregação e distribuição. A decisão de design chave: cada servidor Richat se conecta a múltiplos nodes Solana upstream simultaneamente. Ele deduplica atualizações entre fontes e entrega o resultado saudável mais rápido a jusante. Quando um node upstream fica atrasado em um slot, a camada de agregação serve dados do próximo node mais rápido. É isso que nos dá atenuação de picos de latência. Deployments de node único têm uma cauda longa na latência p99 e p999, porque cada momento ruim no node upstream passa para todos os consumidores. A agregação multi-node achata essa cauda — o stream do builder reflete o node com melhor desempenho a cada momento, não o único disponível. ### O stream do builder Os builders se conectam com bibliotecas cliente Yellowstone padrão. Uma vez conectados, podem se inscrever em atualizações de conta (com filtros de program, owner e data-slice), atualizações de transação (com filtros de account-include/exclude e signature), e atualizações de slot, block, block-meta e entry. Níveis de commitment (`processed`, `confirmed`, `finalized`), compressão Zstd e keepalive do lado do servidor são todos suportados nativamente. Múltiplas assinaturas concorrentes podem ser compostas com semântica AND/OR em uma única conexão. O streaming bidirecional permite que builders se inscrevam, modifiquem e cancelem sem precisar reconectar. ### Replay na reconexão Desconexões breves e reinicializações de cliente são inevitáveis. A questão é se elas custam dados ao builder. Armazenamos uma janela móvel de atualizações recentes no ring buffer do Richat. Quando um cliente reconecta, ele pode se inscrever com um parâmetro `from_slot` e recuperar tudo que perdeu antes de retomar o stream ao vivo. Sem pipeline de backfill separado. Sem lógica de detecção de gaps para manter. Sem serviço de reconciliação rodando junto ao consumidor. Esse é um modelo operacional mais simples para builders que precisam de streams sem gaps ao longo de horizontes de tempo longos — indexadores, plataformas de analytics e qualquer consumidor stateful que não pode arcar com a perda de uma atualização. ## O que vem a seguir A arquitetura atual é a fundação, não o teto. Estamos trabalhando ativamente em: **Janela de replay estendida.** Aumentar significativamente a janela de backfill na reconexão para builders que precisam de cobertura de recuperação mais longa. **Otimizações de hardware e rede.** Melhorias contínuas de infraestrutura para reduzir a latência ao longo do caminho crítico. **Regiões adicionais.** Expandir a cobertura para aproximar os streams de mais builders e mais validadores. **Deployments dedicados.** Para o pequeno número de equipes para as quais co-location e isolamento são requisitos, não preferências. ## Comece agora O [Alchemy Solana gRPC](https://www.alchemy.com/solana-grpc) está disponível hoje em todos os planos pagos a partir de $75/TB, sem restrição de plano e sem mínimo mensal. Se você já roda um cliente Yellowstone, a migração é uma mudança de URL. - [Leia a documentação](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart) - [Fale com nossa equipe](https://www.alchemy.com/contact-sales) - [Inscreva-se no Solana Fund de $20M](https://www.alchemy.com/solana-20m-fund) para até $25 mil em créditos para acelerar seu app na Solana.