Rask skalering av nettbasert lagring for over 1 milliard ChatGPT‑brukere (del II)

Alle OpenAI-produkter trenger rask og pålitelig tilgang til data. Det sørger lagringsplattformen vår, Habitat, for. Den må svare på millisekunder til over 1 milliard brukere fordelt på 40 geografiske regioner. Infrastrukturen vår sto overfor en helt spesiell utfordring: å støtte eksplosiv vekst og nye bruksområder, samtidig som vi fortsatte å forbedre påliteligheten, ytelsen og tempoet i produktutviklingen. For å løse utfordringen måtte vi tenke nytt om hvordan lagringsplattformen vår for nettbaserte tjenester var utformet og driftet. Vi gjorde stadig avveininger etter samme mønster: først bli pålitelige nok for virksomhetskritisk produkttrafikk, så raske nok for brukere over hele verden, og til slutt sikre smidig drift i svært stor skala.

Denne serien i to deler forklarer hvordan vi utviklet Habitat fra et enkelt klientbibliotek og en database til en globalt distribuert lagringsplattform som betjener over 500 petabyte med data. Del I tok for seg Habitats utvikling fra en Python-klient til en tjeneste. Den dekket også teknikkene som lot oss ta en Python-basert tjeneste langt utover det mange ville anse som praktisk gjennomførbart.

I dette innlegget, del II, går vi gjennom hvordan vi skalerte den underliggende lagringskomponenten: Azure Cosmos DB. Gjennom et tett samarbeid med Azure-teamet kom vi frem til en levedyktig flerleietakerløsning med fellesforvaltede containere, med svært god leseytelse i enorm, global skala.

Når selskaper vokser, går infrastrukturteam ofte fra å drifte systemer med én leietaker til systemer med flere leietakere. Med én leietaker, der hvert team for et produktområde vedlikeholder sitt eget system, begrenses konsekvensene av feil. Det gir også tydelige ansvarsgrenser og isolerte arbeidsbelastninger. Etter hvert som teamene og produktområdene vokser, blir dette dyrt å drifte. Enleietakerdrift gjør hvert produktteam ansvarlig for kapasitetsplanlegging og fører ofte til betydelig overdimensjonering.

Flerleietakerdrift gir derimot kontrollen til et sentralt databaseteam med bedre kunnskap og erfaring med ressursklargjøring. Men flerleietakerdrift skaper egne problemer som støyende naboer: én leietaker bruker en uvanlig stor andel av ressursene på bekostning av de andre.

I Habitat måtte vi veie alle disse hensynene mot hverandre for å utforme et pålitelig og effektivt lagringssystem i stor skala. I dag er Habitat et flerleietakerlag for databaser som brukes av mange OpenAI-produkter. Men vi har gått en hel runde: fra én Azure Cosmos DB-container med flere leietakere, via underliggende containere med én leietaker, og tilbake til en flerleietakercontainer som standard. Vi er fortsatt helt i starten av arbeidet med flerleietakerdrift i Habitat. Vi støtter mange bruksområder, men har kunnet utsette investeringer på dette feltet ved å bruke de innebygde grunnfunksjonene i Azure Cosmos DB der det er mulig.

Før vi går gjennom reisen vår med Azure Cosmos DB, litt grunnleggende bakgrunn:

• En Azure Cosmos DB-konto definerer et sett med containere og en replikeringspolicy

• Hver container klargjøres for en bestemt gjennomstrømming, målt i forespørselsenheter per sekund (RU/s)

• Data i hver container fordeles på vanlig måte etter en angitt logisk partisjonsnøkkel, med dokumenterte grenser for lagring og gjennomstrømming per logiske partisjonsnøkkel

• Azure Cosmos DB fordeler logiske partisjonsnøkler på færre underliggende fysiske partisjoner. Disse deles i flere fysiske partisjoner når lagringen overstiger en terskel, eller når containeren trenger flere fysiske partisjoner for å opprettholde den klargjorte gjennomstrømmingen

Opprinnelig slapp vi gjennom all klientbelastning og stolte på at den oppgitte grensen på 10 000 RU/s per logiske partisjonsnøkkel ville gi mottrykk. Da vi startet, brukte vi også bare én standardcontainer for Azure Cosmos DB i hver konto. Dette fungerte godt nok, men viste seg å være problematisk av flere grunner:

På grunn av tidlige API-valg lot vi klientene velge logisk partisjonsnøkkel direkte. Derfor får vi ofte kollisjoner på vanlige partisjonsnøkler, som user_id eller workspace_id, på tvers av ulike bruksområder i produktene. Fordi disse bruksområdene delte Azure Cosmos DB-grensene for de samme logiske partisjonsnøklene, begrenset utformingen den samlede gjennomstrømmingen for en gitt bruker.

Et vanlig problem da vi skalerte Postgres før overgangen til Habitat og Azure Cosmos DB, var at mange forespørsler fra en svært aktiv organisasjon eller mot en mye brukt nøkkel kunne slå ut hele databasen. Én leietaker kunne altså generere en uforholdsmessig høy belastning. Vi la ned en betydelig felles innsats i å hurtigbufre disse nøklene og innføre tidsbegrensede låser ved hurtigbufferbom, slik at belastningen fra slike bom ikke overbelaster den underliggende databasen.

Selv om de dokumenterte grensene for datamengde og gjennomstrømming gjelder logiske partisjonsnøkler, håndheves grensene i den fysiske partisjonen. I praksis betyr dette at logiske partisjoner ikke kan nå 10 000 RU/s. I stedet deler de den fysiske partisjonens grenser med alle andre logiske partisjonsnøkler som ligger på samme fysiske partisjon.

Dermed kunne støyende naboer påvirke mange urelaterte logiske partisjonsnøkler. Arbeidsbelastninger som behandlet data for nisjefunksjoner i produktene, forstyrret grunnleggende innloggings- og registreringsflyter.

Gjennomstrømmingsgrensen for en gitt fysisk partisjon varierer også med den totale gjennomstrømmingen som er tildelt Azure Cosmos DB-containeren. Containerens klargjorte gjennomstrømming fordeles omtrent jevnt over de fysiske partisjonene i containeren.

Når datavolumet vokser, deles fysiske partisjoner. Det totale antallet partisjoner øker, mens den samlede klargjorte gjennomstrømmingen forblir uendret. Resultatet er at den effektive gjennomstrømmingsgrensen per partisjon synker når datamengden vokser.

For de mest lagringskrevende, blob-lignende bruksområdene våre skaper dette en feilsituasjon der lagringsvekst alene reduserer gjennomstrømmingskapasiteten for aktive arbeidsbelastninger, selv om forespørselsraten og bruken er stabile.

Separate containere bidrar til å løse noe av problemet med partisjonsnøkkelgrenser og støyende naboer. Hver separat container kan tildeles egne, uavhengige fysiske partisjoner. Da er det bare arbeidsbelastningene i selve containeren som kan være støyende naboer eller overlappe i partisjonsnøkkelrommet. Ulempen er at klargjøring av nye containere medfører ekstraarbeid – hver container krever individuell kapasitetsplanlegging. Vi ønsker derfor bare å opprette containere der det er en naturlig grense mellom tjenester eller bruksområder.

Vi begynte å bruke separate Azure Cosmos DB-containere for de mest kritiske nye bruksområdene som krevde sterk isolasjon. Sammen med et skript som håndterte svake partisjoner ved å tilpasse den totale klargjorte gjennomstrømmingen i hver container til antallet fysiske partisjoner, gjorde dette at vi stort sett unngikk alle problemene vi hadde stått overfor.

Men siden vi startet med en standardcontainer, var mange eldre, kritiske bruksområder dessverre låst til denne med mindre vi migrerte dataene. For å beskytte kritiske tjenester som fortsatt var avhengige av data i den delte standardcontaineren, anbefalte vi ofte teamene å opprette separate containere for nye tjenester eller større produktfunksjoner. Etter hvert som vi skalerte opp, økte belastningen på standardcontaineren og det ble flere hendelser i produksjon. Vi begynte å klargjøre containere for alle nye tjenester og større produktfunksjoner bare for å beskytte standardcontaineren mot mer belastning.

Dette sparte oss for mange driftsavbrudd som ville rammet hele plattformen, og begrenset konsekvensene til redusert funksjonalitet i enkeltfunksjoner eller tjenester. Men etter hvert ble ekstraarbeidet med å klargjøre nye containere et problem:

I den gamle delte standardcontaineren ville et nytt bruksområde som gikk fra 0 til 1 million QPS neppe endre den samlede bruken vesentlig. I en isolert container kunne derimot et nytt bruksområde som gikk fra 0 til 1 million QPS innebære 1 000 ganger høyere belastning enn grunnivået fra intern utprøving alene.

Med dedikerte containere måtte teamene nå huske å klargjøre containerne på forhånd for forventet gjennomstrømming ved lansering. Produktteamene satte ofte funksjonene sine i produksjon uten å huske å skalere opp på forhånd. Dermed satt vi i beredskapsrom på lanseringsdagen og prøvde å skalere opp containere i siste liten.

Å blande arbeidsbelastninger er en sentral fordel ved flerleietakersystemer. Med denne containerstrategien gir vi avkall på den fordelen for å få bedre isolasjon.

Over tid krevde overvåking av bruken i dedikerte containere også inngående produktkunnskap om når trafikken ville endre seg eller vokse.

Vi kan tilby et enkelt kontrollplanskript som skalerer opp klargjort gjennomstrømming for hver container basert på veksttrender. Men uten stabil samlet vekst krevde riktig skalering at i praksis alle produktteam hos OpenAI deltok i kapasitetsplanleggingen.

Dette lot seg ikke skalere organisatorisk, ettersom det varierte mye hvor nøye de ansvarlige teamene fulgte opp klargjøringen av Azure Cosmos DB for tjenestene sine.

Etter hvert som organisasjonen vokste, ble disse driftsproblemene vanskelige å håndtere i større skala. Uten ett sentralt team som sto for planleggingen, ble resultatet at mange team planla dårlig. Vi gikk derfor tilbake mot en flerleietakerløsning og samarbeidet tett med Azure-teamet om å løse de opprinnelige problemene våre med en utforming basert på delte ressurser:

Ved å strupe de mest brukte nøklene først hindrer vi støyende naboer i å bruke all tilgjengelig gjennomstrømming i en fysisk partisjon. Det reduserer effekten av støyende naboer der én mye brukt nøkkel kan påvirke hele plattformen.

QoS med nivåinndeling av forespørsler hindrer på samme måte at frakoblede arbeidsbelastninger, som masseinnsetting eller datauttrekk, bruker all gjennomstrømmingen i en fysisk partisjon. Når forespørslene fra disse arbeidsbelastningene får lavere prioritet, strupes de først. Det hindrer struping av interaktive forespørsler med høyere prioritet som betjener sluttbrukere.

Azure Cosmos DB hadde allerede en serverløs modus som ville ha løst problemet med svake partisjoner i modusen med klargjort kapasitet. Men den hadde en stor ulempe: Den skalerte bare etter lagringsbruk og begrenset RU-bruken til 5 000 RU/s per fysiske partisjon. Dette ville løst problemet med svake partisjoner, men hindret oss i å skalere opp RU-krevende bruksområder.

Azure Cosmos DB-teamet bygget en ny og forbedret serverløs modus for oss. Den lot hver fysisk partisjon skalere opp til 10 000 RU/s og innførte deling basert på RU-bruk i tillegg til lagringsbruk. Dermed slapp vi å overvåke og skalere opp containere manuelt.

Med disse endringene har vi kunnet gå tilbake til én delt container. Det har gjort både innledende og løpende kapasitetsplanlegging langt enklere for produktteamene, samtidig som isolasjonen mellom arbeidsbelastninger er bevart. Vi har ikke hatt noen hendelser knyttet til klargjøring eller støyende naboer i månedene siden, til tross for økt tempo i produktutviklingen.

Når selskaper når OpenAIs størrelse, blir administrerte tjenester mindre «administrerte». Mange arbeidsbelastninger faller utenfor normalen i skyleverandørens infrastruktur. Da OpenAI ble en av de største brukerne av Azure Cosmos DB, krevde god drift en annen tilnærming: felles tester og instrumentbord, direkte kanaler mellom utviklerne og felles ansvar for feilsituasjoner som bare oppstår i vår skala. I dag lagrer vår største Azure Cosmos DB-konto flere titalls petabyte med data og betjener over 20 millioner QPS. Så vidt vi vet, er vi det eneste selskapet som har tatt i bruk Azure Cosmos DB i denne skalaen.

Sent i 2024 gjorde et regionalt driftsavbrudd det tydelig hvorfor dette samarbeidet var nødvendig. Da rammet et strømbrudd den primære Azure-regionen for en av våre største Azure Cosmos DB-kontoer. Under den påfølgende failover-prosessen oppdaget vi at det ville ta flere timer å flytte de største kontoene våre til en sekundærregion. Verken vi eller Azure Cosmos DB-teamet hadde testet dette i vår skala.

Omtrent en måned senere utløste vi et nytt alvorlig driftsavbrudd da vi flyttet kontoene tilbake til den opprinnelige regionen. Et rush av tilkoblinger til den opprinnelige regionen overbelastet regionens Azure Cosmos DB-gateway. En særegenhet ved måten Azure Cosmos DB-klienten i gateway-modus håndterte failover på, fikk alle klientene til umiddelbart å opprette tilkoblinger og sende forespørsler til den opprinnelige regionen, selv om bare noen av de fysiske partisjonene var flyttet tilbake dit.

Ved hvert driftsavbrudd fulgte både OpenAI og Azure sine rutiner for hendelseshåndtering. Flere rotårsaker ble identifisert og rettelser ble satt i drift. Men avbruddene var symptomer på et større systemisk problem i samspillet mellom måten vårt team og Azure Cosmos DB-teamet drev og testet på. I starten gjorde administrerte tjenester det mulig å jobbe raskt og fokusere på forretningsmål. I stor skala blir administrerte tjenester mindre administrerte og krever tett integrasjon med tjenesteleverandøren på alle nivåer, fra utforming til drift.

I dag overvåker Habitat- og Azure-utviklingsteamene i fellesskap alle lag i Habitat, fra tjenestelagene våre helt ned til de fysiske lagringslagene i Azure Cosmos DB. Vi drifter og tester endringer mot en Azure Cosmos DB-konto som er like stor som produksjonsmiljøet, men som ikke brukes i produksjon. Vi tester og videreutvikler SDK-er sammen og fastsetter beste praksis for skalering og dimensjonering av Azure Cosmos DB-kontoene våre. Utviklerteamene har direkte kontakt gjennom Teams, og vi har til og med gjort det mulig å varsle hverandres vaktpersonell direkte uten å gå gjennom brukerstøttens ulike nivåer.

Det siste året har vi samarbeidet tett om å forbedre skalerbarheten til kontrollplanet og gatewayen i Azure Cosmos DB. Vi har lagt til lastbeskyttelse og hurtigbufring av ulike Azure Cosmos DB-metadata i gatewayen for å beskytte metadatapartisjonen. Vi har også redusert belastningen fra Python-prosessene våre for habitat-service gjennom tilkoblingsgrupper og mer gjenbruk av tilkoblinger, samlokalisert arbeidsbelastninger der det er mulig, og isolert kritiske arbeidsbelastninger fra frakoblede arbeidsbelastninger via ulike VPC-er.

Dette tette utviklingssamarbeidet har vært avgjørende for stabiliteten i Azure Cosmos DB hos oss det siste året. Ethvert system som er stort eller kritisk nok, krever denne typen samarbeid: å bryte ned skiller mellom ansvarsområder og jobbe på tvers av organisasjonsgrenser.

Som nevnt i del I er grunnfilosofien vår: Få det til å fungere, gjør det raskt, gjør det billig. Først pålitelighet, så ytelse, deretter effektivitet. Habitat var blitt kritisk infrastruktur for OpenAI, så førsteprioriteten var å gjøre systemet pålitelig. Etter hvert som systemet stabiliserte seg i 2025 og OpenAI ekspanderte globalt, ble latenstid den neste begrensningen for brukere og produktteam.

Beregnings- og lagringskapasitet var ofte plassert i ulike regioner, slik at forespørsler på tvers av regioner var uunngåelige.

Latenstiden varierte mye avhengig av hvor dataene var lagret, og hvor forespørselen ble behandlet. For å få god ytelse på Habitat-forespørsler brukte produktutviklerne ekstra hurtigbufring på klientsiden, samlet forespørsler i grupper, minimerte lesing og skriving til databasen og flyttet arbeid ut av den kritiske stien der det var mulig. Dette ga noen interessante produktutforminger som tålte databaseproblemer bedre, men gjorde også produktene mer komplekse og bremset videreutviklingen. Dermed nådde ikke Habitat målet om å legge til rette for rask produktutvikling uten at utviklerne måtte forstå databasen.

Dette har vært et viktig satsingsområde for oss i 2026. Vi har utviklet en strategi i flere lag for å optimalisere leseytelsen, siden lesing utgjør over 90 % av forespørslene til Habitat:

Vi har flere Azure Cosmos DB-kontoer i ulike Azure-regioner rundt om i verden for brukere med krav til dataresidens. Også for brukere uten absolutte krav til dataresidens gir lagring av data nær brukerne en bedre opplevelse gjennom lavere latenstid.

I praksis kan vi ikke gjøre dette i stor utstrekning utover tilfeller med krav til dataresidens, fordi plasseringen begrenses av fysisk kapasitet i skyen. Datasettene våre er så store at mange regioner ikke har plass til det enorme lagringsvolumet som kreves for deres forholdsmessige andel av brukertrafikken.

I regioner med begrenset datasenterkapasitet, strøm eller kjøling står vi noen ganger overfor et direkte valg: reservere kapasitet til samlokalisert lagring og lavere latenstid i Habitat, eller bruke kapasiteten til mer forespørselsbehandling og sende lagringsforespørsler lenger unna.

Plasseringsbeslutninger blir derfor ofte en avveining mellom A) å optimalisere latenstiden for ulike produkter og brukergrupper og B) tilgjengelig lagrings- og beregningskapasitet.

For arbeidsbelastningene der latenstid er mest kritisk, som autentiseringsmetadata som trengs for hver forespørsel, reduserer vi rundturstiden (RTT) mellom beregningsressursene og Habitat ved å bruke bredt replikerte Azure Cosmos DB-kontoer med mange sekundærregioner. Noen kontoer replikerer til alle de 40 Azure-regionene der vi betjener trafikk; andre replikerer til minst én region per kontinent.

Vi har måttet bygge inn et transparent lag for dataflytting og ruting i Habitat tidligere enn ønsket, slik at vi kan flytte datasett mellom kontoer med ulike replikeringstopologier.

Også denne tilnærmingen begrenses imidlertid til syvende og sist av kapasiteten, og brukes derfor bare for noen få håndplukkede datasett.

Arbeidsbelastningene i Habitat domineres av lesing. Applikasjoner henter stadig innstillinger, tilstand og andre egenskaper, og en uforholdsmessig stor del av trafikken gjelder et relativt lite aktivt datasett av typer som brukes ofte. Det gjør systemet særlig godt egnet for distribuert hurtigbufring. Hurtigbufring forbedrer ytelsen i infrastruktur med én region, men gevinsten blir enda større på tvers av regioner, der den kan «skjule» latenstiden mellom regionene.

Vi har integrert et distribuert hurtigbufferlag av typen lookaside i Habitat. Det lagrer en kopi av nylig brukte objekter og kanter på Valkey-servere i infrastrukturen vår, nær stedet der brukerforespørslene behandles. Slike hurtigbuffere bruker vanligvis en levetid (TTL) som balanserer treffrate mot hvor utdaterte dataene kan bli. Kort TTL gir ferskere data, men svekker gevinsten ved hurtigbufring, fordi elementene raskt utløper og må hentes oftere. Lengre TTL gir bedre treffrate, men leverer utdaterte data over lengre tid. Det fører til dårlige brukeropplevelser og uforutsigbar produktatferd.

En annen tilnærming er å utføre eksplisitt invalidering når applikasjonen skriver til de samme underliggende dataene. Dette gir langt ferskere data i hurtigbufferen, men kan være vanskelig å få til riktig. Løsningen er fortsatt utsatt for en rekke grensetilfeller, som delvise feil, som etterlater utdaterte data i hurtigbufferen. Drift i flere regioner forsterker problemene: Nettverk mellom regioner er mindre pålitelige, og det kan oppstå kappløp mellom hurtigbufferen og replikeringen av den underliggende lagringen. Å supplere med TTL setter en grense for hvor utdaterte dataene kan bli, men innebærer fortsatt den samme grunnleggende avveiningen som beskrevet ovenfor.

Vi har valgt en mer avansert tilnærming til invalidering, inspirert av systemer som Metas TAO. Habitats integrerte hurtigbuffer bruker endringsdatafangst (CDC) via endringsstrømmen i Azure Cosmos DB til å spre invalideringer globalt i løpet av sekunder. Det gir høy treffrate samtidig som dataene holdes ferske. En tjeneste i infrastrukturen vår leser denne endringsstrømmen og invaliderer lokale hurtigbuffere når de underliggende dataene oppdateres. Det gir en hurtigbufferbom neste gang dataene leses, og hurtigbufferen fylles med den nyeste versjonen av dataene.

Vi har også redusert latenstiden betydelig ved å fjerne ekstraarbeid i selve Habitat-tjenesten. Det gjorde vi ved å skrive om koden i Rust, som gir bedre ytelse enn den opprinnelige Python-koden.

Til sammen har disse endringene redusert vår samlede globale p50-latenstid for lesing fra omtrent 120 ms til omtrent 10 ms – en forbedring på 12 ganger siden vi begynte å fokusere på ytelse tidligere i år.

Selv om hurtigbufring har redusert medianlatenstiden kraftig, krever de tregeste forespørslene fortsatt at data som ikke er hurtigbufret hentes fra underliggende lagring, ofte i fjerntliggende regioner. Etter hvert som mer kapasitet blir tilgjengelig og vi effektiviserer lagringen, planlegger vi å løse en mer grunnleggende utfordring: å plassere data nærmere stedet de skal brukes, helt fra starten.

Pålitelig og skalerbar CDC – å videreformidle databaseendringer til nedstrømssystemer – er en kritisk komponent i mer enn bare Habitats hurtigbufferstrategi. Millioner av registrerte endringer per sekund, fra tusenvis av containere og millioner av containerpartisjoner, går gjennom over hundre Kafka-emner. De driver også sekundærindekser med eventuell konsistens, dataflyttingspipeliner, frakoblet analyse og andre produktfunksjoner i sanntid. Etter hvert som den underliggende infrastrukturen vår har vokst globalt, har det blitt stadig mer komplisert å lytte etter radendringer. Hvis en klient vil registrere en tilbakeringingsfunksjon som kjøres når rader av klientens type endres, må den først blant annet finne ut hvilke Cosmos-kontoer og containere som inneholder dataene, og hvilken CDC-tjenesteinstans som lytter til disse containerne i de aktuelle regionene. I tillegg må CDC-arbeidsprosessene, Kafka og klientens konsument skaleres riktig. CDC-plattformen vår skal skjule alt dette for produktutviklerne og i stedet tilby et enkelt grensesnitt. Klientene registrerer en funksjon som skal kalles når radene deres endres, og vi håndterer all underliggende integrasjon og skalering.

Et internt kontrollplan sikrer løpende at endringer fanges opp fra alle nødvendige containere, velger hvilke Cosmos-regioner det skal leses fra, og fordeler arbeidet effektivt mellom tusenvis av arbeidsprosesser på tvers av flere geografiske regioner. Bruk av replikaregioner og lavere prioritet på lesing av endringsstrømmen beskytter latenstidsfølsom Habitat-trafikk mot arbeidsbelastningen fra endringsfangst i bakgrunnen. I en så stor samling arbeidsprosesser oppstår det stadig krasj, containerproblemer, feil i låselageret, ugyldig konfigurasjon og feil hos mottakere. Vi gjorde livssyklusen og låsehåndteringen til CDC-arbeidsprosessene mer robuste, isolerte feil mellom strømmene og bygget inn sikkerhetsmekanismer for konfigurasjonsendringer og utrullinger. Vi bruker feilkøer for å hindre at permanente leveringsfeil blokkerer resten av køen. Vi tåler regionale driftsavbrudd ved å flytte leseprosessene til alternative Cosmos-regioner. I vår skala har vi til og med måttet endre Azures CDC-SDK for å effektivisere håndteringen av kontrollpunkter. Vi samler kontrollpunktene i minnet og skriver dem ut bare med jevne mellomrom.

Selv om Habitats interne bruk av Azure Cosmos DB er kompleks, har verdien alltid ligget i å skjule infrastrukturdetaljene for produktutviklerne, slik at de kan utvikle produkter raskere. Det samme gjelder CDC-plattformen vår.

Et lite team klarte å støtte en raskt voksende lagringsplattform ved bevisst å holde lagrings-API-et smalt, fortsette å skalere Python-tjenesten og prioritere de mest presserende tekniske utfordringene. Vi fokuserte først på pålitelighet for virksomhetskritisk produkttrafikk, deretter på leseytelse for brukere over hele verden, og til slutt på effektiv drift i stor skala. Denne tilnærmingen muliggjorde rask vekst og nye bruksområder, samtidig som påliteligheten, ytelsen og tempoet i produktutviklingen ble bedre.

For å skalere Habitat og samtalelagringen til den neste milliarden brukere må vi løse utfordringen med å replikere data på tvers av infrastrukturen vår i enda større skala. For å komme dette i forkjøpet har vi begynt å bygge et eget, skreddersydd lagringssystem for nettbaserte tjenester i exabyteskala, optimalisert for Habitats plasskrevende datatyper. Systemet, som fortsatt er under utvikling, kombinerer RocksDB Cloud-kjernen fra Rockset med Raft-basert replikering. Det implementerer samme dokumentmodell som Azure Cosmos DB, men bruker frikoblet lagring og fysisk replikering for å redusere behovet for flashkapasitet, på bekostning av lavere maksimal QPS.

Hvis du er interessert i å jobbe med denne typen datainfrastruktur i banebrytende skala, se våre ledige stillinger⁠.