---
title: "Como migrar entre provedores de RPC com zero downtime"
description: "Migrar entre provedores de RPC é uma troca de endpoint, não uma reconstrução. O que a compatibilidade drop-in cobre, o que auditar primeiro e como trocar sem downtime."
---

# Como migrar entre provedores de RPC com zero downtime

<ImageBlock
  src="https://media.alchemy.com/blog/migrate-between-rpc-providers-zero-downtime-16x9-20260821.png"
  alt="Migre entre provedores de RPC sem downtime"
  width={1920}
  height={1080}
  priority
/>

Times adiam trocar de provedor de RPC porque parece que vão ter que reconstruir tudo. Na maioria das vezes são algumas horas de configuração. Todo provedor relevante segue o mesmo padrão JSON-RPC, então a requisição que seu app envia hoje é a mesma requisição que o novo provedor espera amanhã. Migrar de provedor de RPC é trocar um endpoint, não reescrever o código.

O trabalho que resta fica em volta da troca, não dentro dela: encontrar todos os lugares onde uma URL de endpoint está escondida, mapear o punhado de chamadas específicas do provedor que não se transferem, e fazer o corte de tráfego em uma ordem que seus usuários nunca percebem.

## O que significa compatibilidade drop-in de endpoint?

Compatibilidade drop-in de endpoint significa que dois provedores de RPC aceitam as mesmas requisições e retornam as mesmas respostas para métodos JSON-RPC padrão. Uma aplicação troca de provedor mudando a URL do endpoint que chama. Nomes de métodos, parâmetros e formatos de resposta permanecem idênticos, então a superfície padrão não exige nenhuma mudança de código.

A compatibilidade vem do protocolo, não de algum acordo entre provedores. `eth_call`, `eth_getLogs`, `eth_sendRawTransaction`, e o resto das famílias `eth_*`, `net_*` e `web3_*` são definidos pela [especificação JSON-RPC do Ethereum](https://ethereum.org/en/developers/docs/apis/json-rpc/), e todo provedor sério os implementa conforme a especificação. O mesmo vale para streaming. `eth_subscribe` via WebSocket carrega os mesmos streams newHeads, logs e newPendingTransactions nos [nossos endpoints de subscription](https://www.alchemy.com/docs/reference/subscription-api) que em qualquer outro provedor relevante.

Aqui está o formato do nosso endpoint ao lado do padrão que a maioria dos outros provedores usa:

<CodeSnippet
  language="text"
  code={`Alchemy:         https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY
Other providers: https://your-endpoint-name.provider.example/YOUR_AUTH_TOKEN/`}
/>

Ambos são uma URL com um secret no path. Se o seu endpoint vive em uma variável de ambiente, migrar seu tráfego padrão significa mudar o valor dessa variável. É também por isso que a recomendação padrão de confiabilidade de manter um [endpoint de RPC de backup](https://www.alchemy.com/overviews/alternative-rpc-endpoint) configurado funciona como seguro de migração. O mecanismo de fallback que você adicionaria para uptime é o mesmo mecanismo que você usa para trocar.

Chamadas JSON-RPC padrão rodam no novo provedor sem mudanças. O trabalho se esconde onde quer que seu app dependa de algo específico do provedor, e encontrar esses lugares é para isso que serve a auditoria.

## O que você deve auditar antes de migrar?

A maioria das surpresas em uma migração de provedor é descoberta depois da troca, e todas elas poderiam ter sido encontradas antes. Para uma base de código típica, a auditoria leva uma ou duas horas.

**Encontre toda referência a endpoint.** URLs de endpoint se acumulam em mais lugares do que qualquer um lembra. Procure em arquivos de ambiente, configs do Hardhat e Foundry, imagens Docker, pipelines de CI e builds de frontend pelo domínio do provedor atual e por qualquer URL hardcoded. A referência que você não encontra costuma estar em um cron job ou em um pipeline de CI que ninguém abre há meses.

**Mapeie métodos com prefixo de provedor.** A maioria dos provedores oferece métodos de conveniência sob um prefixo próprio (o nosso é `alchemy_`), e esses não se transferem entre plataformas. Consultas de token mapeiam para equivalentes da [Data API](https://www.alchemy.com/docs/data) como [alchemy_getTokenBalances](https://www.alchemy.com/docs/data/token-api/token-api-endpoints/alchemy-get-token-balances), e histórico de transferências vai para [alchemy_getAssetTransfers](https://www.alchemy.com/docs/data/transfers-api/transfers-endpoints/alchemy-get-asset-transfers). Os equivalentes existem, mas os formatos de resposta são diferentes, então trate cada um como uma pequena mudança de código, não como um find-and-replace.

**Verifique como você autentica.** Uma chave no path da URL se transfere sem problemas. Se você autentica com um header `x-token` ou com JWTs, esses controles precisam ser recriados no novo provedor. Do nosso lado, allowlists de domínio e IP ficam no [dashboard da Alchemy](https://dashboard.alchemy.com) e levam poucos minutos para configurar.

**Reavalie o preço do seu tráfego sob o novo modelo de medição.** Este é o item da auditoria que afeta sua fatura, não seu código. Muitos provedores medem um orçamento fixo de requisições por segundo. Nós medimos [compute units](https://www.alchemy.com/docs/reference/compute-unit-costs), onde uma chamada leve como `eth_blockNumber` custa menos que uma chamada pesada como `eth_getLogs`, e o [throughput](https://www.alchemy.com/docs/reference/throughput) é uma taxa de compute units em uma janela móvel, não uma contagem fixa de requisições. O efeito vai nos dois sentidos. Workloads de indexação pesados em logs consomem orçamento mais rápido do que sua contagem de requisições sugere, enquanto workloads de polling leve consomem menos. A maioria das equipes calcula o preço da hora de tráfego real mais movimentada contra [nossos preços](https://www.alchemy.com/pricing) antes de trocar, em vez de estimar a partir de totais mensais.

**Verifique o gating de plano em métodos de trace e debug.** Métodos `debug_` e `trace_` são limitados por plano na maioria dos provedores. Na Alchemy eles estão disponíveis nos [planos pay-as-you-go e enterprise](https://www.alchemy.com/pricing), mas não no tier gratuito, então se você rodar sua prova de conceito em um endpoint gratuito, espere que chamadas de trace falhem ali mesmo que tudo o mais funcione.

Nenhum desses itens bloqueia uma migração, mas juntos eles definem seu escopo. Para a maioria dos apps, a auditoria termina com uma lista curta de variáveis de ambiente, um ou dois mapeamentos de métodos, e uma estimativa de preço.

## Como fazer o corte de tráfego sem downtime?

O padrão de zero downtime é o mesmo que equipes usam para migrações de banco de dados. Rode o antigo e o novo em paralelo, mova o tráfego em estágios, e mantenha o caminho antigo ativo até que o novo tenha conquistado confiança.

Bibliotecas de cliente tornam a fase paralela quase gratuita. O [fallback transport](https://viem.sh/docs/clients/transports/fallback) do viem recebe uma lista ordenada de endpoints e desce a lista quando um falha:

<CodeSnippet
  language="typescript"
  code={`import { createPublicClient, fallback, http } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
  chain: mainnet,
  transport: fallback([
    http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
    http("https://your-endpoint-name.provider.example/YOUR_AUTH_TOKEN/"),
  ]),
});`}
/>

Com o novo provedor em primeiro e o antigo em segundo, toda requisição tenta o novo endpoint e cai de volta para o que já estava funcionando. Seu pior caso durante o corte é a configuração que você já tem hoje. O ethers.js oferece o mesmo padrão no [FallbackProvider](https://docs.ethers.org/v6/api/providers/fallback-provider/), com uma opção de quorum que consulta vários provedores e aceita um resultado quando concordam, o que te dá verificações de concordância entre provedores dentro do próprio cliente.

A ordem em que você move o tráfego importa mais do que a velocidade com que você o move, e o princípio é leituras primeiro, escritas por último. Leituras são stateless e fáceis de verificar, então direcione o tráfego de leitura para o novo endpoint cedo e compare o que volta. Rode suas queries mais pesadas nos dois provedores, `eth_getLogs` sobre os ranges de bloco mais movimentados dos seus contratos e `eth_call` contra seus contratos principais, e compare as respostas. O envio de transações se move por último, depois que as leituras já rodaram sem problemas, porque uma leitura falha é uma nova tentativa e uma escrita falha é um chamado de suporte.

Subscriptions via WebSocket precisam de um passo extra. Uma subscription está vinculada à conexão que a criou, então ela não faz failover. Ela cai, e você a recria. Planeje se reinscrever no novo endpoint e preencher a lacuna com uma query `eth_getLogs` sobre os blocos que passaram durante a reconexão, para que nenhum evento se perca. Nossas [boas práticas de WebSocket](https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3) também recomendam manter o escopo da subscription estreito, o que torna tanto a reinscrição quanto o preenchimento mais baratos.

Duas coisas merecem um dashboard durante a execução em paralelo. A primeira é o atraso de altura de bloco. Dois provedores saudáveis podem estar em tips de chain ligeiramente diferentes a qualquer momento, então alerte quando o novo endpoint ficar consistentemente atrás do antigo, não em diferenças momentâneas. A segunda é o formato de erro. Respostas de rate limit diferem entre provedores. Sobre HTTP, as nossas retornam um 429 com um [header Retry-After](https://www.alchemy.com/docs/reference/throughput); sobre WebSocket, o mesmo limite aparece como um erro JSON-RPC 429 sem header. Exercite sua lógica de retry contra o novo endpoint, nos dois transportes que você usa, antes que ele carregue tráfego de produção.

A maioria das equipes dá à fase paralela um ou dois dias de tráfego de produção, e então torna o novo endpoint o padrão. Mantenha o endpoint antigo configurado como fallback até o período de cobrança dele acabar. O rollback fica a uma mudança de configuração de distância o tempo todo, e é isso que zero downtime significa na prática. Coisas ainda podem dar errado. Elas só nunca precisam chegar aos seus usuários.

## Como saber se o novo provedor está se saindo bem?

A comparação que você rodou durante a fase paralela se torna sua baseline. Depois da troca, continue observando os números que você comparou antes: taxa de sucesso, latência p95 e frescor de bloco. Se a migração valeu a pena, pelo menos um desses deve se mover a seu favor.

Você também não precisa confiar em alegações de latência por fé. Nossos [benchmarks de RPC ao vivo](https://www.alchemy.com/benchmarks) nos comparam com outros provedores relevantes em diversas chains e regiões, e a [metodologia por trás deles](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance) é pública, então você pode reproduzir os números a partir da sua própria região antes de se comprometer. Para a história mais profunda de por que esses números se mantêm sob carga, nossa [reconstrução do edge proxy](https://www.alchemy.com/blog/alchemy-edge-proxy) percorre a camada de roteamento que toda requisição atinge primeiro.

E se você ainda está avaliando provedores em vez de verificar um, nosso [guia para escolher um provedor de nó](https://www.alchemy.com/overviews/how-to-choose-a-blockchain-node-provider) e o [guia de avaliação de RPC enterprise](https://www.alchemy.com/blog/blockchain-rpc-infrastructure-evaluation-guide-for-enterprises) cobrem as perguntas que valem a pena fazer antes mesmo da questão da migração surgir.

Mantenha as verificações da execução paralela ativas depois que a migração terminar. Os diffs de resposta e os dashboards de latência que validaram o corte de tráfego vão sinalizar regressões de provedor e dados desatualizados meses depois, e eles já estão construídos.

## Pronto para trocar de provedor de RPC?

Qualquer que seja o provedor que você está deixando, tudo acima se aplica como está escrito.

Crie um endpoint gratuito no [dashboard da Alchemy](https://dashboard.alchemy.com) e aponte seu ambiente de staging para ele hoje. Sem contratos, sem chamada de vendas, sem compromisso mínimo. O tier gratuito inclui [30M compute units por mês](https://www.alchemy.com/pricing), suficiente para rodar toda a comparação da fase paralela em tráfego real de produção, e a mesma troca de endpoint funciona nas [mais de 100 chains que suportamos](https://www.alchemy.com/rpc).