Escalar rapidamente o armazenamento para mais de mil milhões de utilizadores do ChatGPT (Parte II)

Todos os produtos da OpenAI precisam de acesso rápido e fiável aos dados, assegurado pela nossa plataforma de armazenamento, o Habitat. A plataforma tem de responder em milissegundos a mais de mil milhões de utilizadores em 40 regiões geográficas. A nossa infraestrutura enfrentou um desafio extraordinário: suportar um crescimento explosivo e novos casos de utilização, continuando a melhorar a fiabilidade, o desempenho e o ritmo de trabalho dos programadores de produto. Resolver este desafio exigiu repensar a conceção e a operação da nossa plataforma de armazenamento online. Avaliámos constantemente os compromissos a assumir, seguindo esta sequência: primeiro, garantir fiabilidade suficiente para o tráfego crítico dos produtos; depois, rapidez suficiente para utilizadores em todo o mundo; e, por fim, operar com agilidade a uma escala massiva.

Esta série em duas partes explica como transformámos o Habitat, inicialmente uma simples biblioteca cliente e uma base de dados, numa plataforma de armazenamento distribuída globalmente, que disponibiliza mais de 500 petabytes de dados. A Parte I centrou-se na evolução do Habitat de um cliente Python para um serviço. Abordou também as técnicas que nos permitiram levar um serviço baseado em Python muito além do que muitos considerariam viável.

Neste artigo, a Parte II, explicamos como escalámos o componente de armazenamento subjacente: o Azure Cosmos DB. Graças a uma colaboração estreita com a equipa do Azure, chegámos a uma abordagem multi-inquilino viável, com contentores geridos em conjunto e um excelente desempenho de leitura à escala global e massiva.

À medida que as empresas crescem, as equipas de infraestrutura passam frequentemente de sistemas de inquilino único para sistemas multi-inquilino. Na arquitetura de inquilino único, cada equipa responsável por uma área do produto mantém o seu próprio sistema. Isto reduz o alcance das falhas, facilita a delimitação de responsabilidades e isola as cargas de trabalho. À medida que as equipas e as áreas de produto crescem, esta abordagem torna-se dispendiosa. A arquitetura de inquilino único responsabiliza cada equipa de produto pelo planeamento da capacidade e resulta frequentemente num sobreaprovisionamento significativo.

Já a arquitetura multi-inquilino atribui o controlo a uma equipa centralizada de bases de dados, com mais conhecimentos e experiência no aprovisionamento de recursos. Mas a arquitetura multi-inquilino cria os seus próprios problemas, como os de vizinhos ruidosos, em que um inquilino consome uma parcela invulgarmente grande dos recursos em detrimento dos restantes.

No Habitat, tivemos de ponderar todos estes compromissos para conceber um sistema de armazenamento fiável e eficiente em grande escala. Hoje, o Habitat é uma camada de base de dados multi-inquilino para muitos produtos da OpenAI, mas fizemos um percurso circular: começámos com um único contentor multi-inquilino do Azure Cosmos DB, passámos a aprovisionar contentores de suporte de inquilino único e voltámos a usar um contentor multi-inquilino por predefinição. Ainda estamos no início do nosso percurso multi-inquilino no Habitat: suportamos muitos casos de utilização, mas conseguimos adiar o investimento nesta área ao tirar partido das primitivas nativas do Azure Cosmos DB sempre que possível.

Antes de descrevermos o nosso percurso com o Azure Cosmos DB, algum contexto básico:

• Uma conta do Azure Cosmos DB define um conjunto de contentores e uma política de replicação

• Cada contentor é aprovisionado para uma determinada taxa de processamento, em unidades de pedido por segundo (RU/s)

• Os dados de cada contentor são armazenados através da fragmentação habitual por uma chave de partição lógica especificada, com limites documentados de armazenamento e taxa de processamento por chave de partição lógica

• O Azure Cosmos DB distribui as chaves de partição lógica por um número menor de partições físicas subjacentes. Divide estas partições quando o armazenamento ultrapassa um limiar ou quando o contentor precisa de mais partições físicas para sustentar a taxa de processamento aprovisionada

Inicialmente, aceitávamos toda a carga dos clientes, contando com o limite anunciado de 10 mil RU/s por chave de partição lógica para exercer contrapressão. No início, também usávamos apenas um contentor predefinido do Azure Cosmos DB em cada conta. Isto funcionava razoavelmente bem, mas revelou-se problemático por alguns motivos:

Devido a decisões iniciais sobre a API, disponibilizámos diretamente aos clientes a seleção da chave de partição lógica. Como resultado, temos colisões frequentes em chaves de partição comuns, como user_id ou workspace_id, entre diferentes casos de utilização dos produtos. Como estes casos de utilização partilhavam os limites do Azure Cosmos DB nas mesmas chaves de partição lógica, esta conceção restringia a taxa de processamento global para um dado utilizador.

Antes de migrarmos para o Habitat e o Azure Cosmos DB, um problema frequente ao escalar o Postgres era o risco de muitos pedidos de uma organização ou chave muito solicitada — um inquilino a gerar uma carga desproporcionadamente elevada — fazerem cair toda a base de dados. Houve um esforço coletivo significativo para colocar essas chaves em cache e incorporar concessões temporárias (leases) nos casos de ausência na cache, para que a carga daí resultante não sobrecarregasse a base de dados subjacente.

Embora os limites documentados de volume de dados e taxa de processamento se apliquem às chaves de partição lógica, é na partição física que os limites são efetivamente impostos. Na prática, isto significa que as partições lógicas não conseguem atingir 10 000 RU/s. Em vez disso, partilham os limites da partição física com todas as outras chaves de partição lógica alojadas nessa partição física.

Isto permitia que vizinhos ruidosos afetassem muitas chaves de partição lógica sem relação entre si: cargas de trabalho sobre dados de funcionalidades de nicho perturbavam os fluxos essenciais de início de sessão e registo.

O limite da taxa de processamento de uma dada partição física também é variável, dependendo da taxa de processamento total atribuída ao contentor do Azure Cosmos DB. A taxa de processamento aprovisionada para o contentor é distribuída de forma aproximadamente uniforme pelas suas partições físicas.

À medida que o volume de dados cresce, as partições físicas dividem-se, aumentando o número total de partições sem alterar a taxa de processamento total aprovisionada. O resultado é que o limite efetivo da taxa de processamento por partição diminui à medida que o volume de dados cresce.

Nos nossos casos de utilização com maiores necessidades de armazenamento, semelhantes a blobs, isto cria um modo de falha em que o crescimento do armazenamento, por si só, reduz a taxa de processamento disponível para as cargas de trabalho ativas, mesmo quando o ritmo de pedidos e a utilização se mantêm estáveis.

Os contentores separados ajudam a resolver parcialmente estes limites das chaves de partição e os problemas de vizinhos ruidosos. Com contentores separados, cada um pode ter as suas próprias partições físicas independentes. Só as diferentes cargas de trabalho no próprio contentor podem atuar como vizinhos ruidosos ou sobrepor-se no espaço de chaves de partição. Em contrapartida, aprovisionar novos contentores tem custos operacionais: cada contentor exige um planeamento individual da capacidade. Por isso, queremos criar contentores apenas quando a separação por serviço ou caso de utilização faz sentido.

Começámos a usar contentores separados do Azure Cosmos DB para os novos casos de utilização mais críticos, que exigiam um isolamento forte. Combinando esta abordagem com um script que geria as partições fracas, ajustando a taxa de processamento total aprovisionada de cada contentor ao seu número de partições físicas, conseguimos evitar a maior parte dos problemas que enfrentávamos.

No entanto, como tínhamos começado com um contentor predefinido, muitos casos de utilização críticos mais antigos ficaram, infelizmente, presos a esse contentor, a menos que se fizesse uma migração de dados. Para proteger os serviços críticos que ainda dependiam dos dados no contentor predefinido partilhado, aconselhávamos frequentemente as equipas a criar contentores separados para novos serviços ou funcionalidades de produto importantes. À medida que crescíamos, aumentavam a pressão sobre o contentor predefinido e os incidentes em produção. Começámos a aprovisionar contentores para qualquer novo serviço ou funcionalidade de produto de maior dimensão, apenas para proteger o contentor predefinido de mais carga.

Isto evitou muitas interrupções em todo o site, limitando o impacto a falhas e degradações de funcionalidades ou serviços. No entanto, os custos operacionais de aprovisionar novos contentores acabaram por se fazer sentir:

No antigo contentor predefinido partilhado, era pouco provável que um novo caso de utilização que passasse de 0 QPS para 1 milhão de QPS alterasse significativamente a utilização total agregada. Num contentor isolado, porém, um novo caso de utilização que passasse de 0 para 1 milhão de QPS podia representar uma carga 1000 vezes superior à carga de referência, gerada apenas pelos testes de utilização internos.

Com contentores dedicados, as equipas tinham agora de se lembrar de aprovisionar antecipadamente os contentores para a taxa de processamento prevista nos lançamentos. As equipas de produto lançavam frequentemente as funcionalidades em produção sem se lembrarem de aumentar a capacidade antes. No dia do lançamento, acabávamos em salas de resposta a incidentes graves (SEV), a tentar aumentar a capacidade dos contentores à última hora.

Esta é uma vantagem fundamental da combinação de cargas de trabalho em sistemas multi-inquilino, que perdemos em troca de um melhor isolamento com esta estratégia de contentores.

Com o tempo, monitorizar a utilização dos contentores dedicados passou também a exigir um conhecimento profundo do produto para saber quando o tráfego mudaria ou cresceria.

Podemos fornecer um script básico do plano de controlo para aumentar a taxa de processamento aprovisionada de cada contentor com base nas tendências de crescimento. Mas, sem um crescimento agregado estável, ajustar corretamente a capacidade acabava por envolver praticamente todas as equipas de produto da OpenAI no planeamento.

Esta abordagem não acompanhou o crescimento da organização: o cuidado de cada equipa responsável por um serviço com o aprovisionamento do Azure Cosmos DB variava muito.

À medida que a organização crescia, tornou-se difícil lidar com esses problemas operacionais à nova escala. Sem uma única equipa central responsável pelo planeamento, muitas equipas acabavam por planear mal. Por isso, acabámos por regressar a uma solução multi-inquilino e trabalhámos em estreita colaboração com a equipa do Azure para corrigir os problemas originais através de uma arquitetura de partilha entre inquilinos:

Limitar primeiro os pedidos para as chaves mais solicitadas impede os vizinhos ruidosos de consumirem toda a taxa de processamento disponível numa dada partição física. Isto reduz o efeito de vizinho ruidoso, em que uma chave muito solicitada pode afetar todo o site.

De forma semelhante, a QoS com classificação de pedidos por níveis impede que cargas de trabalho offline, como inserções em massa ou extrações de dados, utilizem toda a taxa de processamento de uma dada partição física. Ao atribuir uma prioridade inferior aos pedidos destas cargas de trabalho, são estes os primeiros a ser limitados, evitando a limitação de pedidos interativos de maior prioridade que servem os utilizadores finais.

O Azure Cosmos DB já tinha um modo sem servidor que teria resolvido o nosso problema de partições fracas no modo aprovisionado. No entanto, havia uma grande desvantagem: escalava apenas com base na utilização do armazenamento e limitava a utilização de RU a 5 mil RU/s por partição física. Isto resolveria o problema das partições fracas, mas impedir-nos-ia de escalar casos de utilização com elevado consumo de RU.

A equipa do Azure Cosmos DB criou para nós um modo sem servidor melhorado, que permitia a cada partição física atingir 10 mil RU/s e introduzia divisões baseadas na utilização de RU, além das baseadas no armazenamento. Assim, deixámos de precisar de monitorizar e aumentar manualmente a capacidade dos contentores.

Com estas alterações, pudemos voltar a usar um único contentor partilhado, simplificando significativamente o planeamento de capacidade inicial e contínuo das equipas de produto, sem perder o isolamento entre cargas de trabalho. Nos meses que se seguiram, não tivemos qualquer incidente de aprovisionamento ou de vizinhos ruidosos, apesar da aceleração do desenvolvimento de produtos.

Quando as empresas atingem a escala da OpenAI, os serviços geridos tornam-se menos «geridos». Muitas cargas de trabalho passam a ser casos atípicos na infraestrutura do fornecedor de nuvem. À medida que a OpenAI se tornou um dos maiores utilizadores do Azure Cosmos DB, operá-lo com sucesso passou a exigir uma abordagem diferente: testes e painéis partilhados, canais diretos entre equipas de engenharia e responsabilidade conjunta pelos modos de falha que só surgem à nossa escala. Hoje, a nossa maior conta do Azure Cosmos DB armazena dezenas de petabytes de dados e processa mais de 20 milhões de QPS. Tanto quanto sabemos, somos a única empresa que implementou o Azure Cosmos DB a esta escala.

No final de 2024, uma interrupção regional deixou clara a necessidade desta colaboração. Nessa altura, uma falha de energia atingiu a região primária do Azure de uma das nossas maiores contas do Azure Cosmos DB. Na operação de comutação por falha que se seguiu, percebemos que as nossas maiores contas demorariam várias horas a passar para uma região secundária, algo que nem a nossa equipa nem a do Azure Cosmos DB tinham testado à nossa escala.

Cerca de um mês depois, ao repormos essas contas na região original, provocámos outra interrupção grave. Uma avalanche de ligações à região original sobrecarregou o gateway do Azure Cosmos DB dessa região. Uma particularidade na forma como o cliente do Azure Cosmos DB em modo gateway tratava as comutações por falha levou todos os clientes a estabelecer de imediato ligações e a enviar pedidos para a região original, embora apenas parte das partições físicas tivesse regressado a essa região.

Em cada interrupção, tanto a OpenAI como o Azure seguiram os seus processos de gestão de incidentes, identificando várias causas-raiz e implementando correções. Mas estas interrupções eram sintomas de um problema sistémico maior na forma como a nossa equipa e a do Azure Cosmos DB operavam e testavam. Inicialmente, recorrer a serviços geridos permitiu-nos avançar depressa e concentrar-nos nos objetivos do negócio. Em grande escala, os serviços geridos tornam-se menos geridos e exigem uma integração profunda com o fornecedor do serviço a todos os níveis, da conceção às operações.

Hoje, as equipas de engenharia do Habitat e do Azure monitorizam em conjunto todas as camadas do Habitat, desde as nossas camadas de serviço até às camadas de armazenamento físico do Azure Cosmos DB. Operamos e testamos alterações numa conta do Azure Cosmos DB com a dimensão de produção, mas fora do ambiente de produção. Testamos e aperfeiçoamos os SDKs em conjunto e definimos boas práticas para escalar e dimensionar as nossas contas do Azure Cosmos DB. As nossas equipas de engenharia têm contacto direto através do Teams e até disponibilizámos formas de acionar diretamente alertas entre equipas, sem passar pelos níveis de suporte.

Ao longo do último ano, realizámos um trabalho conjunto substancial para melhorar a escalabilidade do plano de controlo e do gateway do Azure Cosmos DB. Adicionámos proteção contra sobrecargas e cache de vários metadados do Azure Cosmos DB no gateway, para proteger a partição de metadados. Reduzimos a pressão dos nossos processos habitat-service em Python através de pools de ligações e de uma maior reutilização das mesmas. Colocámos cargas de trabalho na mesma localização sempre que possível e isolámos as cargas de trabalho críticas das cargas offline através de VPCs distintas.

Este nível de colaboração em engenharia foi essencial para a estabilidade do nosso Azure Cosmos DB no último ano. Qualquer sistema de dimensão ou importância suficientes exige este tipo de trabalho em equipa: eliminar barreiras entre responsáveis e trabalhar para lá das fronteiras organizacionais.

Como referimos na Parte I, a nossa filosofia central é: primeiro pôr a funcionar, depois acelerar e, por fim, reduzir custos. Primeiro a fiabilidade, depois o desempenho e, por fim, a eficiência. O Habitat tinha-se tornado uma infraestrutura crítica para a OpenAI, pelo que a primeira prioridade era torná-lo fiável. À medida que o sistema estabilizou em 2025 e a OpenAI se expandiu globalmente, a latência tornou-se a limitação seguinte para os utilizadores e as equipas de produto.

A capacidade de computação e a de armazenamento encontravam-se frequentemente em regiões diferentes, tornando inevitáveis os pedidos entre regiões.

A latência variava muito consoante o local de armazenamento dos dados e o local de processamento do pedido. Para garantir o desempenho dos pedidos ao Habitat, os programadores de produto recorriam a cache adicional no cliente, ao agrupamento de pedidos, à redução das leituras e escritas na base de dados e, sempre que possível, à retirada de tarefas do caminho crítico. Embora isto tenha levado a soluções de produto interessantes, mais resistentes a problemas na base de dados, também aumentou a complexidade dos produtos e abrandou a sua evolução. Ficava assim por cumprir o objetivo do Habitat: promover o desenvolvimento rápido de produtos sem exigir conhecimentos sobre a base de dados.

Esta tem sido uma das nossas grandes prioridades em 2026. Desenvolvemos uma estratégia em camadas para otimizar o desempenho das leituras, que representam mais de 90% dos pedidos ao Habitat:

Temos várias contas do Azure Cosmos DB em diferentes regiões do Azure pelo mundo, para utilizadores com requisitos de residência de dados. Mesmo para utilizadores sem requisitos rígidos de residência de dados, colocar os dados perto deles melhora a experiência ao reduzir a latência.

Na prática, não conseguimos fazê-lo de forma generalizada fora dos casos de residência de dados, porque a localização é condicionada pela capacidade física da nuvem. Devido à dimensão dos nossos conjuntos de dados, muitas regiões não conseguem acomodar o enorme volume de armazenamento necessário para a sua quota proporcional de tráfego de utilizadores.

Em regiões com capacidade limitada de centros de dados, energia ou refrigeração, temos por vezes de escolher: reservar capacidade para armazenamento local e reduzir a latência do Habitat, ou usá-la para mais computação de resposta a pedidos e encaminhar os pedidos de armazenamento para mais longe.

Assim, as decisões de localização exigem muitas vezes um compromisso de produto entre: A) otimizar a latência para diferentes produtos e grupos de utilizadores e B) a capacidade bruta de armazenamento e computação.

Nas cargas de trabalho mais sensíveis à latência, como os metadados de autenticação necessários em todos os pedidos, reduzimos o tempo de ida e volta (RTT) entre a computação e o Habitat através de contas do Azure Cosmos DB com elevada replicação em muitas regiões secundárias. Algumas contas replicam para as 40 regiões do Azure onde processamos tráfego; outras replicam para pelo menos uma região por continente.

Tivemos de integrar no Habitat, mais cedo do que desejávamos, uma camada transparente de movimentação e encaminhamento de dados, para podermos mover conjuntos de dados entre contas com diferentes topologias de replicação.

No entanto, esta abordagem também é, em última análise, condicionada pela capacidade e, por isso, está limitada a alguns conjuntos de dados criteriosamente selecionados.

As cargas de trabalho do Habitat são dominadas por leituras: as aplicações obtêm constantemente definições, estado e outras propriedades. Uma parcela desproporcionada do tráfego deve-se a um conjunto de trabalho relativamente pequeno de tipos acedidos com frequência. Isto torna o sistema particularmente adequado à utilização de cache distribuída. A cache melhora o desempenho numa infraestrutura de região única, mas os ganhos multiplicam-se entre regiões, onde pode «ocultar» a latência inter-regional.

Integrámos no Habitat uma camada de cache distribuída do tipo lookaside. Esta guarda uma cópia dos objetos e arestas acedidos recentemente em servidores Valkey, localizados na nossa infraestrutura perto do local onde os pedidos dos utilizadores são processados. Normalmente, estas caches usam um TTL que equilibra a taxa de acertos com o grau de desatualização. TTLs curtos reduzem a desatualização, mas limitam os benefícios da cache, porque os itens expiram rapidamente e têm de ser obtidos com maior frequência. TTLs mais longos melhoram a taxa de acertos, mas fornecem dados desatualizados durante mais tempo, prejudicando a experiência do utilizador e tornando o comportamento do produto imprevisível.

Outra abordagem é executar operações explícitas de invalidação quando a aplicação escreve nos mesmos dados subjacentes. Isto melhora muito a atualidade dos dados em cache, mas pode ser difícil de implementar corretamente. Continua também sujeito a vários casos extremos, como falhas parciais, que deixam a cache desatualizada. As implementações multirregionais agravam estes problemas: as redes entre regiões são menos fiáveis e surgem condições de corrida entre a cache e a replicação do armazenamento subjacente. Complementar esta abordagem com TTLs limita a desatualização máxima, mas mantém o mesmo compromisso inerente ao TTL descrito acima.

Adotámos uma abordagem de invalidação mais avançada, seguindo o exemplo de sistemas como o TAO da Meta. A cache integrada do Habitat usa a captura de alterações de dados (CDC) através do feed de alterações do Azure Cosmos DB para propagar invalidações globalmente em segundos, alcançando taxas de acertos elevadas com pouca desatualização. Um serviço na nossa infraestrutura consome este feed e executa invalidações nas caches locais quando os dados subjacentes são atualizados. Assim, na leitura seguinte, os dados não são encontrados na cache, que é então preenchida com a versão mais recente.

Também reduzimos significativamente a latência ao eliminar sobrecarga no próprio serviço Habitat, reescrevendo o código em Rust, que oferece melhor desempenho do que o Python original.

Em conjunto, estas alterações reduziram o p50 global de leitura de cerca de 120 ms para cerca de 10 ms: uma melhoria de 12 vezes desde que começámos a dar prioridade ao desempenho, no início deste ano.

Embora a cache tenha reduzido drasticamente a latência mediana, os pedidos mais lentos ainda exigem obter dados fora da cache a partir do armazenamento subjacente, muitas vezes em regiões distantes. À medida que disponibilizamos mais capacidade e melhoramos a eficiência do armazenamento, planeamos enfrentar um desafio mais fundamental: colocar os dados, desde o início, mais perto de onde serão acedidos.

Uma CDC fiável e escalável — que propaga alterações da base de dados para sistemas a jusante — é essencial não só para a estratégia de cache do Habitat. Milhões de alterações capturadas por segundo, em milhares de contentores e milhões de partições, passam por mais de uma centena de tópicos Kafka. Alimentam também índices secundários com consistência eventual, pipelines de movimentação de dados, análises offline e outras funcionalidades de produto em tempo real. À medida que a nossa infraestrutura de suporte cresceu globalmente, detetar alterações nas linhas tornou-se cada vez mais complexo. Se um cliente quiser registar uma função de callback a executar sempre que as linhas do seu tipo forem alteradas, tem primeiro de identificar, entre outras coisas, as contas e contentores Cosmos que contêm os seus dados e a instância do serviço CDC que monitoriza esses contentores em cada região. Tem também de dimensionar corretamente os processos de trabalho do serviço CDC, o Kafka e o seu consumidor. A nossa plataforma CDC procura ocultar toda esta complexidade aos programadores de produto, oferecendo uma interface simples onde os clientes registam a função a invocar quando as suas linhas são alteradas. Nós tratamos de toda a infraestrutura e do dimensionamento.

Um plano de controlo interno garante continuamente a captura de todos os contentores necessários, seleciona as regiões Cosmos de onde ler e distribui eficientemente o trabalho por milhares de processos de trabalho em várias regiões geográficas. O uso de regiões de réplica e de leituras do feed com prioridade inferior protege o tráfego do Habitat sensível à latência das cargas de captura em segundo plano. Num parque desta dimensão, ocorrem continuamente falhas nos processos de trabalho, problemas nos contentores, erros no armazenamento de concessões, configurações inválidas e falhas nos destinos. Reforçámos a robustez do ciclo de vida dos processos de trabalho CDC e da gestão de concessões, isolámos falhas entre fluxos e criámos salvaguardas para alterações de configuração e implementações. Usamos filas de mensagens não entregues para evitar que falhas permanentes de entrega bloqueiem o início da fila. Suportamos interrupções regionais ao redirecionar os leitores para regiões Cosmos alternativas. À nossa escala, tivemos até de alterar o SDK de CDC do Azure para tornar mais eficiente a criação de pontos de controlo, agrupando-os em memória e gravando-os apenas periodicamente.

Embora a utilização interna do Azure Cosmos DB pelo Habitat seja complexa, a sua proposta de valor sempre foi ocultar os detalhes da infraestrutura aos programadores de produto para acelerar o desenvolvimento. A nossa plataforma CDC segue o mesmo princípio.

Uma pequena equipa conseguiu sustentar uma plataforma de armazenamento em rápido crescimento ao manter a API de armazenamento deliberadamente restrita, continuar a escalar o serviço Python e dar prioridade aos desafios de engenharia mais urgentes. Concentrámo-nos primeiro na fiabilidade do tráfego crítico dos produtos, depois no desempenho de leitura para utilizadores em todo o mundo e, por fim, na eficiência operacional em grande escala. Esta abordagem permitiu um crescimento rápido e novos casos de utilização, melhorando a fiabilidade, o desempenho e o ritmo de desenvolvimento de produtos.

Para escalar o Habitat e o armazenamento de conversas para os próximos mil milhões de utilizadores, temos de resolver a dificuldade de replicar os dados por toda a nossa infraestrutura, a uma escala ainda maior. Para antecipar esse desafio, estamos a criar internamente um sistema de armazenamento online à medida, à escala dos exabytes, otimizado para os tipos de dados volumosos do Habitat. Este sistema, ainda em desenvolvimento, combina o núcleo RocksDB Cloud da Rockset com replicação baseada em Raft. Implementa o mesmo modelo de documentos do Azure Cosmos DB, mas usa armazenamento desagregado e replicação física para reduzir a capacidade de memória flash necessária, em troca de um pico de QPS inferior.

Se lhe interessa trabalhar neste tipo de projetos de infraestrutura de dados à escala de fronteira, consulte as nossas vagas⁠.