A OpenAI revelou nesta sexta-feira, 11 de setembro de 2026, detalhes do Habitat, a plataforma de armazenamento on-line que sustenta acessos a dados usados por ChatGPT, Codex, API e serviços internos. Segundo a empresa, o sistema atende mais de 70 milhões de requisições por segundo, ultrapassa 500 petabytes e dá suporte a produtos usados por mais de 1 bilhão de pessoas por semana. Os números são relevantes, mas foram divulgados pela própria operadora e não constituem auditoria independente.
O relato técnico é mais útil quando lido como uma história de decisões de engenharia. A equipe começou com uma biblioteca Python ligada ao Azure Cosmos DB, transformou essa camada em serviço central, controlou gargalos de latência e conexões e, depois, migrou a maior parte do tráfego para Rust. A lição não é que toda empresa precise copiar essa arquitetura. É que previsibilidade, observabilidade e redução do raio de impacto pesaram tanto quanto desempenho bruto.
O que aconteceu
A OpenAI publicou a primeira parte de uma série técnica sobre como ampliou sua plataforma de armazenamento on-line. O texto apresenta o Habitat como uma camada que esconde dos produtos detalhes de roteamento, autorização, criptografia, serialização, limitação de taxa, conexão, cache e localização dos dados. Para quem usa ChatGPT ou Codex, a consequência aparece de forma indireta: entrar na conta, abrir configurações ou iniciar uma conversa pode exigir muitas leituras antes de a interface responder.
O anúncio não apresenta um novo recurso para o usuário ativar. Também não transforma Habitat em produto comercial disponível separadamente. Trata-se de uma descrição de bastidores, assinada por três integrantes da equipe técnica, sobre uma plataforma interna que foi ampliada enquanto o uso dos produtos crescia.
Quando isso aconteceu
O artigo foi publicado em 11 de setembro de 2026. A OpenAI informa que Habitat começou em meados de 2024 como uma biblioteca Python simples. Em meados de 2025, a abordagem distribuída entre clientes já dificultava mudanças coordenadas. No segundo trimestre de 2026, dois engenheiros, com apoio de Codex e GPT-5.5, reescreveram o serviço em Rust.
A cronologia importa porque os resultados finais misturam etapas diferentes. Python sustentou a evolução inicial e chegou a atender mais de 20 milhões de requisições por segundo. Rust apareceu depois, quando APIs e responsabilidades já estavam mais maduras. Comparar apenas as linguagens apaga o trabalho anterior de desenho, observação e estabilização.
O que é Habitat
Habitat funciona como uma plataforma intermediária entre aplicações e recursos de armazenamento. Em vez de cada equipe decidir sozinha como localizar uma coleção, abrir conexões, aplicar políticas e escolher uma região, ela chama uma interface compartilhada. A plataforma então encaminha a operação para recursos como Azure Cosmos DB, caches Valkey, armazenamento de objetos e serviços de captura de alterações.
A OpenAI afirma que a camada também centraliza políticas de controle de acesso, auditoria e isolamento entre clientes internos. Essa concentração cria um ponto comum para aplicar melhorias, mas também aumenta a criticidade do próprio serviço. Se a camada central falha sem contenção, muitos produtos podem sentir o efeito. O texto descreve mecanismos para reduzir esse risco, não a eliminação dele.
A escala divulgada
Os três números principais são mais de 70 milhões de requisições por segundo, mais de 500 petabytes de dados e produtos usados por mais de 1 bilhão de pessoas por semana, em quase 40 regiões geográficas. A empresa também diz ter crescido mais de dez vezes ao ano durante três anos consecutivos.
Essas métricas não significam que cada pessoa gere a mesma carga nem que 500 petabytes pertençam apenas a conversas do ChatGPT. O diagrama oficial inclui API, Codex, serviços internos, caches, blobs e fluxos derivados. O artigo não abre a composição por produto, tipo de dado, região ou prazo de retenção. Portanto, não é correto converter o total em uma estimativa de dados por usuário.
Da biblioteca ao serviço central
No início, Habitat era uma biblioteca incorporada ao servidor principal do ChatGPT. Ela oferecia operações simples sobre o Cosmos DB e permitia acrescentar cache, compressão e criptografia no cliente. O modelo funcionou enquanto havia menos serviços e mudanças de protocolo podiam ser coordenadas com relativa facilidade.
O problema apareceu quando uma alteração precisava chegar a dezenas de serviços. A equipe descreve uma tentativa de distribuir conjuntos críticos entre contas regionais do Cosmos DB. Roteamento, sinalizador de recurso, observação paralela e correções precisavam ser implantados em todos os clientes. Um rollback de outro time reintroduziu uma versão defeituosa. A resposta foi mover a lógica para um serviço próprio, reduzindo a quantidade de componentes que precisavam mudar a cada correção.
Por que Python permaneceu por mais tempo
A equipe sabia que Python acrescentaria consumo de CPU, memória e latência em uma camada de alto volume. Mesmo assim, escolheu aceitar essa dívida técnica temporária. O objetivo imediato era estabilizar a plataforma, definir APIs e liberar as equipes de produto. Reescrever cedo demais significaria otimizar uma interface ainda em movimento.
Esse ponto contraria uma leitura comum de que desempenho sempre exige começar pela linguagem mais eficiente. No caso relatado, velocidade de evolução e familiaridade venceram na primeira fase. A migração ocorreu quando os custos operacionais cresceram e o contrato do serviço estava mais claro.
Asyncio não elimina trabalho de CPU
O serviço Python usava asyncio para sobrepor operações de entrada e saída. Isso ajuda enquanto uma tarefa espera rede ou banco, mas não transforma uma única thread em várias unidades de CPU executando Python ao mesmo tempo. Habitat também comprime, cifra, calcula checksums, escolhe rotas, verifica dependências e executa tarefas de fundo.
A empresa relata que requisições de cauda, como p99 e superiores, podiam esperar a coroutine responsável voltar a ser escalonada mesmo depois de o armazenamento responder. Em alta utilização, o atraso do loop chegava a centenas de milissegundos e, em casos extremos, a segundos. A equipe passou a medir diretamente a diferença entre o momento esperado e o momento real de execução de tarefas periódicas.
Um arquivo de configuração virou gargalo
Um dos problemas veio da atualização de configurações de feature flags. Cada processo analisava, a cada minuto e sem variação de horário, um arquivo JSON grande com regras de vários serviços. Como um pod podia executar até oito processos, todos competiam por CPU quase ao mesmo tempo e atrasavam requisições em andamento.
A correção descrita foi específica: reduzir a configuração ao necessário, aumentar o intervalo e adicionar jitter, isto é, espalhar no tempo as tarefas periódicas. O episódio mostra por que atividade de fundo aparentemente pequena precisa aparecer em perfis e traces. O banco pode responder rápido e, ainda assim, a aplicação entregar uma cauda lenta.
Conexões LIFO reforçaram a sobrecarga
Outra falha surgiu no reaproveitamento de conexões do aiohttp. O conector escolhia a conexão devolvida mais recentemente. Durante uma rajada, processos lentos devolviam conexões por último e eram selecionados com maior frequência para o próximo trabalho. O mecanismo concentrava novas requisições justamente nos processos que já estavam sofrendo.
A equipe testou a hipótese limitando o tempo de reutilização e depois alterou o pool para uma ordem FIFO. A mudança interrompeu o ciclo de realimentação e reduziu a diferença de carga entre processos. É um exemplo de falha metaestável: mesmo depois de a rajada terminar, o próprio comportamento do sistema mantém a degradação.
Envoy reduziu a pressão de conexões
Manter muitos processos Python com baixa concorrência por processo ajudava o loop de eventos, mas criava conexões demais com dependências. Uma implantação ou vazamento podia provocar uma manada de conexões e pressionar CPU, rede ou gateway NAT.
A OpenAI diz usar Envoy para concentrar conexões, converter HTTP/1 em HTTP/2, aproveitar multiplexação e aplicar limites e circuit breakers em um ponto comum. Também cita Istio e Envoy para balanceamento mais consciente da carga. Isso não prova que esses componentes sejam a escolha correta para qualquer ambiente. Eles adicionam outra camada que precisa de capacidade, telemetria e operação cuidadosa.
Uma API deliberadamente limitada
Habitat evita consultas arbitrárias, joins e varreduras sem limite na rota on-line. A interface trabalha com objetos e arestas predefinidos e procura manter cada pedido simples, previsível e de custo aproximadamente constante. Consultas complexas ficam visíveis para o cliente porque exigem trabalho adicional.
Essa limitação é um recurso de segurança operacional. Quando qualquer equipe pode escrever uma consulta barata de criar e cara de executar, uma única mudança pode saturar o banco. A plataforma troca flexibilidade por comportamento mais previsível. O preço é que travessias de grafo e análises complexas ficam menos convenientes.
O papel do Azure Cosmos DB
O Azure Cosmos DB aparece como a principal camada de armazenamento on-line descrita na primeira fase do Habitat. Objetos e suas arestas são colocados juntos em partições de armazenamento, enquanto objetos ligados podem permanecer em contas e regiões diferentes. Isso facilita distribuir dados horizontalmente, mas torna travessias longas mais caras.
O artigo não divulga configuração de consistência, quantidade de contas, unidades de requisição, custo, políticas exatas de residência ou topologia completa. Quem quiser entender a tecnologia de forma prática pode consultar a Skill do Bastidores sobre Cosmos DB com Python, que aborda partição, autenticação e consultas sem confundir a documentação pública com a arquitetura interna da OpenAI.
Leituras complexas foram isoladas
Para pesquisas, análises e leituras mais pesadas, Habitat envia mudanças por captura de dados para instâncias isoladas do Rockset, próximas do tempo real. Cada equipe cliente fica responsável por dimensionar a própria instância. Essa separação evita que consultas analíticas disputem recursos diretamente com o caminho que responde ao produto.
Há um custo de fricção. Uma equipe com necessidade complexa precisa solicitar, operar e pagar por outro recurso interno. A OpenAI considera essa barreira aceitável porque mantém simples o caminho padrão e impede que workloads exploratórios comprometam o armazenamento transacional.
A migração para Rust
No segundo trimestre de 2026, a empresa reescreveu o serviço em Rust. O texto afirma que dois engenheiros, Codex e GPT-5.5 concluíram a migração, que a implementação nova já processa 95% das requisições de produção e que Python seria desativado nas semanas seguintes.
Segundo medições internas da OpenAI, Rust ficou seis vezes mais eficiente em CPU e quinze vezes mais eficiente em memória, com latências média e de cauda menores. Esses resultados são específicos do Habitat, da implementação e da carga testada. Eles não permitem concluir que uma aplicação comum obterá os mesmos ganhos apenas trocando de linguagem.
O papel de Codex e GPT-5.5
A OpenAI diz ter apostado que seus modelos de programação tornariam uma migração futura mais viável. O artigo atribui apoio de Codex e GPT-5.5 ao trabalho feito por dois engenheiros. Não detalha quantas linhas foram geradas, quanto tempo seria necessário sem IA, quais partes exigiram reescrita humana nem qual taxa de defeitos apareceu durante a transição.
Portanto, o fato verificável é que a empresa declara ter usado essas ferramentas na migração. A interpretação editorial é que agentes podem reduzir o custo de uma reescrita quando contratos, testes e observabilidade já existem. Isso é diferente de pedir a um agente que descubra sozinho os requisitos de um sistema crítico. A matéria do Bastidores sobre a Agents API e suas responsabilidades de infraestrutura ajuda a separar execução automatizada de governança.
Fato divulgado, análise e limite de evidência
Fato divulgado pela fonte primária: Habitat atende mais de 70 milhões de requisições por segundo, armazena mais de 500 petabytes e sustenta produtos usados por mais de 1 bilhão de pessoas por semana. O serviço Rust responde por 95% do tráfego de produção e apresentou ganhos internos de eficiência sobre a versão Python.
Análise editorial: a história mostra uma sequência disciplinada. Primeiro, a equipe centralizou regras. Depois, mediu atraso de loop, perfilou CPU, corrigiu pools e reduziu fanout. Só então substituiu a implementação. A linguagem foi importante, mas não foi a única causa do resultado.
Limite: a publicação é um relato da própria OpenAI. Não há auditoria externa, séries completas de latência, custo por operação, metodologia detalhada do benchmark ou código do Habitat para reprodução independente.
O que ainda não foi detalhado
A empresa promete uma segunda parte sobre confiabilidade multi-tenant, otimização de leituras e a parceria com Azure Cosmos DB. Permanecem abertas perguntas sobre recuperação de desastre, objetivos de disponibilidade, consistência entre regiões, degradação controlada, testes de falha e critérios para decidir onde um dado deve residir.
Também não há relação direta entre os números agregados e políticas de retenção para cada produto. Armazenamento total não equivale ao conteúdo visível de conversas e não permite inferir, sozinho, como dados pessoais são tratados. Essas respostas precisam vir de documentos específicos de privacidade e controles, não de um artigo de arquitetura.
O que equipes menores podem aprender
A principal lição reaproveitável é reduzir variabilidade no caminho crítico. APIs estreitas, consultas limitadas, políticas centralizadas e isolamento de leituras analíticas tornam o custo mais previsível. Medir apenas média também é insuficiente. Usuários sentem a requisição mais lenta dentro de uma sequência, especialmente quando uma tela depende de dezenas ou centenas de leituras.
Outra lição é tratar tarefas periódicas e pools de conexão como partes da carga. Atualizar configuração, renovar conexões ou executar verificações de saúde pode sincronizar milhares de processos. Jitter, limites e backpressure ajudam, mas precisam ser testados sob rajadas reais.
Checklist prático para uma revisão de arquitetura
- Mapeie quantas leituras e dependências formam uma ação percebida pelo usuário.
- Meça p95, p99 e atraso do event loop, não apenas média e CPU agregada.
- Verifique se tarefas periódicas começam ao mesmo tempo em todos os processos.
- Teste o algoritmo de reutilização de conexões durante rajadas e recuperação.
- Limite consultas imprevisíveis no caminho transacional.
- Isole análise pesada e busca de recursos que atendem o produto on-line.
- Centralize políticas somente quando a camada central tiver observabilidade e contenção proporcionais.
- Antes de uma reescrita, estabilize contratos, testes, métricas e plano de reversão.
Esse checklist não reproduz Habitat. Ele traduz o relato em perguntas aplicáveis a ambientes menores. A decisão correta pode ser manter um monólito bem observado, não introduzir uma malha de serviços. Complexidade precisa resolver um problema medido.
Por que isso importa
Serviços de IA são apresentados pelo modelo que responde, mas a experiência depende de uma cadeia extensa de autenticação, armazenamento, cache, rede, filas e políticas. Ao abrir parte dessa engenharia, a OpenAI mostra que crescimento de produto também é problema de banco de dados e sistemas distribuídos.
O dado mais interessante não é um número isolado. É a mudança de estratégia ao longo do tempo. A empresa aceitou Python para avançar, impôs limites à API para reduzir risco, corrigiu comportamento de pool que amplificava sobrecarga e migrou para Rust quando a economia operacional justificou. Essa sequência oferece uma referência útil, desde que as métricas internas não sejam tratadas como benchmark universal.