Escalar ràpid l'emmagatzematge en línia per a més de mil milions d'usuaris de ChatGPT (part II)

Tots els productes d'OpenAI necessiten un accés ràpid i fiable a les dades, que proporciona la nostra plataforma d'emmagatzematge, Habitat. Ha de respondre en mil·lisegons a més de mil milions d'usuaris repartits en 40 regions geogràfiques. La nostra infraestructura s'enfrontava a un repte extraordinari: sostenir un creixement explosiu i nous casos d'ús mentre continuàvem millorant la fiabilitat, el rendiment i la rapidesa dels desenvolupadors de producte. Resoldre aquest repte requeria replantejar el disseny i el funcionament de la nostra plataforma d'emmagatzematge en línia. Avaluàvem constantment els compromisos seguint aquest ordre: primer, assolir prou fiabilitat per al trànsit crític dels productes; després, prou rapidesa per als usuaris de tot el món i, finalment, operar amb agilitat a gran escala.

Aquesta sèrie de dues parts explica com vam transformar Habitat, que va començar com una simple biblioteca de client i una base de dades, en una plataforma d'emmagatzematge distribuïda globalment que serveix més de 500 petabytes de dades. La part I se centrava en l'evolució d'Habitat d'un client Python a un servei. També explicava les tècniques que ens van permetre portar un servei basat en Python molt més enllà del que molts considerarien viable.

En aquest article, la part II, expliquem com vam escalar el component d'emmagatzematge subjacent: Azure Cosmos DB. Gràcies a una col·laboració estreta amb l'equip d'Azure, vam arribar a un enfocament multiarrendatari viable amb contenidors cogestionats i un rendiment de lectura excel·lent a gran escala global.

A mesura que les empreses creixen, els equips d'infraestructura sovint passen de gestionar sistemes d'arrendatari únic a sistemes multiarrendataris. L'arquitectura d'arrendatari únic, en què cada equip d'una àrea de producte manté el seu propi sistema, redueix l'abast dels incidents, delimita fàcilment les responsabilitats i aïlla les càrregues de treball. A mesura que creixen els equips i les àrees de producte, mantenir aquesta arquitectura esdevé costós. L'arquitectura d'arrendatari únic fa que cada equip de producte sigui responsable de planificar la capacitat i sovint comporta un sobreaprovisionament considerable.

En canvi, l'arquitectura multiarrendatària assigna el control a un equip centralitzat de bases de dades, amb més coneixements i experiència per aprovisionar recursos. Però també crea problemes propis, com el dels veïns sorollosos: un arrendatari consumeix una proporció inusualment gran dels recursos en detriment dels altres.

A Habitat vam haver de sospesar tots aquests compromisos per dissenyar un sistema d'emmagatzematge fiable i eficient a gran escala. Avui Habitat és una capa de base de dades multiarrendatària per a molts productes d'OpenAI, però hi vam arribar després d'un recorregut circular: vam passar d'un únic contenidor multiarrendatari d'Azure Cosmos DB a aprovisionar contenidors subjacents d'arrendatari únic, i finalment vam tornar a un contenidor multiarrendatari per defecte. Encara som als inicis de l'arquitectura multiarrendatària d'Habitat: admetem un ampli ventall de casos d'ús, però hem pogut ajornar la inversió en aquest àmbit aprofitant les primitives integrades d'Azure Cosmos DB sempre que ha estat possible.

Abans d'explicar el nostre recorregut amb Azure Cosmos DB, una mica de context bàsic:

• Un compte d'Azure Cosmos DB defineix un conjunt de contenidors i una política de replicació

• Cada contenidor s'aprovisiona amb un rendiment determinat, mesurat en unitats de sol·licitud per segon (RU/s)

• Les dades de cada contenidor s'emmagatzemen amb la fragmentació habitual segons una clau de partició lògica especificada, amb límits documentats d'emmagatzematge i rendiment per clau de partició lògica

• Azure Cosmos DB distribueix les claus de partició lògica entre un nombre menor de particions físiques subjacents. Les divideix en diverses particions físiques quan l'emmagatzematge supera un llindar o quan el contenidor en necessita més per sostenir el rendiment aprovisionat

Inicialment deixàvem passar qualsevol càrrega dels clients i confiàvem en el límit declarat de 10 mil RU/s per clau de partició lògica per exercir contrapressió. Al principi també fèiem servir un únic contenidor predeterminat d'Azure Cosmos DB a cada compte. Això funcionava prou bé, però va resultar problemàtic per diversos motius:

Arran de les primeres decisions sobre l'API, vam exposar directament als clients la selecció de la clau de partició lògica. Per això tenim col·lisions freqüents en claus de partició habituals, com user_id o workspace_id, entre diferents casos d'ús dels productes. Com que aquests casos d'ús compartien els límits d'Azure Cosmos DB sobre les mateixes claus de partició lògica, el disseny limitava el rendiment global per a cada usuari.

Abans de passar a Habitat i Azure Cosmos DB, un problema habitual en escalar Postgres era que les nombroses sol·licituds d'una organització o clau amb molta activitat —un arrendatari que generava una càrrega desproporcionadament alta— podien fer caure tota la base de dades. Vam dedicar un esforç col·lectiu considerable a desar aquestes claus a la memòria cau i a incorporar concessions temporals en cas de fallada de memòria cau, perquè la càrrega resultant no saturés la base de dades subjacent.

Tot i que els límits documentats de mida de les dades i rendiment s'apliquen a les claus de partició lògica, és a la partició física on realment es fan complir. A la pràctica, això vol dir que les particions lògiques no poden arribar a les 10.000 RU/s. En lloc d'això, comparteixen els límits de la partició física amb totes les altres claus de partició lògica que hi estan allotjades.

Això permetia que els veïns sorollosos afectessin moltes claus de partició lògica sense cap relació entre si: càrregues de treball sobre dades de funcions de producte minoritàries alteraven els processos bàsics d'inici de sessió i registre.

El límit de rendiment d'una partició física també és variable i depèn del rendiment total assignat al contenidor d'Azure Cosmos DB. El rendiment aprovisionat del contenidor es distribueix de manera aproximadament uniforme entre les seves particions físiques.

A mesura que creix el volum de dades, les particions físiques es divideixen: augmenta el nombre total de particions, però el rendiment total aprovisionat no canvia. El resultat és que el límit de rendiment efectiu per partició disminueix a mesura que augmenta la mida de les dades.

En els casos d'ús que requereixen més emmagatzematge, de tipus blob, això crea un escenari de fallada en què el simple creixement de les dades emmagatzemades redueix la capacitat de rendiment de les càrregues actives, encara que la taxa de sol·licituds i l'ús es mantinguin estables.

Els contenidors separats ajuden a resoldre parcialment aquests límits de les claus de partició i els problemes dels veïns sorollosos. Si fem servir contenidors separats, podem assignar particions físiques independents a cadascun, i només les càrregues del mateix contenidor poden actuar com a veïns sorollosos o solapar-se en l'espai de claus de partició. Com a contrapartida, aprovisionar contenidors nous té un cost addicional: cadascun requereix una planificació individual de capacitat. Per això volem crear-los només quan tingui sentit separar un servei o un cas d'ús.

Vam començar a fer servir contenidors d'Azure Cosmos DB separats per als nous casos d'ús més crítics que requerien un aïllament fort. Juntament amb un script per gestionar les particions febles sincronitzant el rendiment total aprovisionat de cada contenidor amb el seu nombre de particions físiques, això ens va permetre evitar gairebé tots els problemes que teníem.

Tanmateix, com que havíem començat amb un contenidor predeterminat, molts casos d'ús crítics heretats hi continuaven atrapats si no migràvem les dades. Per protegir els serveis crítics que encara depenien de dades del contenidor compartit predeterminat, sovint recomanàvem als equips que creessin contenidors separats per als serveis nous o les funcions importants dels productes. A mesura que creixíem, augmentaven tant la pressió sobre el contenidor predeterminat com els incidents en producció. Vam començar a aprovisionar contenidors per a qualsevol servei nou o funció important d'un producte, només per protegir el contenidor predeterminat de més càrrega.

Això ens va estalviar moltes caigudes generals del lloc i va limitar l'abast dels incidents a la degradació de funcions o serveis. Tanmateix, el cost addicional d'aprovisionar contenidors nous va acabar passant-nos factura:

A l'antic contenidor compartit predeterminat, era poc probable que un nou cas d'ús que passés de 0 a 1 milió de QPS alterés significativament l'ús agregat total. En canvi, en un contenidor aïllat, un nou cas d'ús que passés de 0 a 1 milió de QPS podia representar una càrrega 1.000 vegades superior a la de referència, que corresponia només a les proves d'ús internes.

Amb els contenidors dedicats, els equips havien de recordar-se d'aprovisionar-los amb antelació al nivell de rendiment previst per als llançaments. Sovint els equips de producte desplegaven les funcions en producció i s'oblidaven d'ampliar-ne la capacitat prèviament, i el dia del llançament ens trobàvem en sales de gestió d'incidents greus intentant ampliar els contenidors a última hora.

La combinació de càrregues és un avantatge fonamental dels sistemes multiarrendataris que perdem amb aquesta estratègia de contenidors a canvi d'un millor aïllament.

Amb el temps, supervisar l'ús dels contenidors dedicats també requeria un coneixement profund del producte per saber quan canviaria o creixeria el trànsit.

Podem proporcionar un script bàsic del pla de control per augmentar el rendiment aprovisionat de cada contenidor segons les tendències de creixement. Però, sense un creixement agregat estable, dimensionar-los correctament va acabar implicant pràcticament tots els equips de producte d'OpenAI en la planificació de capacitat.

Això no va escalar bé des del punt de vista organitzatiu: l'atenció que cada equip responsable d'un servei dedicava a l'aprovisionament d'Azure Cosmos DB variava molt.

A mesura que l'organització creixia, era més difícil gestionar aquells problemes operatius a una escala cada vegada més gran. La manca d'un únic equip central encarregat de la planificació va fer que molts equips planifiquessin malament. Per això vam acabar tornant a una solució multiarrendatària i vam col·laborar estretament amb l'equip d'Azure per resoldre els problemes originals mitjançant un disseny d'arrendament compartit:

Limitar primer les claus amb més activitat impedeix que els veïns sorollosos consumeixin tot el rendiment disponible d'una partició física. Això redueix l'efecte de veí sorollós, en què una sola clau amb molta activitat pot afectar tot el lloc.

De manera semblant, la QoS per nivells de sol·licitud impedeix que les càrregues fora de línia, com les insercions massives o les extraccions de dades, consumeixin tot el rendiment d'una partició física. Si assignem una prioritat més baixa a les sol·licituds d'aquestes càrregues, es limiten primer, cosa que evita limitar les sol·licituds interactives de més prioritat que atenen els usuaris finals.

Azure Cosmos DB ja disposava d'un mode sense servidor que hauria resolt el problema de les particions febles que teníem amb el mode aprovisionat. Però tenia un inconvenient important: només escalava segons l'ús d'emmagatzematge i limitava l'ús de RU a 5 mil RU/s per partició física. Això resoldria el problema de les particions febles, però ens impediria ampliar els casos d'ús amb un consum intensiu de RU.

L'equip d'Azure Cosmos DB va crear per a nosaltres un nou mode sense servidor millorat, que permetia escalar cada partició física fins a 10 mil RU/s i afegia divisions basades en l'ús de RU a les basades en l'ús d'emmagatzematge. Això ens va permetre deixar de supervisar i ampliar els contenidors manualment.

Amb aquests canvis hem pogut tornar a un únic contenidor compartit, cosa que ha simplificat molt la planificació de capacitat, tant inicial com continuada, dels equips de producte, tot mantenint l'aïllament entre càrregues de treball. Des d'aleshores, en els mesos que han passat, no hem tingut cap incident d'aprovisionament ni de veïns sorollosos, malgrat l'acceleració del desenvolupament de productes.

Quan les empreses arriben a l'escala d'OpenAI, els serveis gestionats es tornen menys "gestionats". Moltes càrregues de treball esdevenen casos atípics dins la infraestructura del proveïdor del núvol. A mesura que OpenAI es convertia en un dels usuaris més grans d'Azure Cosmos DB, operar-lo amb èxit requeria un model diferent: proves i taulers compartits, canals directes entre equips d'enginyeria i responsabilitat conjunta sobre els tipus de fallades que només apareixen a la nostra escala. Avui, el nostre compte més gran d'Azure Cosmos DB emmagatzema desenes de petabytes de dades i atén més de 20 milions de QPS. Que sapiguem, som l'única empresa que ha desplegat Azure Cosmos DB a aquesta escala.

A finals de 2024, una interrupció regional va deixar clar per què calia aquesta col·laboració. Un tall de subministrament elèctric va afectar la regió principal d'Azure d'un dels nostres comptes més grans d'Azure Cosmos DB. En la commutació per error que en va resultar, ens vam adonar que els comptes més grans trigarien diverses hores a passar a una regió secundària, una operació que ni el nostre equip ni el d'Azure Cosmos DB havien provat a la nostra escala.

Aproximadament un mes després, en retornar aquells comptes a la regió original, vam provocar una altra interrupció greu. Una allau de connexions cap a la regió original en va saturar la passarel·la d'Azure Cosmos DB. Una peculiaritat de la gestió de les commutacions per error del client d'Azure Cosmos DB en mode passarel·la va fer que tots els clients establissin connexions i enviessin sol·licituds immediatament a la regió original, tot i que només hi havia tornat una part de les particions físiques.

En cada interrupció, tant OpenAI com Azure van aplicar els seus processos de gestió d'incidents, van identificar diverses causes arrel i van desplegar correccions. Però aquestes interrupcions eren símptomes d'un problema sistèmic més ampli en la manera com el nostre equip i el d'Azure Cosmos DB operaven i feien proves. Al principi, aprofitar els serveis gestionats ens va permetre avançar ràpidament i centrar-nos en els objectius de negoci. A gran escala, els serveis gestionats ho són menys i requereixen una integració profunda amb el proveïdor a tots els nivells, des del disseny fins a les operacions.

Avui, els equips d'enginyeria d'Habitat i Azure supervisen conjuntament totes les capes d'Habitat, des de les nostres capes de servei fins a les d'emmagatzematge físic d'Azure Cosmos DB. Operem i provem els canvis en un compte d'Azure Cosmos DB de la mateixa mida que el de producció, però que no és de producció. Provem i millorem els SDK conjuntament i determinem les millors pràctiques per escalar i dimensionar els nostres comptes d'Azure Cosmos DB. Els equips d'enginyeria tenim accés directe els uns als altres a través de Teams i fins i tot hem habilitat maneres d'enviar-nos alertes directament sense passar pels nivells de suport.

Durant l'últim any hem fet una gran feina conjunta per millorar l'escalabilitat del pla de control i de la passarel·la d'Azure Cosmos DB. Hem afegit protecció contra la sobrecàrrega i memòria cau per a diverses metadades d'Azure Cosmos DB a la passarel·la per protegir-ne la partició de metadades; hem reduït la pressió de la nostra flota de processos habitat-service en Python mitjançant l'agrupació de connexions i una reutilització més gran d'aquestes; hem ubicat les càrregues de treball juntes sempre que ha estat possible, i hem aïllat les càrregues crítiques de les que s'executen fora de línia mitjançant VPC diferents.

Aquest grau de col·laboració en enginyeria ha estat essencial per a l'estabilitat del nostre Azure Cosmos DB durant l'últim any. Qualsevol sistema prou gran o crític requereix aquest tipus de treball en equip: superar les barreres entre àrees de responsabilitat i treballar més enllà dels límits de cada organització.

Com vam explicar a la part I, la nostra filosofia bàsica és: fer que funcioni, fer que sigui ràpid i fer que sigui econòmic. Primer la fiabilitat, després el rendiment i, finalment, l'eficiència. Habitat s'havia convertit en una infraestructura crítica per a OpenAI, de manera que la primera prioritat era fer-lo fiable. A mesura que el sistema s'estabilitzava el 2025 i OpenAI s'expandia arreu del món, la latència es va convertir en el següent obstacle per als usuaris i els equips de producte.

La capacitat de còmput i la d'emmagatzematge sovint es trobaven en regions diferents, cosa que feia inevitables les sol·licituds entre regions.

La latència variava molt segons on s'emmagatzemaven les dades i des d'on s'atenia la sol·licitud. Perquè les sol·licituds a Habitat fossin ràpides, els desenvolupadors de producte recorrien a memòries cau addicionals al client, agrupaven sol·licituds, minimitzaven les lectures i escriptures a la base de dades i treien feina del camí crític sempre que podien. Tot i que això va donar lloc a dissenys de producte interessants i més resistents als problemes de la base de dades, també va fer els productes més complexos i en va alentir les iteracions. No complíem, doncs, l'objectiu d'Habitat de facilitar un desenvolupament ràpid sense haver de conèixer la base de dades.

Aquesta ha estat una de les nostres grans prioritats el 2026, i hem desenvolupat una estratègia per capes per optimitzar el rendiment de les lectures, que representen més del 90 % de les sol·licituds a Habitat:

Tenim diversos comptes d'Azure Cosmos DB en diferents regions d'Azure arreu del món per als usuaris amb requisits d'ubicació de les dades. Fins i tot per als usuaris sense requisits estrictes d'ubicació de les dades, situar-les a prop seu també millora l'experiència gràcies a una latència més baixa.

A la pràctica, no ho podem fer de manera generalitzada fora dels casos d'ús amb requisits d'ubicació de les dades, perquè l'emplaçament està condicionat per la capacitat física del núvol. Per la mida dels nostres conjunts de dades, moltes regions no poden allotjar l'enorme volum d'emmagatzematge que els correspondria proporcionalment al seu trànsit d'usuaris.

A les regions amb capacitat limitada de centres de dades, energia o refrigeració, de vegades hem de triar: reservar capacitat per a emmagatzematge local i reduir la latència d'Habitat, o fer-la servir per ampliar el còmput que atén les sol·licituds i encaminar les d'emmagatzematge més lluny.

Per això, les decisions d'emplaçament sovint impliquen un compromís de producte entre: A) optimitzar la latència per a diferents productes i grups d'usuaris, i B) la capacitat bruta d'emmagatzematge i còmput.

Per a les càrregues en què la latència és més crítica, com les metadades d'autenticació necessàries en cada sol·licitud, reduïm el temps d'anada i tornada (RTT) entre el còmput i Habitat mitjançant comptes d'Azure Cosmos DB molt replicats, amb moltes regions secundàries. Alguns comptes es repliquen a les 40 regions d'Azure des d'on atenem trànsit; d'altres, almenys a una regió per continent.

Hem hagut d'incorporar a Habitat una capa transparent de trasllat de dades i encaminament abans del que volíem, per poder moure conjunts de dades entre comptes amb diferents topologies de replicació.

Tanmateix, aquest enfocament també està condicionat, en última instància, per la capacitat i, per tant, es limita a uns quants conjunts de dades seleccionats expressament.

Les càrregues d'Habitat són majoritàriament de lectura: les aplicacions recuperen constantment configuracions, estats i altres propietats. Una proporció desmesurada del trànsit correspon a un conjunt de treball relativament petit de tipus als quals s'accedeix sovint. Això fa que el sistema sigui especialment adequat per a la memòria cau distribuïda. Tot i que la memòria cau millora el rendiment en infraestructures d'una sola regió, els beneficis es multipliquen quan es treballa entre regions, ja que pot "amagar" la latència entre elles.

Hem integrat a Habitat una capa de memòria cau distribuïda de consulta lateral. Desa una còpia dels objectes i les arestes consultats recentment en servidors Valkey situats a la nostra infraestructura, a prop d'on es processen les sol·licituds dels usuaris. Normalment, aquestes memòries cau fan servir un temps de vida (TTL) que busca un equilibri entre la taxa d'encerts i l'obsolescència de les dades. Els TTL curts redueixen l'obsolescència, però també els beneficis de la memòria cau, perquè els elements hi caduquen ràpidament i cal recuperar-los més sovint. Els TTL més llargs milloren la taxa d'encerts, però serveixen dades obsoletes durant més temps, cosa que perjudica l'experiència d'usuari i fa imprevisible el comportament del producte.

Un altre enfocament és executar operacions d'invalidació explícites quan l'aplicació escriu sobre les mateixes dades subjacents. Això millora molt l'actualització de les dades en memòria cau, però pot ser difícil d'implementar correctament. A més, continua exposat a casos límit, com les fallades parcials, que deixen la memòria cau obsoleta. Els desplegaments multiregionals agreugen aquests problemes: les xarxes entre regions són menys fiables i es produeixen condicions de cursa entre la memòria cau i la replicació de l'emmagatzematge subjacent. Complementar-ho amb TTL limita l'obsolescència màxima, però manté el mateix compromís inherent als TTL que hem explicat abans.

Hem adoptat un enfocament d'invalidació més avançat, seguint l'exemple de sistemes com TAO de Meta. La memòria cau integrada d'Habitat es basa en la captura de canvis de dades (CDC) mitjançant el flux de canvis d'Azure Cosmos DB per propagar invalidacions arreu del món en segons, amb taxes d'encerts altes i poca obsolescència. Un servei de la nostra infraestructura consumeix aquest flux de canvis i executa invalidacions a les memòries cau locals quan s'actualitzen les dades subjacents. Això provoca una fallada de memòria cau en la lectura següent, i la memòria cau s'omple amb la versió més recent de les dades.

També hem reduït molt la latència eliminant sobrecàrrega del mateix servei Habitat: hem reescrit el codi en Rust, que ofereix més rendiment que el Python original.

En conjunt, aquests canvis han reduït el p50 de latència de lectura a escala mundial d'uns 120 ms a uns 10 ms: una millora de 12 vegades des que vam començar a centrar-nos en el rendiment a principis d'any.

Tot i que la memòria cau ha reduït molt la mediana de latència, les sol·licituds més lentes encara requereixen recuperar dades que no són a la memòria cau des de l'emmagatzematge subjacent, sovint en regions llunyanes. A mesura que disposem de més capacitat i millorem l'eficiència de l'emmagatzematge, ens proposem abordar un repte més fonamental: situar les dades, des del principi, més a prop d'on es consultaran.

Una CDC fiable i escalable —que propagui els canvis de la base de dades als sistemes posteriors— és essencial, i no només per a l'estratègia de memòria cau d'Habitat. Milions de canvis capturats per segon, en milers de contenidors i milions de particions, passen per més de cent temes de Kafka. També alimenten índexs secundaris amb consistència eventual, canals de trasllat de dades, analítica fora de línia i altres funcions de producte en temps real. A mesura que la infraestructura subjacent s'ha expandit arreu del món, escoltar els canvis a les files s'ha tornat cada vegada més complex. Si un client vol registrar una funció de retorn que s'executi cada vegada que canvien files del seu tipus, primer ha de determinar, entre altres coses, quins comptes i contenidors de Cosmos contenen les seves dades i quin desplegament del servei CDC escolta aquests contenidors a cada regió. També ha de dimensionar correctament la flota de processos de treball de CDC, Kafka i el seu consumidor. La nostra plataforma CDC vol estalviar tota aquesta complexitat als desenvolupadors de producte i oferir-los una interfície senzilla: els clients registren la funció que volen que es cridi quan canvien les seves files i nosaltres ens encarreguem de tota la infraestructura i l'escalabilitat.

Un pla de control intern comprova contínuament que es capturin els canvis de tots els contenidors necessaris, selecciona de quines regions de Cosmos cal llegir i distribueix eficientment la feina entre milers de processos de treball en diverses regions geogràfiques. L'ús de regions de rèplica i de lectures del flux amb menys prioritat protegeix el trànsit d'Habitat sensible a la latència de les càrregues de captura en segon pla. En una flota tan gran, es produeixen contínuament caigudes de processos de treball, problemes de contenidors, errors del magatzem de concessions temporals, configuracions no vàlides i fallades de destinació. Hem reforçat el cicle de vida dels processos de treball de CDC i la gestió de concessions temporals, hem aïllat les fallades entre fluxos i hem creat salvaguardes per als canvis de configuració i els desplegaments. Fem servir cues de missatges no lliurats per evitar que les fallades permanents de lliurament bloquegin el cap de la cua. Tolerem les interrupcions regionals redirigint els lectors a regions alternatives de Cosmos. A la nostra escala, fins i tot hem hagut de modificar l'SDK de CDC d'Azure per fer més eficient la implementació dels punts de control: els agrupem en memòria i només els persistim periòdicament.

Tot i que l'ús intern d'Azure Cosmos DB a Habitat és complex, la seva proposta de valor sempre ha estat amagar els detalls de la infraestructura als desenvolupadors per accelerar el desenvolupament de productes. La nostra plataforma CDC no n'és una excepció.

Un equip petit va poder sostenir una plataforma d'emmagatzematge en ràpid creixement mantenint l'API d'emmagatzematge deliberadament limitada, continuant escalant el servei Python i prioritzant els reptes d'enginyeria més urgents. Ens vam centrar primer en la fiabilitat del trànsit crític dels productes, després en el rendiment de lectura per als usuaris de tot el món i, finalment, en l'eficiència operativa a gran escala. Aquest enfocament va permetre un creixement ràpid i nous casos d'ús, alhora que millorava la fiabilitat, el rendiment i la rapidesa del desenvolupament de productes.

Per escalar Habitat i l'emmagatzematge de converses per als propers mil milions d'usuaris, hem d'abordar la dificultat de replicar les dades a tota la infraestructura a una escala encara més gran. Per anticipar-nos-hi, estem desenvolupant internament un sistema propi d'emmagatzematge en línia a escala d'exabytes, optimitzat per als tipus de dades voluminosos d'Habitat. Aquest sistema en desenvolupament combina el nucli RocksDB Cloud de Rockset amb la replicació basada en Raft. Implementa el mateix model de documents que Azure Cosmos DB, però fa servir emmagatzematge desagregat i replicació física per reduir la capacitat flaix necessària, a canvi d'un pic de QPS més baix.

Si t'interessa treballar en projectes d'infraestructura de dades com aquests a una escala d'avantguarda, consulta les nostres vacants⁠.