---
title: "Cómo migrar entre proveedores de RPC sin downtime"
description: "Migrar entre proveedores de RPC es un cambio de endpoint, no una reconstrucción. Qué cubre la compatibilidad drop-in, qué auditar primero y cómo migrar sin downtime."
---

# Cómo migrar entre proveedores de RPC sin downtime

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

Los equipos posponen el cambio de proveedor de RPC porque sienten que implica una reconstrucción completa. La mayoría de las veces son apenas unas horas de configuración. Todo proveedor importante sigue el mismo estándar JSON-RPC, así que la solicitud que tu aplicación envía hoy es la misma que espera el nuevo proveedor mañana. Migrar de proveedor de RPC es cambiar un endpoint, no reescribir código.

El trabajo que queda está alrededor del cambio, no dentro de él: encontrar cada lugar donde se esconde una URL de endpoint, identificar el puñado de llamadas específicas del proveedor que no se trasladarán, y hacer el corte de tráfico en un orden que tus usuarios nunca noten.

## ¿Qué significa la compatibilidad directa entre endpoints?

La compatibilidad directa entre endpoints significa que dos proveedores de RPC aceptan las mismas solicitudes y devuelven las mismas respuestas para los métodos estándar de JSON-RPC. Una aplicación cambia de proveedor modificando la URL del endpoint que invoca. Los nombres de método, los parámetros y la forma de las respuestas se mantienen idénticos, así que la superficie estándar no requiere ningún cambio de código.

La compatibilidad viene del protocolo, no de ningún acuerdo entre proveedores. `eth_call`, `eth_getLogs`, `eth_sendRawTransaction`, y el resto de las familias `eth_*`, `net_*` y `web3_*` están definidas por la [especificación JSON-RPC de Ethereum](https://ethereum.org/en/developers/docs/apis/json-rpc/), y todo proveedor serio las implementa conforme a esa especificación. Lo mismo aplica al streaming. `eth_subscribe` sobre WebSocket transporta los mismos streams de newHeads, logs y newPendingTransactions en [nuestros endpoints de suscripción](https://www.alchemy.com/docs/reference/subscription-api) que en los de cualquier otro proveedor importante.

Aquí está la forma de nuestro endpoint junto al patrón que usan la mayoría de los otros proveedores:

<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 son una URL con un secreto en la ruta. Si tu endpoint vive en una variable de entorno, migrar tu tráfico estándar significa cambiar el valor de esa variable. Esto también explica por qué el consejo estándar de confiabilidad de mantener configurado un [endpoint de RPC de respaldo](https://www.alchemy.com/overviews/alternative-rpc-endpoint) funciona además como seguro de migración. El mecanismo de respaldo que agregarías por disponibilidad es el mismo que usas para cambiar de proveedor.

Las llamadas JSON-RPC estándar se ejecutan sin cambios en el nuevo proveedor. El trabajo se esconde donde sea que tu aplicación dependa de algo específico del proveedor, y encontrar esos lugares es para lo que sirve la auditoría.

## ¿Qué deberías auditar antes de migrar?

La mayoría de las sorpresas en una migración de proveedor se descubren después del cambio, y cualquiera de ellas podría haberse encontrado antes. Para una base de código típica, la auditoría toma una o dos horas.

**Encuentra cada referencia a un endpoint.** Las URLs de endpoints se acumulan en más lugares de los que cualquiera recuerda. Busca en archivos de entorno, configuraciones de Hardhat y Foundry, imágenes de Docker, pipelines de CI y builds de frontend el dominio del proveedor actual y cualquier URL codificada directamente. La referencia que se te pasa suele estar en un cron job o en un pipeline de CI que nadie ha abierto en meses.

**Mapea los métodos con prefijo de proveedor.** La mayoría de los proveedores ofrecen métodos de conveniencia bajo un prefijo propio (el nuestro es `alchemy_`), y esos no se trasladan entre plataformas. Las consultas de tokens se mapean a equivalentes de [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), y el historial de transferencias pasa a [alchemy_getAssetTransfers](https://www.alchemy.com/docs/data/transfers-api/transfers-endpoints/alchemy-get-asset-transfers). Los equivalentes existen, pero la forma de las respuestas difiere, así que trata cada uno como un pequeño cambio de código en lugar de un buscar y reemplazar.

**Revisa cómo te autenticas.** Una clave en la ruta de la URL se traslada sin problemas. Si en cambio te autenticas con un header `x-token` o con JWTs, esos controles hay que recrearlos en el nuevo proveedor. De nuestro lado, las listas blancas de dominio e IP viven en el [dashboard de Alchemy](https://dashboard.alchemy.com) y toman pocos minutos configurar.

**Vuelve a calcular el costo de tu tráfico bajo el nuevo modelo de medición.** Este es el punto de la auditoría que afecta tu factura en lugar de tu código. Muchos proveedores miden un presupuesto plano de solicitudes por segundo. Nosotros medimos [unidades de cómputo](https://www.alchemy.com/docs/reference/compute-unit-costs), donde una llamada liviana como `eth_blockNumber` cuesta menos que una llamada pesada como `eth_getLogs`, y el [throughput](https://www.alchemy.com/docs/reference/throughput) es una tasa de unidades de cómputo sobre una ventana móvil en lugar de un conteo plano de solicitudes. El efecto va en ambos sentidos. Las cargas de trabajo de indexación con muchos logs consumen presupuesto más rápido de lo que sugiere su cantidad de solicitudes, mientras que las cargas de polling livianas consumen menos. La mayoría de los equipos calcula el precio de su hora más ocupada de tráfico real contra [nuestros precios](https://www.alchemy.com/pricing) antes de cambiar, en lugar de adivinar a partir de totales mensuales.

**Revisa las restricciones de plan en los métodos de trace y debug.** Los métodos `debug_` y `trace_` están restringidos por plan en la mayoría de los proveedores. En Alchemy están disponibles en los [planes pay-as-you-go y enterprise](https://www.alchemy.com/pricing) pero no en el nivel gratuito, así que si corres tu prueba de concepto en un endpoint gratuito, espera que las llamadas de trace fallen ahí aunque todo lo demás funcione.

Ninguno de estos puntos bloquea una migración, pero juntos definen su alcance. Para la mayoría de las aplicaciones, la auditoría termina con una lista corta de variables de entorno, uno o dos mapeos de métodos, y una estimación de precio.

## ¿Cómo haces el corte sin tiempo de inactividad?

El patrón de cero tiempo de inactividad es el mismo que usan los equipos para migraciones de bases de datos. Corre el proveedor antiguo y el nuevo en paralelo, mueve el tráfico por etapas, y mantén la ruta antigua activa hasta que la nueva se haya ganado la confianza.

Las librerías de cliente hacen que la fase paralela sea casi gratuita. El [fallback transport](https://viem.sh/docs/clients/transports/fallback) de viem toma una lista ordenada de endpoints y avanza en la lista cuando uno falla:

<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/"),
  ]),
});`}
/>

Con el nuevo proveedor primero y el antiguo segundo, cada solicitud intenta primero el nuevo endpoint y cae de vuelta al que ya funcionaba. Tu peor escenario durante el corte es la configuración que ya tienes hoy. ethers.js ofrece el mismo patrón en [FallbackProvider](https://docs.ethers.org/v6/api/providers/fallback-provider/), con una opción de quórum que consulta a varios proveedores y acepta un resultado una vez que coinciden, lo cual te da verificaciones de concordancia entre proveedores dentro del mismo cliente.

El orden en que mueves el tráfico importa más que la velocidad a la que lo mueves, y el principio es: lecturas primero, escrituras al final. Las lecturas son sin estado y fáciles de verificar, así que apunta el tráfico de lectura al nuevo endpoint temprano y compara lo que regresa. Corre tus consultas más pesadas en ambos proveedores, `eth_getLogs` sobre los rangos de bloques más activos de tus contratos y `eth_call` contra tus contratos principales, y compara las respuestas. El envío de transacciones se mueve al final, después de que las lecturas hayan corrido sin problemas, porque una lectura fallida es un reintento y una escritura fallida es un ticket de soporte.

Las suscripciones por WebSocket necesitan un paso adicional. Una suscripción está atada a la conexión que la creó, así que no hace failover. Simplemente se cae, y hay que recrearla. Planea volver a suscribirte en el nuevo endpoint y rellenar el hueco con una consulta `eth_getLogs` sobre los bloques que pasaron durante la reconexión, para que no se pierda ningún evento. Nuestras [buenas prácticas de WebSocket](https://www.alchemy.com/docs/reference/best-practices-for-using-websockets-in-web3) también recomiendan mantener el alcance de la suscripción acotado, lo cual abarata tanto la resuscripción como el relleno.

Dos cosas merecen un dashboard durante la corrida en paralelo. La primera es el retraso en altura de bloque. Dos proveedores sanos pueden estar en puntas de cadena ligeramente distintas en un momento dado, así que alerta cuando el nuevo endpoint se quede consistentemente atrás del antiguo, no por diferencias momentáneas. La segunda es la forma del error. Las respuestas de límite de tasa difieren entre proveedores. Sobre HTTP, las nuestras devuelven un 429 con un [header Retry-After](https://www.alchemy.com/docs/reference/throughput); sobre WebSocket, el mismo límite se manifiesta como un error JSON-RPC 429 sin header. Ejercita tu lógica de reintentos contra el nuevo endpoint, en ambos transportes que uses, antes de que cargue tráfico de producción.

La mayoría de los equipos le dan a la fase paralela uno o dos días de tráfico de producción, y luego hacen que el nuevo endpoint sea el predeterminado. Mantén el endpoint antiguo configurado como respaldo hasta que se agote su período de facturación. El rollback queda siempre a un cambio de configuración de distancia, y eso es lo que significa cero tiempo de inactividad en la práctica. Las cosas pueden seguir saliendo mal. Simplemente nunca tienen que llegar a tus usuarios.

## ¿Cómo sabes si el nuevo proveedor está respondiendo bien?

La comparación que hiciste durante la fase paralela se convierte en tu línea base. Después del cambio, sigue observando los números que comparaste antes: tasa de éxito, latencia p95 y frescura de bloque. Si la migración valió la pena, al menos uno de ellos debería moverse a tu favor.

Tampoco tienes que tomar las afirmaciones de latencia como un acto de fe. Nuestros [benchmarks de RPC en vivo](https://www.alchemy.com/benchmarks) nos comparan con otros proveedores importantes en distintas chains y regiones, y la [metodología detrás de ellos](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance) es pública, así que puedes reproducir los números desde tu propia región antes de comprometerte. Para la historia más a fondo de por qué esos números se sostienen bajo carga, nuestra [reconstrucción del proxy de borde](https://www.alchemy.com/blog/alchemy-edge-proxy) recorre la capa de enrutamiento que recibe primero cada solicitud.

Y si todavía estás evaluando proveedores en lugar de verificar uno, nuestra [guía para elegir un proveedor de nodos](https://www.alchemy.com/overviews/how-to-choose-a-blockchain-node-provider) y la [guía de evaluación de RPC empresarial](https://www.alchemy.com/blog/blockchain-rpc-infrastructure-evaluation-guide-for-enterprises) cubren las preguntas que vale la pena hacerse antes de que surja la pregunta de la migración.

Mantén activas las verificaciones de la corrida en paralelo después de que termine la migración. Los diffs de respuestas y los dashboards de latencia que validaron el corte detectarán regresiones del proveedor y datos desactualizados meses después, y ya están construidos.

## ¿Listo para cambiar de proveedor de RPC?

Sea cual sea el proveedor que estés dejando, todo lo anterior aplica tal como está escrito.

Crea un endpoint gratuito en el [dashboard de Alchemy](https://dashboard.alchemy.com) y apunta hoy mismo tu entorno de staging hacia él. Sin contratos, sin llamada de ventas, sin compromiso mínimo. El nivel gratuito incluye [30M de unidades de cómputo al mes](https://www.alchemy.com/pricing), suficiente para correr la comparación completa de la fase paralela con tráfico de producción real, y el mismo cambio de endpoint funciona en las [más de 100 chains que soportamos](https://www.alchemy.com/rpc).