OpenAI escala ChatGPT a 1 bi com Azure Cosmos DB, 12x

Introdução

Azure Cosmos DB está no centro do salto de escala do armazenamento do ChatGPT. No novo capítulo sobre o Habitat, a OpenAI informa que já atende mais de 1 bilhão de usuários em 40 regiões, orquestrando dados em mais de 500 petabytes e reduzindo a latência p50 de leituras de aproximadamente 120 ms para cerca de 10 ms, um ganho de 12x. Esses números contextualizam a ambição e o rigor técnico por trás do desenho do Habitat, a camada de armazenamento online que sustenta produtos como ChatGPT e a API. (openai.com)

O artigo técnico Part II descreve como a equipe amadureceu a arquitetura multi-tenant sobre Azure Cosmos DB, recuperou simplicidade operacional com um container compartilhado de alto isolamento, e obteve confiabilidade por meio de coengenharia com a Microsoft. Tudo isso mantendo a promessa de acesso a dados em milissegundos, numa escala inédita para serviços conversacionais. (openai.com)

Por dentro do Habitat, a plataforma de armazenamento

O Habitat nasceu como uma biblioteca Python para facilitar persistência sem que equipes de produto se preocupassem com detalhes de banco. Evoluiu para um serviço centralizado que abstrai roteamento, autorização, criptografia, rate limiting e caches, conectando-se a Azure Cosmos DB, Valkey, blob storage e um pipeline de CDC que alimenta Rockset e outros consumidores downstream. Essa mudança para serviço permitiu governança, observabilidade e segurança consistentes, além de simplificar o desenvolvimento de produtos. (openai.com)

No Part I, a OpenAI relata que o Habitat hoje processa mais de 70 milhões de requisições por segundo e serve mais de 500 petabytes, números que ajudam a explicar por que o time precisou redesenhar fluxos de tráfego, conexões e cache. A migração progressiva de Python para Rust, já atendendo 95 por cento do tráfego, trouxe ganhos de eficiência de CPU e memória, preparando o terreno para as otimizações descritas na segunda parte. (openai.com)

Multi-tenancy que funciona sob pressão

Escalar com um único container multi-tenant em Azure Cosmos DB parecia simples até que choques de “hot keys” e colisões de partição lógica expuseram limites práticos. A equipe então ensaiou um desvio para single-tenant por workload, ganhando isolamento, mas pagando caro em planejamento de capacidade e overprovisioning. A guinada final foi um multi-tenant “por padrão”, com capacidade de mover dados entre contas e containers quando necessário, agora protegido por mecanismos como throttling de hot keys, QoS e um modo serverless aprimorado. (openai.com)

O detalhe crítico está na colaboração com o time do Azure Cosmos DB. Para lidar com partições fracas e picos imprevisíveis, a Microsoft introduziu uma versão melhorada do serverless, elevando o teto de RU por partição física e permitindo splits guiados por uso de RU, não apenas por armazenamento. Essa mudança reduziu drasticamente o trabalho manual de escala e evitou incidentes de “vizinho barulhento”, mesmo com aceleração no ritmo de lançamentos. (openai.com)

Coengenharia com a Microsoft, aprendizados de incidentes

Em operações desse porte, serviços “gerenciados” deixam de ser plug and play. A OpenAI relata que tornou-se um dos maiores usuários de Azure Cosmos DB, com a maior conta armazenando dezenas de petabytes e servindo mais de 20 milhões de QPS. A parceria evoluiu para testes compartilhados, dashboards comuns, canais diretos de engenharia e operação conjunta de camadas que vão do serviço Habitat ao armazenamento físico. (openai.com)

Dois eventos foram pedagógicos. Uma falha regional no fim de 2024 revelou que failovers em contas gigantes levariam horas. Um mês depois, o failback provocou um “carimbo de conexões” que saturou o gateway do Cosmos DB, expondo um comportamento do cliente em modo gateway durante failovers. A resposta incluiu correções nos SDKs, proteção de carga, caching de metadados no gateway e técnicas de pooling e reuse de conexões no fleet Python do Habitat, além de isolamento de workloads críticos em VPCs separadas. (openai.com)

Leituras 12x mais rápidas, em escala global

Com confiabilidade sob controle, a meta de 2026 foi desempenho. O tráfego global forçava jornadas entre regiões, variando a latência conforme a distância entre compute e storage. A resposta veio em três camadas, aplicadas conforme restrições físicas de capacidade em cada região. (openai.com)

• Guardar dados perto dos usuários quando a capacidade permite, priorizando contas altamente replicadas para conjuntos mínimos e ultra críticos, como metadados de autenticação.
• Replicar amplamente apenas os datasets menores e mais sensíveis à latência, até todas as 40 regiões em alguns casos.
• Confiar em caching integrado para o resto, reduzindo RTTs percebidos e suavizando diferenças regionais de capacidade.

O pulo de qualidade veio com um cache de lookaside distribuído, implementado em Valkey, e invalidação impulsionada por change feed do Azure Cosmos DB, propagada globalmente em segundos. Combinado a uma reescrita do proxy crítico em Rust, o conjunto derrubou o p50 global de leitura de aproximadamente 120 ms para aproximadamente 10 ms, um ganho de 12x medido após a virada de foco para performance. (openai.com)

CDC como coluna vertebral da atualidade dos dados

A plataforma de CDC do Habitat captura milhões de mudanças por segundo, em milhares de containers e milhões de partições, alimentando centenas de tópicos Kafka para índices secundários, movimentação de dados e análises quase em tempo real. Para o desenvolvedor de produto, o CDC aparece como uma superfície simples de callbacks em mudanças de linhas, enquanto um plano de controle interno garante captura nos containers certos, gerencia leitores por região e protege tráfego sensível com uso de regiões réplica e leituras de feed com menor prioridade. (openai.com)

Essa abordagem mantém a latência de leitura baixa, preserva frescor e evita acoplamento entre consultas online e workloads analíticos. Para consultas complexas, cada time provisiona seu próprio ambiente Rockset que consome o CDC do Habitat, mantendo o online leve e previsível. (openai.com)

Segurança, isolamento e velocidade de produto

Ao centralizar o acesso a dados no Habitat, a OpenAI reforçou políticas de ACL, auditoria e limites de acesso para times e agentes internos. O modelo de API deliberadamente estreito privilegia consultas simples e custo previsível, evitando explosões de fanout e degraus de latência que costumam surgir em SQL ad hoc sem restrições. Essa escolha arquitetural minimiza riscos operacionais e dá aos times uma via óbvia para demandas analíticas, via CDC, sem impactar o plano de controle transacional. (openai.com)

A reescrita em Rust aproveitou o momento certo. Após esticar o serviço Python ao máximo, o time reporta ganhos substanciais, reduzindo custos e cortando latências médias e de cauda, o que se soma aos efeitos do caching e das réplicas para sustentar a experiência de usuário em milissegundos, mesmo com crescimento agressivo. (openai.com)

O que isso significa para equipes de dados e produto

• Planejamento de capacidade conservador, quando isolado por serviço, tende a desperdiçar recursos em hiperescala. O retorno ao multi-tenant com QoS, throttling de hot keys e serverless baseado em RU mostra que governança centralizada funciona melhor quando há telemetria e limites fortes por workload. (openai.com)
• Caching distribuído só entrega confiabilidade e frescor se a invalidação for tratada como produto de primeira classe. O uso do change feed do Azure Cosmos DB como motor de invalidação global é um padrão replicável em arquiteturas que já contam com captura de mudanças. (openai.com)
• Desenvolver com foco em “fazer funcionar, depois ficar rápido, depois barato” evita otimização prematura e alinha prioridade a impacto visível para usuário. A sequência relatada para o Habitat ilustra bem essa disciplina. (openai.com)

Olhando adiante, o próximo salto em armazenamento

Para continuar escalando a conversa e o histórico dos usuários para o próximo bilhão, a OpenAI já trabalha em um sistema de armazenamento online próprio, em escala de exabytes, voltado a dados volumosos do Habitat. A solução, em desenvolvimento, combina RocksDB Cloud da Rockset com replicação via Raft, mantendo o mesmo modelo de documentos do Azure Cosmos DB, porém usando armazenamento desagregado e replicação física para reduzir necessidade de flash, aceitando menor pico de QPS. (openai.com)

Essa estratégia reconhece limites físicos e de capacidade regionais. Ao colocar dados efetivamente mais perto do consumo e ao mesmo tempo otimizar camadas de cache e replicação, o desenho busca garantir latência previsível sem multiplicar custos de forma descontrolada, algo vital quando serviços atendem mais de 1 bilhão de pessoas. (openai.com)

Casos e táticas que equipes podem aplicar hoje

• Adotar uma superfície de API mínima no plano transacional. Evitar queries de alto fanout reduz riscos de sobrecarga, aproxima o custo do request do seu benefício e deixa claro quando é hora de mandar a complexidade para visões secundárias. (openai.com)
• Implementar cache lookaside com invalidação por CDC, preferindo TTLs como limite superior de staleness, não como único mecanismo de frescor. Essa combinação forma uma rede de segurança contra falhas parciais e variações regionais. (openai.com)
• Usar replicação seletiva para metadados de autenticação e outros conjuntos críticos, enquanto mantém datasets pesados apoiados em cache regional e rotas eficientes. O ganho percebido pelo usuário vem da redução de RTT entre compute e storage. (openai.com)

Conclusão

Escalar armazenamento para mais de 1 bilhão de usuários exige escolhas que equilibram simplicidade de API, disciplina operacional e parceria profunda com o provedor de nuvem. O caso do Habitat mostra como Azure Cosmos DB, aliado a caching distribuído com invalidação via change feed, replicação seletiva e reescrita em Rust, levou a leituras 12x mais rápidas e sustentou crescimento global sem comprometer confiabilidade. (openai.com)

O próximo capítulo, com um sistema próprio em escala de exabytes baseado em RocksDB Cloud e Raft, aponta para uma arquitetura híbrida que preserva o que já funciona e cria espaço para reduzir custos físicos de armazenamento. Para quem constrói produtos de IA, vale observar a fórmula, clareza de limites no plano online, CDC robusto, e replicação e cache usados com parcimônia, metas de latência primeiro, eficiência depois. (openai.com)