Hurtig skalering af onlinelagring til over 1 milliard ChatGPT‑brugere (del II)

Alle OpenAI-produkter kræver hurtig og pålidelig adgang til data, som vores lagerplatform Habitat leverer. Den skal svare på millisekunder til over 1 milliard brugere i 40 geografiske regioner. Vores infrastruktur stod over for en usædvanlig udfordring: at understøtte eksplosiv vækst og nye anvendelser og samtidig forbedre driftssikkerheden, ydeevnen og produktudviklernes arbejdshastighed. Det krævede, at vi gentænkte designet og driften af vores onlinelagerplatform. Vi afvejede løbende fordele og ulemper efter dette princip: Først skulle platformen være driftssikker nok til forretningskritisk produkttrafik, så hurtig nok til globale brugere og til sidst kunne drives effektivt i enorm skala.

Denne serie i to dele forklarer, hvordan vi udviklede Habitat fra et enkelt klientbibliotek og en database til en globalt distribueret lagerplatform, der leverer adgang til over 500 petabyte data. Del I fokuserede på Habitats udvikling fra en Python-klient til en tjeneste. Den beskrev også de teknikker, der gjorde det muligt at presse en Python-baseret tjeneste langt ud over, hvad mange ville anse for praktisk muligt.

I dette indlæg, del II, gennemgår vi, hvordan vi skalerede den underliggende lagerkomponent: Azure Cosmos DB. Gennem et tæt samarbejde med Azure-teamet fandt vi en holdbar multi-tenancy-løsning med containere, vi administrerer i fællesskab, og fremragende læseydeevne i enorm, global skala.

Når virksomheder vokser, går infrastrukturteams ofte fra at drive single-tenant-systemer til multi-tenant-systemer. Single-tenancy, hvor hvert team med ansvar for en produktflade vedligeholder sit eget system, begrænser konsekvenserne af fejl og giver klare ansvarsgrænser og isolering af workloads. Når antallet af teams og produktflader vokser, bliver det dyrt at drive. Single-tenancy gør hvert produktteam ansvarligt for kapacitetsplanlægning og fører ofte til betydelig overdimensionering.

Multi-tenancy placerer derimod styringen hos et centralt databaseteam med større viden om og erfaring med klargøring af ressourcer. Men multi-tenancy skaber sine egne problemer, f.eks. støjende naboer, hvor én tenant bruger en usædvanligt stor andel af ressourcerne på bekostning af de øvrige.

I Habitat måtte vi afveje alle disse hensyn for at designe et driftssikkert og effektivt lagersystem i stor skala. I dag er Habitat et multi-tenant-databaselag for mange OpenAI-produkter. Men vi har været hele vejen rundt: fra én multi-tenant-container i Azure Cosmos DB til klargøring af underliggende single-tenant-containere og tilbage til en multi-tenant-container som standard. Vi er stadig i en tidlig fase med multi-tenancy i Habitat. Vi understøtter mange anvendelser, men har kunnet udskyde investeringer på området ved at udnytte Azure Cosmos DB's indbyggede grundfunktioner, hvor det var muligt.

Før vi gennemgår vores forløb med Azure Cosmos DB, er her lidt grundlæggende baggrund:

• En Azure Cosmos DB-konto definerer et sæt containere og en replikeringspolitik

• Hver container klargøres til et bestemt gennemløb målt i forespørgselsenheder pr. sekund (RU/s)

• Data i hver container lagres ved almindelig sharding ud fra en angivet logisk partitionsnøgle med dokumenterede grænser for lagerplads og gennemløb pr. logisk partitionsnøgle

• Azure Cosmos DB fordeler logiske partitionsnøgler over færre underliggende fysiske partitioner. Disse opdeles i flere fysiske partitioner, når datamængden overskrider en tærskel, eller når containeren har brug for flere fysiske partitioner for at opretholde det klargjorte gennemløb

Oprindeligt lod vi al klientbelastning passere og stolede på, at den angivne grænse på 10.000 RU/s pr. logisk partitionsnøgle ville skabe modtryk. I begyndelsen brugte vi også kun én standardcontainer i Azure Cosmos DB pr. konto. Det fungerede godt nok, men viste sig at være problematisk af flere grunde:

På grund af tidlige API-valg lod vi klienterne vælge den logiske partitionsnøgle direkte. Derfor oplever vi hyppige kollisioner mellem forskellige produktanvendelser på almindeligt brugte partitionsnøgler som user_id og workspace_id. Da disse anvendelser delte Azure Cosmos DB-grænser på de samme logiske partitionsnøgler, begrænsede designet det samlede gennemløb for en given bruger.

Et almindeligt problem, da vi skalerede Postgres før overgangen til Habitat og Azure Cosmos DB, var, at mange forespørgsler fra en meget aktiv organisation eller på en meget aktiv nøgle – én tenant med uforholdsmæssigt stor belastning – kunne lægge hele databasen ned. Vi brugte mange kræfter i fællesskab på at cache disse nøgler og indføre leases ved cachemissere, så belastningen fra dem ikke overvældede den underliggende database.

Selvom de dokumenterede grænser for datastørrelse og gennemløb gælder for logiske partitionsnøgler, håndhæves grænserne faktisk på den fysiske partition. I praksis betyder det, at logiske partitioner ikke kan nå op på 10.000 RU/s. I stedet deler de den fysiske partitions grænser med alle andre logiske partitionsnøgler på samme fysiske partition.

Det betød, at støjende naboer kunne påvirke mange uvedkommende logiske partitionsnøgler, så workloads, der arbejdede med data til nichefunktioner, forstyrrede centrale login- og tilmeldingsforløb.

Gennemløbsgrænsen for en given fysisk partition varierer også afhængigt af det samlede gennemløb, der er tildelt Azure Cosmos DB-containeren. Containerens klargjorte gennemløb fordeles nogenlunde ligeligt mellem dens fysiske partitioner.

Når datamængden vokser, opdeles de fysiske partitioner. Dermed stiger det samlede antal partitioner, mens det samlede klargjorte gennemløb forbliver uændret. Resultatet er, at den effektive gennemløbsgrænse pr. partition falder, efterhånden som datamængden vokser.

For vores mest lagerkrævende, blob-lignende anvendelser skaber det en fejltilstand, hvor vækst i datamængden alene reducerer gennemløbskapaciteten for aktive workloads, selvom forespørgselsrater og brug forbliver stabile.

Separate containere hjælper med delvist at løse problemerne med partitionsnøglegrænser og støjende naboer. Med separate containere kan hver container tildeles sine egne uafhængige fysiske partitioner. Så kan kun de forskellige workloads i selve containeren være støjende naboer eller have overlappende partitionsnøgler. Ulempen er, at klargøring af nye containere kræver ekstra arbejde – hver container kræver individuel kapacitetsplanlægning. Derfor vil vi kun oprette containere, hvor en naturlig grænse mellem tjenester eller anvendelser gør det meningsfuldt.

Vi begyndte at bruge separate Azure Cosmos DB-containere til de mest kritiske nye anvendelser, der krævede stærk isolering. Sammen med et script, der håndterede svage partitioner ved at tilpasse hver containers samlede klargjorte gennemløb til antallet af fysiske partitioner, gjorde det, at vi stort set undgik alle de problemer, vi stod over for.

Men da vi var startet med en standardcontainer, var mange ældre, kritiske anvendelser desværre bundet til den, medmindre vi migrerede dataene. For at beskytte kritiske tjenester, der stadig var afhængige af data i den delte standardcontainer, rådede vi ofte teams til at oprette separate containere til nye tjenester eller større produktfunktioner. Efterhånden som vi skalerede, steg belastningen på standardcontaineren, og antallet af driftsproblemer voksede. Vi begyndte at klargøre containere til enhver ny tjeneste eller større produktfunktion alene for at beskytte standardcontaineren mod yderligere belastning.

Det skånede os for mange nedbrud på tværs af hele platformen og begrænsede konsekvenserne til driftsforstyrrelser i enkelte funktioner eller tjenester. Men efterhånden blev det ekstra arbejde med at klargøre nye containere et problem:

I den gamle delte standardcontainer ville en enkelt ny anvendelse, der gik fra 0 QPS til 1 million QPS, næppe ændre det samlede forbrug væsentligt. I en isoleret container kunne en ny anvendelse, der gik fra 0 til 1 million QPS, derimod betyde en belastning, der var 1.000 gange større end udgangspunktet med kun intern afprøvning.

Med dedikerede containere skulle teams nu huske på forhånd at klargøre containerne til det forventede gennemløb ved lancering. Produktteams satte ofte deres funktioner i produktion uden at huske at skalere på forhånd. Så sad vi i beredskabsmøder på lanceringsdagen og forsøgte at opskalere containere i sidste øjeblik.

Det er en central fordel ved at blande workloads i multi-tenant-systemer, som vi mister til fordel for bedre isolering med denne containerstrategi.

Med tiden krævede overvågningen af forbruget i dedikerede containere også indgående produktkendskab til, hvornår trafikken ville ændre sig eller vokse.

Vi kan levere et enkelt script til kontrolplanet, der opskalerer det klargjorte gennemløb for hver container ud fra væksttendenser. Men uden stabil samlet vækst krævede korrekt skalering i praksis, at alle produktteams hos OpenAI deltog i kapacitetsplanlægningen.

Det kunne ikke skaleres organisatorisk, da der var stor forskel på, hvor omhyggeligt de ansvarlige teams håndterede Azure Cosmos DB-klargøringen for deres tjenester.

Efterhånden som organisationen voksede, blev disse driftsproblemer svære at håndtere i større skala. Uden ét centralt team til at stå for planlægningen endte mange teams med at planlægge dårligt. Derfor vendte vi tilbage til en multi-tenant-løsning og arbejdede tæt sammen med Azure-teamet om at løse vores oprindelige multi-tenancy-problemer med et design baseret på delte ressourcer:

Ved først at hastighedsbegrænse de mest aktive nøgler forhindrer vi støjende naboer i at bruge hele det tilgængelige gennemløb på en given fysisk partition. Det reducerer effekten af støjende naboer, hvor én meget aktiv nøgle kan påvirke hele platformen.

QoS med niveauinddeling af forespørgsler forhindrer på samme måde offline-workloads, f.eks. masseindsættelser eller dataudtræk, i at bruge hele gennemløbet på en given fysisk partition. Ved at give forespørgslerne fra disse workloads lavere prioritet bliver de hastighedsbegrænset først. Det forhindrer hastighedsbegrænsning af interaktive forespørgsler med højere prioritet, som betjener slutbrugerne.

Azure Cosmos DB havde allerede en serverløs tilstand, der kunne have løst vores problem med svage partitioner ved klargjort kapacitet. Men der var en stor ulempe: Den skalerede kun ud fra lagerforbruget og begrænsede RU-forbruget til 5.000 RU/s pr. fysisk partition. Det ville løse problemet med svage partitioner, men forhindre os i at opskalere RU-krævende anvendelser.

Azure Cosmos DB-teamet byggede en ny og forbedret serverløs tilstand til os, hvor hver fysisk partition kunne skalere op til 10.000 RU/s. Den indførte også opdeling baseret på RU-forbrug ud over lagerforbrug, så vi ikke længere behøvede at overvåge og opskalere containere manuelt.

Med disse ændringer har vi kunnet vende tilbage til én delt container. Det har i høj grad forenklet kapacitetsplanlægningen for produktteams, både på forhånd og løbende, samtidig med at workloads fortsat er isoleret fra hinanden. I månederne siden har vi ikke haft nogen hændelser med klargøring eller støjende naboer, selvom produktudviklingen er accelereret.

Når virksomheder vokser til OpenAI's størrelse, bliver administrerede tjenester mindre »administrerede«. Mange workloads falder uden for det normale i cloududbyderens infrastruktur. Da OpenAI blev en af de største brugere af Azure Cosmos DB, krævede vellykket drift en anden model: fælles test, fælles dashboards, direkte kontakt mellem udviklingsteams og fælles ansvar for fejltilstande, der kun opstår i vores skala. I dag lagrer vores største Azure Cosmos DB-konto titals petabyte data og håndterer over 20 millioner QPS. Så vidt vi ved, er vi den eneste virksomhed, der har taget Azure Cosmos DB i brug i denne skala.

I slutningen af 2024 gjorde et regionalt nedbrud det tydeligt, hvorfor dette samarbejde var nødvendigt. Et strømsvigt ramte den primære Azure-region for en af vores største Azure Cosmos DB-konti. Under den efterfølgende failover opdagede vi, at det ville tage flere timer at flytte vores største konti over til en sekundær region. Det havde hverken vores team eller Azure Cosmos DB-teamet testet i vores skala.

Omkring en måned senere udløste vi endnu et alvorligt nedbrud, da vi flyttede kontiene tilbage til den oprindelige region. En storm af forbindelser til den oprindelige region overbelastede regionens Azure Cosmos DB-gateway. En særegenhed i Azure Cosmos DB-klientens håndtering af failover i gateway-tilstand fik alle klienter til straks at oprette forbindelser og sende forespørgsler til den oprindelige region, selvom kun en del af de fysiske partitioner var flyttet tilbage.

Ved hvert nedbrud fulgte både OpenAI og Azure deres procedurer for hændelseshåndtering, identificerede en række grundårsager og udrullede rettelser. Men nedbruddene var symptomer på et større, systemisk problem i samspillet mellem vores og Azure Cosmos DB-teamets drifts- og testmetoder. I starten gjorde administrerede tjenester det muligt for os at arbejde hurtigt og fokusere på forretningsmål. I stor skala bliver administrerede tjenester mindre administrerede og kræver tæt integration med tjenesteudbyderen på alle niveauer fra design til drift.

I dag overvåger Habitats og Azures udviklingsteams i fællesskab alle lag i Habitat, fra vores tjenestelag til Azure Cosmos DB's fysiske lagerlag. Vi kører og tester ændringer på en Azure Cosmos DB-konto, der har samme størrelse som i produktion, men ikke bruges til produktion. Vi tester og videreudvikler SDK'er sammen og fastlægger bedste praksis for skalering og dimensionering af vores Azure Cosmos DB-konti. Udviklingsteams kan kontakte hinanden direkte via Teams, og vi har endda gjort det muligt at tilkalde hinanden direkte uden at gå gennem supportniveauer.

I det seneste år har vi i fællesskab gjort en stor indsats for at forbedre skalerbarheden af Azure Cosmos DB's kontrolplan og gateway. Vi har tilføjet belastningsbeskyttelse og caching af forskellige Azure Cosmos DB-metadata i gatewayen for at beskytte metadatapartitionen. Vi har også reduceret belastningen fra vores mange Python-baserede habitat-service-processer gennem forbindelsespuljer og øget genbrug af forbindelser, samplaceret workloads, hvor det var muligt, og isoleret kritiske workloads fra offline-workloads via separate VPC'er.

Dette tætte udviklingssamarbejde har været afgørende for stabiliteten af vores Azure Cosmos DB det seneste år. Ethvert tilstrækkeligt stort eller kritisk system kræver denne form for samarbejde: at nedbryde skel mellem ansvarsområder og arbejde på tværs af organisatoriske grænser.

Som nævnt i del I er vores grundfilosofi: Få det til at virke, gør det hurtigt, gør det billigt. Først driftssikkerhed, så ydeevne og til sidst effektivitet. Habitat var blevet kritisk infrastruktur for OpenAI, så førsteprioriteten var at gøre det driftssikkert. Da systemet blev stabiliseret i 2025, og OpenAI ekspanderede globalt, blev latens den næste begrænsning for brugere og produktteams.

Beregnings- og lagerkapacitet var ofte placeret i forskellige regioner, så forespørgsler på tværs af regioner var uundgåelige.

Latensen varierede meget, alt efter hvor dataene blev lagret, og hvor forespørgslen blev behandlet. For at få hurtige Habitat-forespørgsler brugte produktudviklerne ekstra caching på klientsiden og samlede forespørgsler i batches. De minimerede også læsninger og skrivninger i databasen og flyttede så vidt muligt arbejde væk fra den kritiske sti. Det førte til nogle interessante produktdesign, der var mere robuste over for databaseproblemer, men gjorde også produkterne mere komplekse og bremsede den løbende produktudvikling. Dermed indfriede Habitat ikke sit mål om at muliggøre hurtig produktudvikling uden behov for at forstå databasen.

Det har været et vigtigt fokusområde for os i 2026. Vi har udviklet en strategi i flere lag for at optimere læseydeevnen, da læsninger udgør over 90 % af Habitats forespørgsler:

Vi har en række Azure Cosmos DB-konti i forskellige Azure-regioner verden over til brugere med krav om dataresidens. Også for brugere uden strenge krav om dataresidens giver placering af data tæt på brugerne en bedre oplevelse takket være lavere latens.

I praksis kan vi ikke gøre dette i større omfang ud over de tilfælde, hvor der er krav om dataresidens, da placeringen er begrænset af den fysiske cloudkapacitet. Vores datasæt er så store, at mange regioner ikke har plads til den enorme datamængde, der kræves for at håndtere deres forholdsmæssige andel af brugertrafikken.

I regioner med begrænset datacenterkapacitet, strøm eller køling står vi nogle gange over for et direkte valg: reservere kapacitet til samplaceret lagring og lavere Habitat-latens eller bruge kapaciteten til flere beregningsressourcer til forespørgsler og sende lagerforespørgsler længere væk.

Derfor er beslutninger om placering ofte en afvejning mellem A) optimering af latens for forskellige produkter og brugergrupper og B) den tilgængelige lager- og beregningskapacitet.

For de mest latenskritiske workloads, f.eks. godkendelsesmetadata, der kræves ved hver forespørgsel, reducerer vi RTT mellem beregningsressourcerne og Habitat ved at bruge Azure Cosmos DB-konti med omfattende replikering til mange sekundære regioner. Nogle konti replikerer til alle 40 Azure-regioner, hvor vi håndterer trafik, mens andre replikerer til mindst én region pr. kontinent.

Vi har tidligere end ønsket måttet bygge et lag til transparent dataflytning og routing ind i Habitat, så vi kan flytte datasæt mellem konti med forskellige replikeringstopologier.

Denne tilgang er dog i sidste ende også begrænset af kapacitet og bruges derfor kun til nogle få nøje udvalgte datasæt.

Habitats workloads er stærkt domineret af læsninger, hvor applikationer konstant henter indstillinger, tilstand og andre egenskaber. En uforholdsmæssigt stor del af trafikken vedrører et relativt lille aktivt sæt af ofte anvendte typer. Det gør systemet særligt velegnet til distribueret caching. Caching forbedrer ydeevnen i infrastruktur med én region, men gevinsten bliver endnu større på tværs af regioner, hvor caching kan bruges til at »skjule« latensen mellem regionerne.

Vi har integreret et distribueret lookaside-cachelag i Habitat. Det lagrer en kopi af nyligt tilgåede objekter og kanter på Valkey-servere i vores infrastruktur tæt på det sted, hvor brugerforespørgsler behandles. Denne type cache bruger typisk en TTL, der afvejer træfrate mod forældelse. Korte TTL'er reducerer forældelse, men dæmper den positive effekt af caching, fordi elementer hurtigt udløber i cachen og skal hentes oftere. Længere TTL'er forbedrer træfraten, men leverer forældede data i længere tid, hvilket giver dårlige brugeroplevelser og uforudsigelig produktadfærd.

En anden tilgang er at udføre eksplicitte invalideringer, når applikationen skriver til de samme underliggende data. Det gør de cachede data markant mere aktuelle, men kan være svært at implementere korrekt. Tilgangen er også stadig sårbar over for en række særtilfælde, f.eks. delvise fejl, der efterlader cachen med forældede data. Drift i flere regioner forstærker problemerne, fordi netværk mellem regioner er mindre pålidelige, og der kan opstå kapløb mellem cachen og replikeringen i det underliggende lager. Supplerer man med TTL'er, sættes en øvre grænse for forældelsen, men den samme grundlæggende TTL-afvejning gælder stadig.

Vi har valgt en mere avanceret tilgang til invalidering, inspireret af systemer som Metas TAO. Habitats integrerede cache bruger change data capture (CDC) via Azure Cosmos DB's ændringsfeed til at udbrede invalideringer globalt på få sekunder. Det giver høje træfrater og begrænser samtidig forældelsen. En tjeneste i vores infrastruktur læser dette ændringsfeed og invaliderer data i de lokale cacher, når de underliggende data opdateres. Det giver en cachemisser, næste gang dataene læses, hvorefter cachen fyldes med den nyeste version.

Vi har også reduceret latensen markant ved at fjerne overhead i selve Habitat-tjenesten. Det har vi gjort ved at omskrive koden i Rust, som yder bedre end den oprindelige Python-kode.

Tilsammen har disse ændringer reduceret vores samlede globale p50-læselatens fra cirka 120 ms til cirka 10 ms – en forbedring på 12 gange, siden vi begyndte at fokusere på ydeevne tidligere i år.

Selvom caching har reduceret medianlatensen markant, kræver de langsomste forespørgsler stadig, at ikke-cachede data hentes fra det underliggende lager, ofte fra fjerntliggende regioner. Efterhånden som mere kapacitet bliver tilgængelig, og vi forbedrer lagereffektiviteten, vil vi tage fat på en mere grundlæggende udfordring: fra starten at placere data tættere på det sted, hvor de skal bruges.

Pålidelig og skalerbar CDC – som sender databaseændringer videre til efterfølgende systemer – er en afgørende komponent i mere end blot Habitats cachingstrategi. Millioner af registrerede ændringer pr. sekund fra tusindvis af containere og millioner af containerpartitioner strømmer gennem over hundrede Kafka-topics. De driver også sekundære indeks med eventual consistency, pipelines til dataflytning, offline-analyser og andre produktfunktioner i realtid. Efterhånden som vores underliggende infrastruktur er vokset globalt, er det blevet mere komplekst at lytte efter ændringer i rækker. Hvis en klient vil registrere et callback, der køres, hver gang rækker af dens type ændres, skal den bl.a. først finde ud af, hvilke Cosmos-konti og -containere der indeholder dens data, og hvilken CDC-tjenesteinstallation der lytter til containerne i de respektive regioner. Den skal også skalere CDC-tjenestens workers, Kafka og sin egen consumer korrekt. Vores CDC-platform skal skjule alt dette for produktudviklerne og i stedet tilbyde en enkel grænseflade. Her registrerer klienterne en funktion, som skal kaldes, når deres rækker ændres, mens vi håndterer al den tekniske opsætning og skalering.

Et internt kontrolplan sikrer løbende, at ændringer registreres fra alle nødvendige containere, vælger, hvilke Cosmos-regioner der skal læses fra, og fordeler effektivt arbejdet mellem tusindvis af workers i flere geografiske regioner. Ved at bruge replikaregioner og give feedlæsninger lavere prioritet beskytter vi latensfølsom Habitat-trafik mod de workloads, der registrerer ændringer i baggrunden. I en så stor installation opstår der hele tiden worker-nedbrud, containerproblemer, fejl i lease-lageret, ugyldige konfigurationer og fejl på destinationer. Vi gjorde CDC-workernes livscyklus og lease-håndtering mere robuste, isolerede fejl mellem streams og indbyggede sikkerhedsforanstaltninger ved konfigurationsændringer og udrulninger. Vi bruger dead letter-køer til at forhindre, at permanente leveringsfejl blokerer forrest i køen. Vi håndterer regionale nedbrud ved at lade læserne skifte til andre Cosmos-regioner. I vores skala har vi endda måttet ændre Azures CDC-SDK for at effektivisere checkpoint-implementeringen ved at samle checkpoints i hukommelsen og kun skrive dem ud med jævne mellemrum.

Selvom Habitats interne brug af Azure Cosmos DB er kompleks, har værdien altid ligget i at skjule infrastrukturdetaljer for produktudviklerne, så de kan udvikle hurtigere. Det samme gælder vores CDC-platform.

Et lille team kunne understøtte en hastigt voksende lagerplatform ved bevidst at holde lager-API'et snævert, fortsætte skaleringen af Python-tjenesten og prioritere de mest presserende tekniske udfordringer. Vi fokuserede først på driftssikkerhed for forretningskritisk produkttrafik, derefter på læseydeevne for globale brugere og til sidst på effektiv drift i stor skala. Denne tilgang muliggjorde hurtig vækst og nye anvendelser og forbedrede samtidig driftssikkerheden, ydeevnen og tempoet i produktudviklingen.

For at skalere Habitat og samtalelagring til den næste milliard brugere skal vi løse udfordringen med at replikere vores data på tværs af infrastrukturen i endnu større skala. For at være på forkant har vi arbejdet på et skræddersyet, egenudviklet onlinelagersystem i exabyteskala, optimeret til Habitats store datatyper. Systemet, som stadig er under udvikling, kombinerer RocksDB Cloud-kernen fra Rockset med Raft-baseret replikering. Det implementerer samme dokumentmodel som Azure Cosmos DB, men bruger adskilt lagring og fysisk replikering til at reducere behovet for flashkapacitet til gengæld for en lavere maksimal QPS.

Hvis du er interesseret i at arbejde med denne type datainfrastruktur i banebrydende skala, så se vores ledige stillinger⁠.