--- title: "Cómo construimos infraestructura de RPC de baja latencia" description: "La latencia de RPC es un problema de sistemas, no un único cuello de botella. Así es como Alchemy redujo la latencia en el edge, el ruteo, el escalado, las operaciones de nodos y la medición." --- # Cómo construimos infraestructura de RPC de baja latencia Una wallet carga el balance de un usuario. Una app de trading estima el gas antes de un swap. Un indexer reconstruye meses de historial en una sola ráfaga. Cada una de esas acciones es una llamada RPC, y cada milisegundo de demora lo siente una persona real esperando frente a una pantalla. La latencia de RPC no tiene una sola causa, así que no se resuelve con una sola solución. Proviene de la sobrecarga en el camino de la solicitud, del tránsito de red interno evitable, del ruteo ineficiente, de picos repentinos de tráfico, del retraso operativo de la chain y los nodos, de cuellos de botella específicos de cada carga de trabajo, y de mediciones incompletas. Corregir una causa e ignorar el resto solo desplaza el cuello de botella. Por eso tratamos la latencia como un problema de sistema e invertimos en cada capa que controlamos, manteniendo 99.99% de uptime y tiempos de respuesta promedio por debajo de 50ms como base en las más de 100 chains que soportamos. ## Qué construimos Alchemy Edge Proxy', tooltip: "", icon: "", }, benefit: { title: "Respuesta más rápida en la cola, hasta 7.5x", tooltip: "", icon: "", }, id: 0, }, { cause: { title: "Tránsito de red interno evitable", tooltip: "", icon: "", }, built: { title: 'Ubicación de servicios más cercana dentro del cluster', tooltip: "", icon: "", }, benefit: { title: "Menos tiempo perdido dentro de nuestra infraestructura", tooltip: "", icon: "", }, id: 1, }, { cause: { title: "Ruteo ineficiente", tooltip: "", icon: "" }, built: { title: 'Ruteo inteligente y contextual', tooltip: "", icon: "", }, benefit: { title: "Rutas de infraestructura más cortas, consultas hasta 2.5x más rápidas", tooltip: "", icon: "", }, id: 2, }, { cause: { title: "Picos de tráfico", tooltip: "", icon: "" }, built: { title: 'Escalado predictivo', tooltip: "", icon: "", }, benefit: { title: "Capacidad lista antes del pico (Usual: 30K RPS)", tooltip: "", icon: "", }, id: 3, }, { cause: { title: "Throughput predecible bajo carga", tooltip: "", icon: "" }, built: { title: 'Throughput elástico diseñado a medida', tooltip: "", icon: "", }, benefit: { title: "Rendimiento estable cuando el volumen aumenta", tooltip: "", icon: "", }, id: 4, }, { cause: { title: "Retraso operativo de la chain y los nodos", tooltip: "", icon: "", }, built: { title: 'Flota de nodos gestionada con IA', tooltip: "", icon: "", }, benefit: { title: "Actualizaciones detectadas, probadas e implementadas con menos demora", tooltip: "", icon: "", }, id: 5, }, { cause: { title: "Cuellos de botella específicos de cada carga de trabajo", tooltip: "", icon: "", }, built: { title: 'Optimización específica por producto', tooltip: "", icon: "", }, benefit: { title: "Los flujos completos de producto (World: 44% más rápido para minar) y las consultas pesadas (Solflare: hasta 20x más rápido en archive) se mantienen rápidos", tooltip: "", icon: "", }, id: 6, }, { cause: { title: "Medición incompleta", tooltip: "", icon: "" }, built: { title: 'Metodología de benchmarking', tooltip: "", icon: "", }, benefit: { title: "Latencia medida junto con la tasa de éxito y las solicitudes fallidas", tooltip: "", icon: "", }, id: 7, }, ], }} /> ## Alchemy Edge Proxy reduce la sobrecarga en el camino de la solicitud El edge es la puerta de entrada: el primer punto de contacto controlado por Alchemy que toca una solicitud. Antes de que una llamada llegue a cualquier nodo, pasa por el establecimiento de conexión, la negociación TLS, la autenticación y la lógica de ruteo. Cada paso agrega milisegundos, y esos milisegundos se acumulan más en la cola: las solicitudes más lentas, las que un usuario realmente siente. Alchemy Edge Proxy es la capa que construimos para eliminar esa sobrecarga del camino de la solicitud. Al manejar la reutilización de conexiones, la autenticación y las decisiones de ruteo en la puerta de entrada en lugar de más adentro en el stack, reduce el costo fijo que paga cada solicitud. El resultado es RPC hasta 7.5x más rápido en la cola. Ver [Alchemy Edge Proxy](/blog/alchemy-edge-proxy) para más detalle. Por debajo, el edge corre sobre una arquitectura de proxy de microkernel, parte de [Cortex](/cortex): un núcleo pequeño y estable controla el camino crítico de la solicitud, mientras que módulos como autenticación, rate limiting y ruteo se actualizan de forma independiente. Dado que el edge es una de las capas de infraestructura crítica que controlamos de punta a punta, podemos seguir mejorándolo sin depender de la red de nadie más. ## Dentro de nuestra infraestructura: ubicación más cercana, ruteo más inteligente, throughput estable Una vez que una solicitud está dentro de nuestra infraestructura, la distancia y el hardware siguen costando tiempo. Si los servicios que manejan una llamada están lejos entre sí, la solicitud pasa milisegundos solo viajando entre ellos antes de que se realice trabajo real. Y cuando el volumen sube, el hardware compartido agrega el tipo de variabilidad que se manifiesta como latencia inconsistente. Aquí es donde [Cortex](/cortex), el motor de blockchain inteligente de Alchemy, hace el trabajo pesado. Cortex es la inversión central de infraestructura detrás de nuestros números de baja latencia, y algunas piezas específicas de él importan aquí: - La colocación de pods con Kubernetes affinity mantiene en la misma máquina a los servicios que más se comunican entre sí, de modo que las solicitudes permanecen locales en lugar de saltar entre racks. - El ruteo con conciencia de localidad de Istio envía el tráfico interno a la instancia de servicio disponible más cercana, acortando las rutas de infraestructura cuando esto realmente ayuda. - Miles de servidores bare-metal desplegados globalmente corren directamente sobre hardware dedicado sin sobrecarga de virtualización, de modo que el throughput se mantiene consistente bajo carga alta. - Los virtual threads de Java permiten que una sola máquina maneje muchas más solicitudes concurrentes sin el costo de memoria y CPU de los threads tradicionales, lo cual es lo que absorbe un pico sin que la latencia aumente. Juntos, estos elementos reducen el tiempo de viaje que los usuarios nunca notan pero siempre sienten, y mantienen el rendimiento estable a medida que el volumen aumenta. ## El escalado predictivo prepara capacidad antes de los picos El tráfico onchain no aumenta de forma ordenada. Un lanzamiento, un mint o un evento de mercado pueden multiplicar la carga en segundos, y la capacidad que llega después del pico es capacidad que llegó demasiado tarde. Nuestra lógica de escalado predictivo prepara capacidad antes de la demanda en lugar de reaccionar a ella, observando señales como CPU, memoria, I/O de disco y patrones de tráfico para aprovisionar antes de que llegue un pico. Usual es la prueba: alcanzaron un pico de 30,000 solicitudes por segundo, atendieron 38 millones de solicitudes en la primera hora, y superaron los 1,000 millones de solicitudes en 36 horas, sin que la latencia se deteriorara bajo el aumento. > "Alchemy pudo darnos una disponibilidad casi perfecta, atendiendo cantidades masivas de solicitudes por segundo (30k solicitudes por segundo fue nuestro pico, y aún teníamos margen), sin contratiempos ni downtime. ¡Y todo con poco tiempo de aviso!" > > Adli Takkal-Bataille en [Usual](/case-studies/scaling-to-30000-requests-per-second) ## La automatización de la flota gestionada con IA mantiene las operaciones de nodos al día Las blockchains cambian debajo de ti. Los clients lanzan actualizaciones, las redes programan hard forks, y un nodo que corre software desactualizado es un nodo que sirve respuestas lentas o incorrectas. Manejar esto de forma manual introduce demora y riesgo justo cuando la precisión más importa. Nuestra flota de nodos es gestionada por un sistema agéntico totalmente automatizado que se encarga de actualizaciones, pruebas y monitoreo. Las actualizaciones se detectan y aplican en tiempo real, con pruebas automatizadas integradas en el pipeline, de modo que las actualizaciones de red obligatorias y los hard forks nunca se pasan por alto. Hacer esto de forma manual en cada chain que operamos sería imposible de mantener al día, por eso lo automatizamos, y por eso mantenemos el mismo estándar de baja latencia en más de 100 chains en lugar de en solo algunas favoritas. Esta automatización es parte de [Cortex](/cortex), el motor de blockchain inteligente detrás de la plataforma de Alchemy: [RPC APIs](/rpc-api), data APIs, rollups y el resto del stack para desarrolladores. ## La optimización específica por producto mejora los flujos completos de usuario La latencia no se trata solo de una llamada individual. Los productos reales encadenan llamadas, y el flujo es tan rápido como su eslabón más lento. Lo que los usuarios realmente sienten es la ruta completa, no un método individual. World, construido por Tools for Humanity y ejecutándose en World Chain, vio un tiempo de minado 44% más rápido, de 5.5 segundos a 3.1 segundos, y una latencia de estimación de gas 74% menor en `alchemy_requestGasAndPaymasterAndData`, de aproximadamente 380ms a 100ms. > "Cuando buscábamos proveedores de infraestructura, lo que más importaba era la escala y el soporte de nivel empresarial. Alchemy fue, sin duda, el líder claro en cada producto que necesitábamos, la única opción lógica." > > Steven en [Tools For Humanity](/case-studies/world-onchain-performance) ## La infraestructura archival de Solana reduce la latencia de consultas pesadas Las consultas históricas y archival son un tipo de problema en sí mismas. Extraer rangos grandes de estado pasado es un trabajo pesado, y en una chain de throughput tan alto como Solana puede volverse muy lento sin infraestructura construida para eso. Construimos los métodos archival más rápidos en Solana sobre una arquitectura HBase multi-región hecha a medida, parte de nuestra plataforma de Solana. Solflare ejecutó exactamente esa carga de trabajo y vio consultas archival hasta 20x más rápidas, tiempos de respuesta por debajo de 200ms durante consultas históricas grandes, y backfills de wallets completándose en menos de un minuto. > "El Archival RPC de Alchemy se ha mantenido a la par del throughput de Solflare, manteniendo un tiempo de respuesta consistente de <200ms." > > Dusan K. en [Solflare](/case-studies/solflare) ## La metodología de benchmarking mide velocidad y confiabilidad juntas Los números de velocidad no significan nada sin honestidad sobre qué pasó con cada solicitud. Un promedio rápido que esconde llamadas fallidas o descartadas no es rápido, es engañoso. Nuestra metodología de benchmarking mide la latencia junto con la tasa de éxito y las solicitudes fallidas, de modo que los números reflejen lo que experimentaría una carga de trabajo real. Ese es el estándar que nos exigimos a nosotros mismos, y el que te invitamos a exigirnos. Puedes revisar la [metodología de benchmarking](/blog/how-we-benchmark-rpc-performance) completa. ## El objetivo: infraestructura tan rápida que desaparece La mejor infraestructura es la que nadie nota. Cuando la latencia es lo suficientemente baja y la confiabilidad lo suficientemente alta, la wallet simplemente carga, el swap simplemente confirma, y el backfill simplemente termina. Ninguna capa de este stack resuelve la latencia por sí sola, pero juntas suman esa experiencia. Comprueba los números por ti mismo. Compara proveedores en la [página de benchmarks de Alchemy](/benchmarks), y lee exactamente [cómo medimos el rendimiento de RPC](/blog/how-we-benchmark-rpc-performance) para que puedas evaluar el método, no solo el resultado. Cuando estés listo para construir sobre esto, [empieza gratis](https://dashboard.alchemy.com/signup/). ## Preguntas frecuentes **¿Qué causa la latencia de RPC?** La latencia de RPC proviene de varias fuentes independientes: la sobrecarga en el camino de la solicitud en el punto de entrada, el tránsito evitable entre servicios internos, el ruteo ineficiente, los picos de tráfico, el retraso operativo de la chain y los nodos, los cuellos de botella específicos de cada carga de trabajo, y la medición incompleta. Como las causas son independientes, ninguna solución individual las elimina todas. **¿Puede una sola optimización resolver la latencia de RPC?** No. Corregir una sola causa simplemente desplaza el cuello de botella hacia el siguiente. Reducir la latencia de forma confiable requiere invertir en cada capa del camino de la solicitud, desde el edge hasta la infraestructura de nodos y la forma en que se mide el rendimiento. **¿Qué es el edge en la infraestructura de RPC?** El edge es el primer punto de entrada controlado por el proveedor al que llega una solicitud, la puerta de entrada del tráfico RPC. Manejar el establecimiento de conexión, la autenticación y el ruteo ahí, en lugar de más adentro en el stack, elimina la sobrecarga fija que cada solicitud tendría que pagar de otra forma. **¿Cómo mide Alchemy la latencia de RPC de forma honesta?** Alchemy mide la latencia junto con la tasa de éxito y las solicitudes fallidas, no como un promedio aislado. Esto evita que un número que parece rápido esconda llamadas descartadas o fallidas, de modo que los resultados reflejen lo que realmente experimentaría una carga de trabajo de producción real. **¿Cómo maneja el escalado predictivo los picos de tráfico?** El escalado predictivo prepara capacidad antes de la demanda en lugar de reaccionar después de que comienza un pico. Esto es lo que permitió a Usual sostener 30,000 solicitudes por segundo y más de 1,000 millones de solicitudes en 36 horas sin que la latencia se degradara durante el aumento. **¿Por qué el rendimiento de las consultas archival de Solana es un problema aparte?** Las consultas archival extraen rangos grandes de estado histórico, lo cual es un trabajo pesado, y el throughput alto de Solana hace que esos rangos sean aún más grandes. La infraestructura archival construida a medida es lo que mantiene rápidas estas consultas, como se vio con las consultas archival de Solflare, hasta 20x más rápidas.