Por dentro do Cortex: a engenharia por trás de uma infraestrutura com menos de 50ms e 99,995% de uptime

Conectividade blockchain confiável não é negociável. Cortex é o motor blockchain inteligente que alimenta a plataforma Alchemy: RPC APIs, data APIs, rollups e a infraestrutura por trás do restante da plataforma de desenvolvimento.

Foi construído a partir de princípios fundamentais, treinado em trilhões de requisições e mais de sete anos de dados, com um objetivo: entregar infraestrutura que tenha desempenho confiável em qualquer escala.

O resultado é um tempo médio de resposta abaixo de 50ms, 99,995% de uptime, e throughput que escala para dezenas de milhões de usuários sem migrações, novas ferramentas ou mudanças de configuração do seu lado.

Para uma visão pública comparando provedores, veja os benchmarks de performance de RPC da Alchemy para latência, taxas de sucesso e requisições com falha.

Este post analisa mais de perto as decisões de engenharia por trás do Cortex: o trabalho em nível de sistema em latência, throughput e confiabilidade que torna esses números possíveis.

Como o Cortex reduz a latência?

Colocação de pods com kubernetes affinity

Quando seu app envia uma requisição, ela passa por vários serviços internos antes de receber uma resposta. Cada vez que ela se move de um servidor para outro, isso tem um custo de latência.

Colocação de pods significa posicionar os serviços que se comunicam com mais frequência na mesma máquina física. O Kubernetes suporta regras de affinity que tornam isso possível, de modo que workloads sensíveis à latência rodem juntos em vez de se espalharem por máquinas ou racks diferentes.

O resultado: as requisições permanecem locais, o que reduz saltos de rede e diminui o tempo de resposta.

Roteamento com consciência de localidade no Istio

Mesmo dentro de um único data center, os serviços estão distribuídos entre nodes e racks. O Istio é a camada de rede que gerencia como os serviços internos se comunicam.

Com o roteamento com consciência de localidade, o Istio sabe a localização física de cada instância de serviço e roteia o tráfego para a instância disponível mais próxima sempre que possível. Se o serviço que processa sua requisição estiver rodando no mesmo node, o tráfego permanece ali em vez de atravessar a rede até uma instância mais distante.

Isso reduz saltos de rede desnecessários sem exigir nenhuma mudança no código da aplicação.

Arquitetura de proxy microkernel

À medida que a infraestrutura cresce em complexidade, sistemas fortemente acoplados ficam mais difíceis de alterar com segurança. Atualizar um componente pode introduzir risco no restante da stack.

Uma abordagem microkernel mantém o núcleo pequeno e estável, responsável apenas pelo caminho crítico. Todo o resto, incluindo logging, rate limiting, autenticação e lógica de roteamento, é implementado como componentes modulares sobrepostos.

Nossa camada de proxy fica entre as requisições recebidas e os sistemas de backend. Por ser construída sobre um modelo microkernel, módulos individuais podem ser atualizados e implantados de forma independente sem tocar no caminho central de requisições. Isso facilita iterar rapidamente enquanto reduz o risco de regressões.

Roteamento direto para o data center

Para workloads enterprise, rotear tráfego pela internet pública introduz variabilidade: latência inconsistente, perda de pacotes e caminhos congestionados que mudam com base em condições fora do seu controle.

O roteamento direto para o data center evita isso enviando o tráfego enterprise por caminhos de rede privados e otimizados que se conectam diretamente à nossa infraestrutura. Isso elimina a imprevisibilidade do roteamento público compartilhado e entrega desempenho de baixa latência mais consistente em cada salto.

Como o Cortex escala?

Milhares de servidores bare-metal implantados globalmente

A maior parte da infraestrutura em nuvem roda em máquinas virtuais. A virtualização é flexível, mas adiciona overhead porque CPU, largura de banda de memória e I/O são compartilhados com outros workloads no mesmo host.

Bare-metal significa rodar diretamente no hardware físico, sem hypervisor no meio. Todo recurso é dedicado às suas requisições. Isso elimina a variabilidade de desempenho de ambientes compartilhados e dá ao Cortex throughput consistente sob carga pesada.

Java virtual threads

Lidar com um grande número de requisições concorrentes exige muito do modelo de threading de um servidor. Threads tradicionais no nível do sistema operacional consomem muita memória, e o custo de gerenciar a troca de contexto cresce à medida que a concorrência aumenta.

Java Virtual Threads, introduzidas no Java 21, são threads leves gerenciadas pela JVM em vez do sistema operacional. O custo de criá-las e alternar entre elas é muito menor do que com threads tradicionais, o que permite que uma única máquina lide com muito mais tarefas concorrentes sem o overhead de memória e CPU que normalmente limita o throughput.

Na prática, isso significa uso mais eficiente do hardware existente e mais margem para absorver picos de tráfego sem degradar o desempenho.

Lógica de escalonamento preditivo

O auto-scaling padrão observa um limite, como o uso de CPU, e adiciona capacidade depois que esse limite é ultrapassado. Isso o torna reativo por design: a demanda sobe primeiro, a infraestrutura alcança depois.

Nossa lógica de escalonamento monitora vários sinais ao mesmo tempo, incluindo CPU, memória, I/O de disco e padrões de tráfego, e usa dados históricos para antecipar picos antes que aconteçam. A capacidade é provisionada antes da demanda em vez de depois, o que diminui a diferença entre um aumento de tráfego e a capacidade da infraestrutura de absorvê-lo.

Frota de nodes gerenciada por IA

Nossa frota de nodes é gerenciada por um sistema agêntico totalmente automatizado que cuida de atualizações, testes e monitoramento. Atualizações são detectadas e aplicadas em tempo real, com testes automatizados incorporados ao pipeline, para que upgrades obrigatórios de rede e hard forks nunca sejam perdidos.

Isso melhora o uptime e elimina o risco de atraso humano quando eventos críticos da chain acontecem.

Por que esses sistemas se somam?

Essas não são otimizações isoladas. A colocação de pods reduz a latência. O roteamento com consciência de localidade a reduz ainda mais. A arquitetura microkernel torna possível melhorar ambos sem introduzir instabilidade. O hardware bare-metal dá às Java Virtual Threads os recursos de que precisam para operar de forma eficiente. O escalonamento preditivo garante que a capacidade esteja disponível antes de ser necessária.

Cada camada foi projetada para tornar as camadas acima dela mais rápidas e resilientes. É isso que significa repensar a infraestrutura a partir de princípios fundamentais, e é sobre isso que o Cortex é construído.

Tudo isso roda por baixo dos panos. Não há migração, nem novas ferramentas, nem configuração exigida do seu lado. Continuamos construindo a infraestrutura para que você possa continuar construindo seu produto.

Comece a construir hoje e entre em contato com vendas para preços personalizados, dúvidas sobre integração e mais.

Perguntas frequentes

O que é o Alchemy Cortex?

Cortex é o motor blockchain inteligente que alimenta a plataforma de desenvolvimento da Alchemy, incluindo RPC APIs, data APIs, rollups e infraestrutura. Foi construído a partir de princípios fundamentais e treinado em trilhões de requisições e mais de sete anos de dados para entregar tempos de resposta abaixo de 50ms, 99,995% de uptime, e throughput que escala sem exigir migrações ou mudanças de configuração.

Como o Cortex alcança tempos de resposta abaixo de 50ms?

O Cortex usa colocação de pods com Kubernetes affinity para posicionar serviços que se comunicam com frequência na mesma máquina física, roteamento com consciência de localidade no Istio para direcionar o tráfego para a instância de serviço mais próxima, uma arquitetura de proxy microkernel para desempenho estável no núcleo, e roteamento direto para o data center para tráfego enterprise por redes privadas.

O que é a arquitetura de proxy microkernel do Cortex?

A abordagem microkernel mantém o sistema central de processamento de requisições pequeno e estável, enquanto logging, rate limiting, autenticação e lógica de roteamento são implementados como componentes modulares que podem ser atualizados de forma independente sem tocar no caminho crítico ou introduzir risco no restante da stack.

Como o Cortex lida com o escalonamento de forma diferente?

O Cortex usa lógica de escalonamento preditivo que monitora vários sinais, incluindo CPU, memória, I/O de disco e padrões de tráfego, e usa dados históricos para provisionar capacidade antes dos picos de demanda em vez de reagir depois que limites são ultrapassados.

Por que o Cortex usa servidores bare-metal em vez de máquinas virtuais?

Servidores bare-metal rodam diretamente no hardware físico sem hypervisor, dedicando todo recurso às requisições e eliminando a variabilidade de desempenho e o overhead de ambientes virtualizados compartilhados, o que entrega throughput consistente sob carga pesada.

O que são Java Virtual Threads e por que o Cortex as usa?

Java Virtual Threads são threads leves gerenciadas pela JVM em vez do sistema operacional, com custos de criação e troca de contexto muito menores do que threads tradicionais, permitindo que uma única máquina lide com mais tarefas concorrentes sem o overhead de memória e CPU que tipicamente limita o throughput.

Como o Cortex gerencia os upgrades de nodes blockchain?

O Cortex usa um sistema agêntico totalmente automatizado que cuida de atualizações, testes e monitoramento em tempo real, com testes automatizados incorporados ao pipeline para que upgrades obrigatórios de rede e hard forks nunca sejam perdidos, melhorando o uptime e eliminando o risco de atraso humano.

Preciso migrar ou configurar algo para usar o Cortex?

Não, nenhuma migração, nova ferramenta ou configuração é exigida do seu lado; o Cortex roda por baixo dos panos e entrega melhorias de infraestrutura automaticamente enquanto você continua construindo seu produto.