Cada produto desenvolvido pela OpenAI depende de acesso imediato e confiável aos dados, seja no momento em que um usuário faz login, ajusta suas preferências no Codex ou inicia uma nova conversa no ChatGPT. Cada uma dessas ações simples na interface pode exigir dezenas ou centenas de consultas independentes aos bancos de dados antes mesmo que a primeira palavra seja gerada na tela. Se essas consultas forem lentas, a experiência de uso parece travada. Se falharem, o serviço para por completo.
Para sustentar essa carga monumental, a OpenAI revelou os bastidores técnicos do Habitat, a plataforma interna de armazenamento online projetada especificamente para permitir que seus produtos acessem informações de maneira veloz e resiliente. Hoje, o Habitat processa mais de 70 milhões de requisições por segundo, atendendo a mais de 1 bilhão de pessoas por semana espalhadas por quase 40 regiões geográficas do planeta, gerenciando um volume superior a 500 petabytes de dados.
A dimensão desse desafio técnico não decorre apenas dos números absolutos, mas do ritmo em que essa expansão precisou acontecer. Enquanto equipes tradicionais de engenharia projetam sistemas para suportar um crescimento de dez vezes ao longo de anos, a OpenAI viu sua demanda crescer mais de dez vezes ano após ano durante três anos consecutivos. Construir o Habitat exigiu decisões táticas de alta precisão para extrair cada gota de desempenho do hardware existente enquanto preparava o terreno para saltos estruturais profundos.
O que é o Habitat e como ele nasceu
O Habitat surgiu em meados de 2024 a partir de um princípio prático: desenvolvedores de produtos não deveriam perder tempo gerenciando bancos de dados. Em seu estágio inicial, a ferramenta era apenas uma biblioteca de cliente escrita em Python que interagia com o servidor principal do ChatGPT. Essa biblioteca conectava as aplicações à base de dados subjacente, o Azure Cosmos DB.
A proposta era simplificar o trabalho dos times de engenharia. Em vez de lidar manualmente com detalhes complexos como consultas de esquemas, roteamento geográfico, autorização, criptografia, serialização de dados, modelagem de tráfego e agrupamento de conexões (connection pooling), os desenvolvedores simplesmente solicitavam o dado à biblioteca. O engenheiro não precisava saber se a informação viria do Azure Cosmos DB, de camadas de cache ou de outros tipos de armazenamento.
A adoção interna foi imediata e espontânea, sem a necessidade de imposições centrais. Conforme novos recursos surgiam, os próprios times podiam colaborar na biblioteca compartilhada, acrescentando suporte para compactação, políticas de criptografia e cache no lado do cliente.
A transição de biblioteca para um serviço centralizado
No entanto, em meados de 2025, o modelo baseado em biblioteca no cliente chegou ao seu limite. À medida que o número de microsserviços da OpenAI disparava, garantir a compatibilidade retroativa de alterações em protocolos tornou-se uma tarefa arriscada e operacionalmente custosa.
Um caso emblemático ilustra bem essa fragilidade. A equipe de infraestrutura pretendia reduzir a área de impacto de possíveis falhas regionais migrando os conjuntos de dados mais sensíveis para contas do Azure Cosmos DB distribuídas em várias regiões. Para viabilizar essa mudança com segurança, foi necessário embutir uma lógica adicional de roteamento no cliente Python, protegida por sinalizadores de recursos (feature flags). Foi preciso coordenar a distribuição com dezenas de serviços diferentes, aguardar a adoção por cada equipe e monitorar o processo durante dias.
Antes de ativar o recurso em produção, a equipe decidiu aplicar técnicas de espelhamento (shadowing) para verificar se o particionamento estava correto, o que demandou mais alguns dias. Logo em seguida, a correção de uma pequena falha exigiu outra rodada de implementação. Quando tudo parecia pronto para a ativação final da sinalização, uma das equipes de produto precisou reverter seu próprio serviço por motivos alheios, voltando acidentalmente para uma versão antiga e falha da biblioteca. O resultado foi exatamente a interrupção que todo o planejamento minucioso pretendia evitar.
Esse episódio deixou claro que depender de uma biblioteca distribuída entre dezenas de clientes gerava um efeito de propagação operacional insustentável. A decisão arquitetural foi clara: desacoplar a lógica de armazenamento e transformar o Habitat em um serviço independente e centralizado.
Com um serviço dedicado, a OpenAI passou a ter um ponto único de controle para implantações, observabilidade e melhorias de plataforma. Qualquer aprimoramento de desempenho implantado centralmente beneficia de imediato todos os produtos da empresa, sem necessidade de atualizar aplicações clientes. Além disso, a centralização criou um perímetro robusto para segurança da informação e privacidade, concentrando em um único ponto as políticas de controle de acesso, registros de auditoria e limites de conexões aos recursos do Azure Cosmos DB, protegendo dados contra acessos indevidos internos, externos e de agentes autônomos.
Artigos recomendados
Desafios de executar um serviço Python em hiperescala
Ao criar o serviço do Habitat, a OpenAI optou conscientemente por manter o código em Python em um primeiro momento, assumindo uma dívida técnica calculada. A prioridade não era minimizar o consumo de memória ou CPU imediatamente, mas destravar os desenvolvedores de produtos e consolidar as APIs centrais da plataforma. Além disso, a liderança de engenharia apostou que a evolução dos próprios modelos de codificação da empresa, como o Codex e os modelos GPT, tornaria viável uma reescrita automatizada no futuro, aposta que se mostraria acertada mais tarde.
Ainda assim, operar um serviço de altíssimo tráfego em Python impôs desafios severos de desempenho, especialmente em relação à latência de cauda (tail latency). Quando uma requisição comum dispara centenas de chamadas ao banco de dados, a chamada mais lenta é a que define a percepção do usuário.
A equipe identificou e superou quatro grandes gargalos nessa fase:
- Atraso no laço do asyncio: O mecanismo de asyncio do Python gerencia concorrência de entrada e saída (I/O), mas o Global Interpreter Lock (GIL) restringe o processamento da CPU a uma única thread por processo. Como o Habitat executa tarefas pesadas de CPU (criptografia, compactação, cálculo de somas de verificação, roteamento e requisições hedged), o laço de eventos sofria atrasos de agendamento de centenas de milissegundos. A solução foi monitorar o atraso do event loop em tempo real, manter cada processo atendendo apenas a poucas requisições simultâneas e escalar massivamente a quantidade de processos worker de Python.
- O bloqueio por configurações de feature flags: O sistema de telemetria e perfilamento revelou que a biblioteca Statsig estava configurada para atualizar regras de produção a cada minuto sem variação aleatória de tempo (jitter). Como cada pod executava até 8 processos Python para aproveitar melhor a CPU, a cada minuto todos os processos congelavam simultaneamente para processar arquivos JSON gigantescos. A correção envolveu o envio de configurações direcionadas e menores, aumento dos intervalos de atualização e inserção de jitter nas tarefas de segundo plano.
- Falha metaestável em pools de conexões: O conector TCP da biblioteca aiohttp adotava por padrão a política LIFO (último a entrar, primeiro a sair) para reaproveitamento de conexões. Durante picos de tráfego, servidores mais lentos demoravam mais para responder e devolviam suas conexões por último. Pela regra LIFO, essas conexões recém-devolvidas eram escolhidas primeiro nas requisições seguintes, direcionando ainda mais tráfego justamente para os nós sobrecarregados em um ciclo destrutivo. A alteração para a política FIFO (primeiro a entrar, primeiro a sair) quebrou esse círculo vicioso, estabilizando a distribuição de carga.
- Efeito thundering herd nos bancos de dados: Com milhares de processos Python em execução, reiniciar serviços ou sofrer pequenos vazamentos de conexão causava saturação instantânea no Azure Cosmos DB e nos gateways de tradução de endereços (NAT). A OpenAI contornou o problema posicionando proxies Envoy na camada intermediária, convertendo conexões HTTP/1 dos processos Python em fluxos multiplexados HTTP/2, estendendo o tempo de vida das conexões e aplicando circuit breakers centralizados.
Por que a arquitetura do Habitat faz menos
Antes do Habitat e da migração para o Azure Cosmos DB, a maior parte dos dados da OpenAI residia em instâncias PostgreSQL. Naquela época, quando as equipes eram menores, era viável revisar manualmente cada consulta SQL e índice antes de enviar o código para produção. Com o crescimento vertiginoso do ChatGPT, esse controle manual tornou-se inviável, transformando consultas SQL caras e complexas na principal causa de quedas de banco de dados.
No modelo relacional tradicional, existe um descompasso perigoso: é muito fácil escrever uma consulta SQL que parece simples no código, mas cuja execução exige junções pesadas e varreduras completas de tabelas. Para evitar que uma única consulta mal projetada derrube a infraestrutura, a OpenAI projetou o Habitat com uma API intencionalmente restrita.
Inspirada na arquitetura TAO desenvolvida pelo Facebook/Meta, a interface do Habitat baseia-se em um modelo NoSQL orientado a objetos e arestas (edges). Os desenvolvedores definem entidades e como elas se relacionam diretamente, mas a plataforma não permite consultas de travessia profunda de grafos nem comandos SQL arbitrários. Cada requisição ao Habitat executa um trabalho constante, simples e altamente previsível.
Para garantir escalabilidade horizontal, o grafo é particionado de modo que um objeto e suas arestas diretas fiquem fisicamente armazenados na mesma partição de armazenamento. Caso uma aplicação precise navegar por múltiplos saltos no grafo, a responsabilidade de orquestrar as requisições sucessivas é transferida para o cliente. Já para casos de uso que realmente necessitam de análises complexas, buscas textuais e agregações pesadas, a OpenAI utiliza Change Data Capture (CDC) para transmitir alterações em tempo quase real do Habitat para instâncias dedicadas do Rockset, isolando completamente o banco operacional de consultas analíticas que poderiam comprometer a disponibilidade do ChatGPT.
A reescrita do serviço em Rust com inteligência artificial
Adiar a reescrita do serviço em Python durante um ano permitiu que a OpenAI concentrasse seus engenheiros nas dores mais urgentes da hiper-expansão. Conforme a infraestrutura amadureceu, o Habitat consolidou-se como o segundo maior serviço em número de núcleos de processamento de toda a empresa e o quarto em consumo de infraestrutura Envoy. No auge, o serviço em Python sustentou picos de 20 milhões de requisições por segundo.
No segundo trimestre de 2026, a empresa concretizou o plano de modernização: com uma equipe enxuta de apenas dois engenheiros humanos, auxiliados intensivamente pelas ferramentas Codex e GPT-5.5, o serviço completo do Habitat foi reescrito na linguagem Rust.
Essa nova versão em Rust já é responsável por processar 95% de todo o tráfego de produção da OpenAI, com a desativação definitiva dos componentes em Python prevista para as semanas seguintes. As medições oficiais demonstram ganhos de eficiência impressionantes: o serviço em Rust é 6 vezes mais eficiente no uso de CPU e 15 vezes mais eficiente no consumo de memória em comparação com o código anterior em Python, além de registrar reduções drásticas nas latências médias e nos extremos de p99.
Essa reformulação consolida a fundação técnica necessária para que o ChatGPT e outros produtos da OpenAI continuem operando de forma estável enquanto a empresa avança em direção a volumes ainda maiores de usuários e inteligência em tempo real.
