--- title: "Como construímos uma infraestrutura de RPC de baixa latência" description: "Latência de RPC é um problema de sistemas, não um único gargalo. Veja como a Alchemy reduziu a latência na borda, no roteamento, no escalonamento, nas operações de node e na medição." --- # Como construímos uma infraestrutura de RPC de baixa latência Uma wallet carrega o saldo de um usuário. Um app de trading estima o gas antes de um swap. Um indexer faz o backfill de meses de histórico em uma única rajada. Cada uma dessas ações é uma chamada RPC, e cada milissegundo de atraso é sentido por uma pessoa real esperando na tela. A latência de RPC não é causada por uma única coisa, então não pode ser resolvida por uma única coisa. Ela vem do overhead do caminho da requisição, de tráfego de rede interno evitável, de roteamento ineficiente, de picos repentinos de tráfego, de atraso operacional da chain e dos nodes, de gargalos específicos de cada workload e de medições incompletas. Corrigir um desses pontos e ignorar o resto apenas desloca o gargalo. Por isso tratamos a latência como um problema de sistema e investimos em cada camada que controlamos, mantendo 99,99% de uptime e tempos médios de resposta abaixo de 50ms como base nas mais de 100 chains que suportamos. ## O que construímos Alchemy Edge Proxy', tooltip: "", icon: "", }, benefit: { title: "Faster response at the tail, up to 7.5x", tooltip: "", icon: "", }, id: 0, }, { cause: { title: "Avoidable internal network travel", tooltip: "", icon: "", }, built: { title: 'Closer service placement within the cluster', tooltip: "", icon: "", }, benefit: { title: "Less time lost inside our infrastructure", tooltip: "", icon: "", }, id: 1, }, { cause: { title: "Inefficient routing", tooltip: "", icon: "" }, built: { title: 'Contextual smart routing', tooltip: "", icon: "", }, benefit: { title: "Shorter infrastructure paths, up to 2.5x faster queries", tooltip: "", icon: "", }, id: 2, }, { cause: { title: "Traffic spikes", tooltip: "", icon: "" }, built: { title: 'Predictive scaling', tooltip: "", icon: "", }, benefit: { title: "Capacity ready before the surge (Usual: 30K RPS)", tooltip: "", icon: "", }, id: 3, }, { cause: { title: "Predictable throughput under load", tooltip: "", icon: "" }, built: { title: 'Purpose-built, elastic throughput', tooltip: "", icon: "", }, benefit: { title: "Stable performance when volume climbs", tooltip: "", icon: "", }, id: 4, }, { cause: { title: "Chain and node operational lag", tooltip: "", icon: "", }, built: { title: 'AI-managed node fleet', tooltip: "", icon: "", }, benefit: { title: "Upgrades detected, tested, and rolled out with less delay", tooltip: "", icon: "", }, id: 5, }, { cause: { title: "Workload-specific bottlenecks", tooltip: "", icon: "", }, built: { title: 'Product-specific optimization', tooltip: "", icon: "", }, benefit: { title: "Full product flows (World: 44% faster to mine) and heavy queries (Solflare: up to 20x faster archive) stay fast", tooltip: "", icon: "", }, id: 6, }, { cause: { title: "Incomplete measurement", tooltip: "", icon: "" }, built: { title: 'Benchmark methodology', tooltip: "", icon: "", }, benefit: { title: "Latency measured with success rate and failed requests", tooltip: "", icon: "", }, id: 7, }, ], }} /> ## O Alchemy Edge Proxy reduz o overhead do caminho da requisição O edge é a porta de entrada: o primeiro ponto de contato controlado pela Alchemy que uma requisição toca. Antes de uma chamada chegar a qualquer node, ela passa pelo estabelecimento de conexão, negociação TLS, autenticação e lógica de roteamento. Cada etapa adiciona milissegundos, e esses milissegundos se acumulam principalmente na cauda - as requisições mais lentas, aquelas que o usuário realmente sente. O Alchemy Edge Proxy é a camada que construímos para remover esse overhead do caminho da requisição. Ao lidar com reuso de conexão, autenticação e decisões de roteamento na porta de entrada em vez de mais fundo na stack, ele reduz o custo fixo que toda requisição paga. O resultado é um RPC até 7,5x mais rápido na cauda. Veja [Alchemy Edge Proxy](/blog/alchemy-edge-proxy) para mais detalhes. Por baixo do capô, o edge roda sobre uma arquitetura de proxy microkernel, parte do [Cortex](/cortex): um núcleo pequeno e estável cuida do caminho crítico da requisição, enquanto módulos como autenticação, rate limiting e roteamento são atualizados de forma independente. Como o edge é uma das camadas de infraestrutura crítica que controlamos de ponta a ponta, podemos continuar melhorando-o sem depender da rede de mais ninguém. ## Dentro da nossa infraestrutura: posicionamento mais próximo, roteamento mais inteligente, throughput estável Uma vez que uma requisição está dentro da nossa infraestrutura, distância e hardware ainda custam tempo. Se os serviços que atendem uma chamada estão fisicamente distantes, a requisição gasta milissegundos apenas viajando entre eles antes de qualquer trabalho real acontecer. E quando o volume aumenta, hardware compartilhado adiciona o tipo de variabilidade que aparece como latência inconsistente. É aqui que o [Cortex](/cortex), o motor de blockchain inteligente da Alchemy, faz o trabalho pesado. O Cortex é o principal investimento de infraestrutura por trás dos nossos números de baixa latência, e algumas peças específicas dele importam aqui: - A colocação de pods com Kubernetes affinity mantém os serviços que mais se comunicam na mesma máquina, de modo que as requisições permaneçam locais em vez de saltar entre racks. - O roteamento consciente de localidade do Istio envia tráfego interno para a instância de serviço disponível mais próxima, encurtando os caminhos de infraestrutura quando isso realmente ajuda. - Milhares de servidores bare-metal implantados globalmente rodam diretamente em hardware dedicado sem overhead de virtualização, de modo que o throughput se mantém consistente sob carga pesada. - Java virtual threads permitem que uma única máquina lide com muito mais requisições concorrentes sem o custo de memória e CPU das threads tradicionais, o que é o que absorve um surto sem que a latência suba. Juntos, eles cortam o tempo de deslocamento em que os usuários nunca pensam mas sempre sentem, e mantêm o desempenho estável conforme o volume aumenta. ## O escalonamento preditivo prepara capacidade antes dos picos O tráfego onchain não aumenta de forma educada. Um lançamento, um mint ou um evento de mercado pode multiplicar a carga em segundos, e capacidade que chega depois do pico é capacidade que chegou tarde demais. Nossa lógica de escalonamento preditivo prepara capacidade antes da demanda em vez de reagir a ela, observando sinais como CPU, memória, I/O de disco e padrões de tráfego para provisionar antes que um pico aconteça. A Usual é a prova: eles atingiram um pico de 30.000 requisições por segundo, serviram 38 milhões de requisições na primeira hora e ultrapassaram 1 bilhão de requisições em 36 horas, sem que a latência se deteriorasse sob o surto. > "A Alchemy conseguiu nos dar uma disponibilidade quase perfeita, atendendo quantidades massivas de requisições por segundo (30 mil requisições por segundo foi o nosso pico, e ainda tínhamos margem), sem nenhum contratempo ou downtime. E tudo com pouco aviso prévio!" > > Adli Takkal-Bataille, [Usual](/case-studies/scaling-to-30000-requests-per-second) ## A automação da frota gerenciada por IA mantém as operações de node atualizadas As blockchains mudam por baixo dos seus pés. Clients lançam atualizações, redes agendam hard forks, e um node rodando software desatualizado é um node servindo respostas lentas ou erradas. Lidar com isso manualmente introduz atraso e risco exatamente quando a precisão mais importa. Nossa frota de nodes é gerenciada por um sistema agêntico totalmente automatizado que cuida de atualizações, testes e monitoramento. As atualizações são detectadas e aplicadas em tempo real, com testes automatizados embutidos no pipeline, de modo que upgrades de rede obrigatórios e hard forks nunca são perdidos. Fazer isso manualmente em cada chain que operamos seria impossível de manter atualizado - por isso automatizamos, e por isso mantemos o mesmo padrão de baixa latência em mais de 100 chains em vez de apenas algumas favoritas. Essa automação faz parte do [Cortex](/cortex), o motor de blockchain inteligente por trás da plataforma Alchemy: [RPC APIs](/rpc-api), data APIs, rollups e o restante da stack de desenvolvimento. ## A otimização específica de produto melhora fluxos completos de usuário A latência não se resume a uma única chamada. Produtos reais encadeiam chamadas, e o fluxo só é tão rápido quanto seu elo mais lento. O que os usuários realmente sentem é o caminho inteiro, não um método isolado. A World, construída pela Tools for Humanity e rodando na World Chain, teve um tempo de mine 44% mais rápido, caindo de 5,5 segundos para 3,1 segundos, e uma latência de estimativa de gas 74% menor em `alchemy_requestGasAndPaymasterAndData`, de aproximadamente 380ms para 100ms. > "Quando estávamos procurando fornecedores de infraestrutura, o que mais importava era escala e suporte empresarial. A Alchemy foi disparada a líder clara em cada produto que precisávamos - a única escolha lógica." > > Steven, [Tools For Humanity](/case-studies/world-onchain-performance) ## A infraestrutura de arquivamento em Solana reduz a latência de queries pesadas Queries históricas e de arquivamento são um tipo particular de desafio. Extrair grandes intervalos de estado passado é trabalho pesado, e em uma chain de throughput tão alto quanto Solana isso pode ficar arrastado sem infraestrutura construída para esse fim. Construímos os métodos de arquivamento mais rápidos em Solana sobre uma arquitetura HBase multi-região personalizada, parte da nossa plataforma Solana. A Solflare rodou exatamente esse workload e teve queries de arquivo até 20x mais rápidas, tempos de resposta abaixo de 200ms durante grandes queries históricas, e backfills de wallet concluídos em menos de um minuto. > "O Archival RPC da Alchemy acompanhou o throughput da Solflare mantendo um tempo de resposta consistente de <200ms." > > Dusan K., [Solflare](/case-studies/solflare) ## A metodologia de benchmark mede velocidade e confiabilidade juntas Números de velocidade não significam nada sem honestidade sobre o que aconteceu com cada requisição. Uma média rápida que esconde chamadas com falha ou perdidas não é rápida, é enganosa. Nossa metodologia de benchmark mede a latência junto com a taxa de sucesso e as requisições com falha, de modo que os números reflitam o que um workload real experimentaria. Esse é o padrão que mantemos para nós mesmos, e o mesmo que convidamos você a exigir de nós. Você pode conferir a [metodologia de benchmark](/blog/how-we-benchmark-rpc-performance) completa. ## O objetivo: infraestrutura rápida o suficiente para desaparecer A melhor infraestrutura é aquela que ninguém percebe. Quando a latência é baixa o suficiente e a confiabilidade é alta o suficiente, a wallet simplesmente carrega, o swap simplesmente confirma, e o backfill simplesmente termina. Nenhuma camada dessa stack resolve a latência sozinha, mas juntas elas somam essa experiência. Veja os números por conta própria. Compare provedores na [página de benchmarks da Alchemy](/benchmarks), e leia exatamente [como fazemos o benchmark de performance de RPC](/blog/how-we-benchmark-rpc-performance) para que você possa julgar o método, não apenas o resultado. Quando estiver pronto para construir sobre isso, [comece gratuitamente](https://dashboard.alchemy.com/signup/). ## FAQ **O que causa a latência de RPC?** A latência de RPC vem de várias fontes independentes: overhead do caminho da requisição no ponto de entrada, tráfego evitável entre serviços internos, roteamento ineficiente, picos de tráfego, atraso operacional da chain e dos nodes, gargalos específicos de cada workload e medições incompletas. Como as causas são separadas, nenhuma correção isolada elimina todas elas. **Uma única otimização pode resolver a latência de RPC?** Não. Corrigir uma única causa simplesmente desloca o gargalo para a próxima. Reduzir a latência de forma confiável exige investir em cada camada do caminho da requisição, desde o edge até a infraestrutura de nodes e a forma como o desempenho é medido. **O que é o edge na infraestrutura de RPC?** O edge é o primeiro ponto de entrada controlado pelo provedor que uma requisição alcança, a porta de entrada para o tráfego de RPC. Lidar com o estabelecimento de conexão, a autenticação e o roteamento ali em vez de mais fundo na stack remove o overhead fixo que toda requisição pagaria de outra forma. **Como a Alchemy mede a latência de RPC com honestidade?** A Alchemy mede a latência junto com a taxa de sucesso e as requisições com falha, não como uma média isolada. Isso evita que um número aparentemente rápido esconda chamadas perdidas ou com falha, de modo que os resultados reflitam o que um workload real de produção de fato experimentaria. **Como o escalonamento preditivo lida com picos de tráfego?** O escalonamento preditivo prepara capacidade antes da demanda em vez de reagir depois que um pico começa. Foi isso que permitiu à Usual sustentar 30.000 requisições por segundo e mais de 1 bilhão de requisições em 36 horas sem degradação de latência durante o surto. **Por que o desempenho de queries de arquivamento em Solana é um problema à parte?** Queries de arquivamento extraem grandes intervalos de estado histórico, o que é trabalho pesado, e o alto throughput de Solana torna esses intervalos ainda maiores. Uma infraestrutura de arquivamento construída para esse fim é o que mantém essas queries rápidas, como visto nas queries de arquivo até 20x mais rápidas da Solflare.