--- title: "Dentro de Cortex: la ingeniería detrás de una infraestructura con menos de 50 ms y 99.995% de uptime" description: "La conectividad blockchain confiable no es negociable. Cortex logra tiempos de respuesta de menos de 50 ms y 99.995% de uptime a escala mediante una arquitectura diseñada a medida: desde hardware bare-metal hasta una flota de nodos administrada por IA." --- # Dentro de Cortex: la ingeniería detrás de una infraestructura con menos de 50 ms y 99.995% de uptime La conectividad blockchain confiable no es negociable. [Cortex](https://www.alchemy.com/cortex) es el motor blockchain inteligente que impulsa la plataforma de Alchemy: [RPC APIs](https://www.alchemy.com/docs/reference/node-api-overview), [data APIs](https://www.alchemy.com/docs/reference/data-overview), [rollups](https://www.alchemy.com/docs/reference/rollups-quickstart), y la infraestructura detrás del resto de la plataforma para desarrolladores. Fue construido desde los principios básicos, entrenado con billones de requests y más de siete años de datos, con un solo objetivo: entregar infraestructura que rinda de manera confiable a cualquier escala. El resultado son tiempos de respuesta promedio menores a 50ms, 99.995% de uptime, y un throughput que escala a decenas de millones de usuarios sin migraciones, nuevas herramientas ni cambios de configuración de tu parte. Para una vista pública que compara distintos proveedores, revisa los [RPC performance benchmarks](https://www.alchemy.com/benchmarks) de Alchemy sobre latencia, tasas de éxito y requests fallidos. Este post examina más de cerca las decisiones de ingeniería detrás de Cortex: el trabajo a nivel de sistemas en latencia, throughput y confiabilidad que hace posibles esos números. ## ¿Cómo reduce Cortex la latencia? ### Colocación de pods con kubernetes affinity Cuando tu app envía un request, ese request pasa por varios servicios internos antes de recibir una respuesta. Cada vez que se mueve de un servidor a otro, paga un costo en latencia. La colocación de pods consiste en ubicar en la misma máquina física los servicios que se comunican con más frecuencia. Kubernetes soporta reglas de affinity que hacen esto posible, de modo que las cargas de trabajo sensibles a la latencia se ejecutan juntas en lugar de distribuirse entre máquinas o racks. El resultado: los requests se mantienen locales, lo que reduce los saltos de red y acorta el tiempo de respuesta. ### Locality-aware routing de Istio Incluso dentro de un mismo centro de datos, los servicios están distribuidos entre nodos y racks. Istio es la capa de networking que gestiona cómo se comunican los servicios internos. Con locality-aware routing, Istio conoce la ubicación física de cada instancia de servicio y enruta el tráfico hacia la instancia disponible más cercana siempre que sea posible. Si el servicio que maneja tu request se ejecuta en el mismo nodo, el tráfico se queda ahí en lugar de cruzar la red hacia una instancia más lejana. Esto reduce saltos de red innecesarios sin requerir cambios en el código de la aplicación. ### Arquitectura de proxy con microkernel A medida que la infraestructura crece en complejidad, los sistemas fuertemente acoplados se vuelven más difíciles de modificar con seguridad. Actualizar un componente puede introducir riesgo en el resto del stack. Un enfoque de microkernel mantiene el núcleo pequeño y estable, responsable únicamente del critical path. Todo lo demás, incluyendo logging, rate limiting, autenticación y lógica de routing, se implementa como componentes modulares en capas superiores. Nuestra capa de proxy se ubica entre los requests entrantes y los sistemas backend. Como está construida sobre un modelo de microkernel, los módulos individuales se pueden actualizar y desplegar de forma independiente sin tocar el core del request path. Esto facilita iterar rápido mientras se reduce el riesgo de regresiones. ### Direct-to-datacenter routing Para cargas de trabajo enterprise, enrutar el tráfico por internet público introduce variabilidad: latencia inconsistente, pérdida de paquetes y rutas congestionadas que cambian según condiciones fuera de tu control. El direct-to-datacenter routing evita esto enviando el tráfico enterprise por rutas de red privadas y optimizadas que se conectan directamente a nuestra infraestructura. Esto elimina la imprevisibilidad del routing público compartido y entrega un rendimiento de baja latencia más consistente en cada salto. ## ¿Cómo escala Cortex? ### Miles de servidores bare-metal desplegados globalmente La mayoría de la infraestructura cloud corre sobre máquinas virtuales. La virtualización es flexible, pero agrega overhead porque el CPU, el ancho de banda de memoria y el I/O se comparten con otras cargas de trabajo en el mismo host. Bare-metal significa correr directamente sobre hardware físico sin hipervisor de por medio. Cada recurso está dedicado a tus requests. Esto elimina la variabilidad de rendimiento de los entornos compartidos y le da a Cortex un throughput consistente bajo carga pesada. ### Java virtual threads Manejar grandes cantidades de requests concurrentes presiona el modelo de threading de un servidor. Los threads tradicionales a nivel de OS consumen mucha memoria, y el costo de gestionar el context switching crece a medida que aumenta la concurrencia. Java Virtual Threads, introducidos en Java 21, son threads livianos gestionados por la JVM en lugar del sistema operativo. El costo de crearlos y cambiar entre ellos es mucho menor que el de los threads tradicionales, lo que permite que una sola máquina maneje muchas más tareas concurrentes sin el overhead de memoria y CPU que normalmente limita el throughput. En la práctica, esto significa un uso más eficiente del hardware existente y más margen para absorber picos de tráfico sin degradar el rendimiento. ### Lógica de escalado predictivo El auto-scaling estándar observa un umbral, como el uso de CPU, y agrega capacidad después de que ese umbral se cruza. Esto lo hace reactivo por diseño: la demanda sube primero, la infraestructura reacciona después. Nuestra lógica de escalado monitorea múltiples señales a la vez, incluyendo CPU, memoria, I/O de disco y patrones de tráfico, y luego usa datos históricos para anticipar picos antes de que ocurran. La capacidad se aprovisiona antes de la demanda en lugar de después, lo que reduce la brecha entre un aumento de tráfico y la capacidad de la infraestructura para absorberlo. ### Flota de nodos gestionada por IA Nuestra flota de nodos es gestionada por un sistema agentic completamente automatizado que se encarga de upgrades, testing y monitoreo. Las actualizaciones se detectan y aplican en tiempo real, con testing automatizado integrado en el pipeline, de modo que los upgrades obligatorios de red y los hard forks nunca se pasan por alto. Esto mejora el uptime y elimina el riesgo de retraso humano cuando ocurren eventos críticos en la chain. ## ¿Por qué estos sistemas se potencian entre sí? Estas no son optimizaciones aisladas. La colocación de pods reduce la latencia. El locality-aware routing la reduce aún más. La arquitectura de microkernel hace posible mejorar ambas cosas sin introducir inestabilidad. El hardware bare-metal le da a Java Virtual Threads los recursos que necesita para operar de forma eficiente. El escalado predictivo asegura que la capacidad esté disponible antes de que se necesite. Cada capa fue diseñada para hacer que las capas superiores sean más rápidas y resilientes. Eso es lo que significa repensar la infraestructura desde los principios básicos, y sobre eso está construido Cortex. Todo esto corre por debajo. No hay migración, ni nuevas herramientas, ni configuración requerida de tu parte. Nosotros seguimos construyendo la infraestructura para que tú puedas seguir construyendo tu producto. [Start building](https://dashboard.alchemy.com/) hoy y [contact sales](https://www.alchemy.com/contact-sales) para precios personalizados, preguntas de integración y más. ## Preguntas frecuentes ### ¿Qué es Alchemy Cortex? Cortex es el motor blockchain inteligente que impulsa la plataforma para desarrolladores de Alchemy, incluyendo RPC APIs, data APIs, rollups e infraestructura. Fue construido desde los principios básicos y entrenado con billones de requests y más de siete años de datos para entregar tiempos de respuesta menores a 50ms, 99.995% de uptime, y throughput que escala sin requerir migraciones ni cambios de configuración. ### ¿Cómo logra Cortex tiempos de respuesta menores a 50ms? Cortex usa colocación de pods con Kubernetes affinity para ubicar en la misma máquina física los servicios que se comunican con frecuencia, locality-aware routing de Istio para dirigir el tráfico a la instancia de servicio más cercana, una arquitectura de proxy con microkernel para un rendimiento estable del core, y direct-to-datacenter routing para el tráfico enterprise a través de redes privadas. ### ¿Qué es la arquitectura de proxy con microkernel de Cortex? El enfoque de microkernel mantiene pequeño y estable el sistema central que maneja los requests, mientras que logging, rate limiting, autenticación y lógica de routing se implementan como componentes modulares que se pueden actualizar de forma independiente sin tocar el critical path ni introducir riesgo en el stack. ### ¿Cómo maneja Cortex el escalado de forma distinta? Cortex usa una lógica de escalado predictivo que monitorea múltiples señales, incluyendo CPU, memoria, I/O de disco y patrones de tráfico, y luego usa datos históricos para aprovisionar capacidad antes de los picos de demanda en lugar de reaccionar después de que se cruzan los umbrales. ### ¿Por qué Cortex usa servidores bare-metal en lugar de máquinas virtuales? Los servidores bare-metal corren directamente sobre hardware físico sin hipervisor, dedicando cada recurso a los requests y eliminando la variabilidad de rendimiento y el overhead de los entornos virtualizados compartidos, lo que entrega un throughput consistente bajo carga pesada. ### ¿Qué son los Java Virtual Threads y por qué los usa Cortex? Los Java Virtual Threads son threads livianos gestionados por la JVM en lugar del sistema operativo, con costos de creación y context-switching mucho más bajos que los threads tradicionales, lo que permite que una sola máquina maneje más tareas concurrentes sin el overhead de memoria y CPU que normalmente limita el throughput. ### ¿Cómo gestiona Cortex las actualizaciones de nodos blockchain? Cortex usa un sistema agentic completamente automatizado que se encarga de upgrades, testing y monitoreo en tiempo real, con testing automatizado integrado en el pipeline para que los upgrades obligatorios de red y los hard forks nunca se pasen por alto, mejorando el uptime y eliminando el riesgo de retraso humano. ### ¿Necesito migrar o configurar algo para usar Cortex? No se requiere migración, nuevas herramientas ni configuración de tu parte. Cortex corre por debajo y entrega mejoras de infraestructura de forma automática mientras tú sigues construyendo tu producto.