Shkallëzimi i shpejtë i hapësirës online për t’u shërbyer mbi 1 miliard përdoruesve të ChatGPT

Çdo produkt i OpenAI varet nga qasja e shpejtë dhe e besueshme te të dhënat, qoftë kur dikush identifikohet, kontrollon cilësimet e Codex apo nis një bisedë të re në ChatGPT. Secili prej këtyre veprimeve mund të kërkojë shumë kërkime të veçanta në të dhëna para se produkti të përgjigjet. Nëse këto kërkesa janë të ngadalta, produkti perceptohet si i ngadaltë. Nëse këto kërkesa dështojnë, produkti ndalon plotësisht së funksionuari.

Habitat është platforma e ruajtjes online që ndërtuam, në mënyrë që produktet e OpenAI të kenë qasje të shpejtë dhe të besueshme tek informacioni i nevojshëm. Habitat tani përpunon mbi 70 milionë kërkesa çdo sekondë, duke mbështetur produkte që përdoren çdo javë nga mbi 1 miliard njerëz në afro 40 rajone gjeografike. Habitat u lançua fillimisht për të mbështetur GPT‑të në DevDay 2023, si një bibliotekë e thjeshtë Python në anën e klientit, e lidhur me një bazë të vetme të dhënash. Sot është një sistem kompleks i shpërndarë që menaxhon mbi 500 petabajt të dhëna.

Ndërtimi dhe operimi i infrastrukturës në këtë shkallë nuk është i lehtë, por as veçanërisht sfidues. Situatën tonë e bënte unike ritmi i paparë me të cilin duhej të shkallëzoheshim për të përballuar rritjen marramendëse të përdoruesve dhe kërkesën për produktet, ndërkohë që ndërtonim një platformë të pjekur. Shpesh, inxhinierët e sistemeve ndërtojnë për një shkallë 10 herë më të madhe dhe shpresojnë që ajo të mjaftojë për disa vjet, ndërsa përgatiten për rritjen tjetër 10-fish. Në rastin tonë, gjatë tre vjetëve të fundit jemi rritur mbi 10-fish nga viti në vit. Si rezultat, ndërtimi dhe operimi i Habitat kanë qenë një varg vendimesh taktike dhe përcaktimesh të kujdesshme të rendit të tyre: të kuptonim çdo komponent në nivelin më të ulët për të shfrytëzuar maksimalisht infrastrukturën ekzistuese teknologjike, ndërsa përballonim kufizimet e kapacitetit të ruajtjes dhe atij llogaritës për të fituar kohë për investime themelore.

Me rritjen e OpenAI, duhej të rritej edhe Habitat: fillimisht duke u bërë mjaftueshëm i besueshëm për trafikun kritik të produkteve, më pas mjaftueshëm i shpejtë për përdoruesit në mbarë botën dhe, në fund, duke operuar me shkathtësi në shkallë masive. Ky artikull është i pari në një seri me dy pjesë mbi mënyrën se si shkallëzuam hapësirën ruajtëse online. Në këtë artikull do të tregojmë se si evoluoi Habitat, pse e shndërruam nga bibliotekë në shërbim dhe si arritëm ta shkallëzonim një shërbim të shkruar në një gjuhë jo të zakonshme për këtë lloj infrastrukture shërbimi—Python—derisa u bë një shtresë e besueshme e platformës së ruajtjes.

Në një artikull të ardhshëm do të shpjegojmë me hollësi se si arritëm besueshmëri në shkallë të gjerë në një mjedis me shumë klientë, strategjinë tonë me shtresa për optimizimin e performancës së operacioneve të leximit dhe si e zgjeruam bashkëpunimin me Azure Cosmos DB për të përballuar me besueshmëri kërkesën e paparë.

Habitat nisi nga një ide e thjeshtë: inxhinierët e produkteve nuk duhet të merren me menaxhimin e bazës së të dhënave. Habitat u lançua fillimisht për të mbështetur GPT‑të në DevDay 2023, si një bibliotekë e vogël Python që ndërvepronte me serverin kryesor të ChatGPT. Ajo mbështeste një grup të vogël veprimesh që, në prapaskenë, përktheheshin në veprime përkatëse në bazën e të dhënave Azure Cosmos DB.

Detyra e bibliotekës ishte t’u ofronte ekipeve të produkteve një mënyrë të thjeshtë për të ruajtur dhe marrë të dhëna, pa pasur nevojë të zotëronin hollësitë teknike në themel. Habitat kujdesej për punën e nevojshme: përcaktonte se për ç’lloj të dhënash bëhej fjalë, nga duhej të merreshin (ose ku duhej të ruheshin), nëse kërkesa lejohej e kështu me radhë.

Inxhinierët e produkteve nuk kanë pse të merren me kërkimin e skemës, rrugëzimin, autorizimin, enkriptimin, serializimin, formësimin e kërkesave dhe menaxhimin e grupit të lidhjeve. Madje, nuk u duhej as të mendonin se nga vinin të dhënat: nga Azure Cosmos DB, memoriet e ndërmjetme apo lloje të tjera të hapësirës ruajtëse.

Kjo bibliotekë Python funksionoi mirë dhe Habitat u adoptua shpejt nga inxhinierët e produkteve në OpenAI, megjithëse nuk pati ndonjë nxitje qendrore të bashkërenduar për t’u larguar nga përdorimi në mënyrë të pavarur i Postgres dhe Azure Cosmos DB.

Me evoluimin e nevojave të produkteve, zhvilluesit mund t’i shtonin lehtësisht bibliotekës së përbashkët mbështetje për veçori si ruajtja në memorien e ndërmjetme në anën e klientit, kompresimi ose enkriptimi.

Nga mesi i vitit 2025, Habitat kishte arritur kufijtë e tij si implementim në anën e klientit. Me rritjen e kompleksitetit të shtresës Habitat dhe të numrit të shërbimeve të OpenAI, ndryshimet e protokollit që ishin të përputhshme me versionet e mëparshme ishin bërë të parealizueshme.

Në një rast, donim të kufizonim ndikimin e ndërprerjes së një rajoni të vetëm te grupet tona më kritike të të dhënave, duke i migruar në një grup llogarish të Azure Cosmos DB të shpërndara rajonalisht. Ky ndryshim kërkonte shtimin e logjikës së rrugëzimit në klient, të kontrolluar nga një flamur veçorie që fillimisht ishte i çaktivizuar, duke u siguruar që ndryshimi të shpërndahej te të gjithë klientët dhe më pas duke aktivizuar flamurin e veçorisë.

Bashkërendimi i vënieve në përdorim në dhjetëra shërbime dhe puna me secilin ekip për shpërndarjen zgjatën disa ditë. Para aktivizimit, kuptuam se donim të shtonim pasqyrim për t’u siguruar që logjika e ndarjes në fragmente ishte e saktë. U deshën edhe disa ditë për ta shpërndarë. Po një korrigjim për diçka që kuptuam se ishte gabim? Edhe disa ditë të tjera. Më në fund ishim gati ta aktivizonim flamurin, por një nga ekipet, për arsye të palidhura, e riktheu shërbimin e vet te një version i mëparshëm i klientit që kishte defekt, duke shkaktuar pikërisht ndërprerjen që ishim përpjekur aq shumë ta shmangnim.

Ndryshimet në bibliotekën e klientit kërkonin bashkërendim kompleks mes dhjetëra shërbimeve, një proces që po bëhej gjithnjë e më i brishtë, joefikas dhe i cenueshëm ndaj dështimeve operative. Për ta zvogëluar këtë shtrirje operative në shumë shërbime gjatë vënieve tona të ardhshme në përdorim, vendosëm ta kthenim Habitat në një shërbim të veçantë.

Duke e ndarë logjikën e ruajtjes në një shërbim të pavarur, krijuam një pikë të vetme kontrolli për vëniet në përdorim, vëzhgueshmërinë dhe përmirësimet e platformës. Në vend që të menaxhonim përditësime të fragmentuara, mund t’i zbatonim përmirësimet në mënyrë të centralizuar, duke i sjellë menjëherë përfitime çdo produkti të OpenAI.

Një shërbim i centralizuar na jep gjithashtu një pikë të vetme kontrolli për të ofruar mekanizmat më të fortë të sigurisë dhe privatësisë së të dhënave. Shërbimi Habitat na mundëson të zbatojmë në mënyrë të centralizuar politikat e kontrollit të qasjes, të kryejmë regjistrimin e auditimit dhe të kufizojmë qasjen te burimet themelore të ruajtjes, si Azure Cosmos DB. Habitat luan rol kritik në mbrojtjen e të dhënave të përdoruesve dhe parandalimin e qasjes së paautorizuar nga aktorë të jashtëm, të brendshëm dhe agjentë.

E dinim se na nevojitej një shërbim, por ende nuk donim të largoheshim nga Python, pavarësisht ngarkesës së tij shtesë si shërbim. Përdorimi i Python për një shërbim me kapacitet të lartë përpunimi rriti vonesën e rrjetit dhe solli kosto të konsiderueshme për shkallëzimin e CPU-së dhe memories, krahasuar me ekzekutimin lokal të bibliotekës. Gjithashtu, e kuptuam se joefikasitetet e Python nuk do të ishin të pranueshme në një shkallë 100 herë më të madhe, ndaj një rishkrim i ardhshëm ishte thuajse i sigurt.

Megjithatë, këtë e konsideruam si një marrje përsipër strategjike të borxhit teknik. Objektivi ynë kryesor në atë kohë nuk ishte optimizimi i kostos apo burimeve, por zhbllokimi i zhvilluesve të produkteve dhe arritja e stabilitetit të platformës. Duke pranuar përkohësisht kompromiset e performancës së një shërbimi Python, mundëm t’u jepnim përparësi sfidave më të ngutshme, të përcaktonim API-të bazë dhe të ndërtonim një infrastrukturë të fuqishme.

Gjithashtu, bëmë një supozim të mirëmenduar se përparimi i shpejtë i modeleve tona të kodimit do ta thjeshtonte rrugën teknike në të ardhmen. U mbështetëm në supozimin se, kur të kërkohej migrimi i plotë nga Python, Codex dhe GPT do ta bënin të realizueshëm këtë migrim. Ky supozim përfundimisht rezultoi i saktë.

Ekzekutimi i Habitat si shërbim Python nuk do të ishte optimal për performancën, por ishte një zgjedhje e nevojshme. Python na mundëson të ecim shpejt, por kjo nuk do të thotë se mund të shpërfillnim rreziqet dhe të pranonim vonesa ndjeshëm më të mëdha. Kur një kërkesë mesatare e përdoruesit shkakton qindra thirrje në bazën e të dhënave, përdoruesi ndien vonesën e thirrjes më të ngadaltë. Kemi konstatuar se sfida kryesore e ekzekutimit të një shërbimi Python në këtë shkallë është menaxhimi i këtyre vonesave në skajin e sipërm të shpërndarjes.

Asyncio e ndihmon Python të ekzekutojë njëkohësisht ngarkesat e kufizuara nga I/O-ja, por nuk e anashkalon GIL-in e Python dhe nuk siguron paralelizëm të CPU-së. Përveç përcjelljes së kërkesave me ngarkesë të lartë I/O-je, Habitat kryen shumë detyra intensive për CPU-në dhe në sfond: rrugëzim, kompresim, enkriptim, përllogaritje të shumave të kontrollit, kontrolle të gjendjes së shërbimeve pasuese, pasqyrim të kërkesave dhe dërgim paralel të kërkesave rezervë.

Me kaq shumë ngarkesa intensive për CPU-në dhe detyra në sfond në shërbimin tonë, vonesa e planifikimit të asyncio mund të mbizotërojë lehtësisht në vonesën e kërkesave në skajin e sipërm të shpërndarjes. Para optimizimit për nisjen fillestare të shërbimit, në gjurmët e kërkesave me vonesë p99 e lart pamë se, ndonëse hapësira ruajtëse pasuese përgjigjej shpejt, kërkesat shpesh ngecnin duke pritur që korutina përgjegjëse të planifikohej sërish për të analizuar përgjigjen.

Për shërbimet Python në OpenAI, përveç matjes së treguesve standardë të përdorimit dhe ngopjes së memories, CPU-së, rrjetit dhe diskut, është thelbësore të monitorohet edhe cikli i ngjarjeve i asyncio dhe ngarkesa e tij, pastaj të bëhen rregullimet përkatëse.

Duke planifikuar periodikisht detyra në sfond dhe duke regjistruar diferencën mes kohës së pritur dhe asaj reale të ekzekutimit, mund ta matim empirikisht dhe në kohë reale vonesën e planifikimit të ciklit të ngjarjeve. Në përdorim të lartë dhe me shumë detyra të kushtueshme, edhe një numër i moderuar kërkesash të njëkohshme për proces mjafton për të shkaktuar luhatje të konsiderueshme në planifikim, deri në qindra milisekonda dhe, në disa raste të skajshme, disa sekonda.

Prandaj, çdo proces e kufizojmë në vetëm pak kërkesa të njëkohshme dhe, në vend të kësaj, rrisim në mënyrë masive numrin e proceseve punëtore Python.

Gjatë nisjes fillestare të shërbimit, përmes profilizimit të CPU-së së shërbimit në funksionim, zbuluam një nga shkaqet rrënjësore të vonesës së lartë të asyncio (dhe, si rrjedhojë, të vonesave të larta në skajin e sipërm të shpërndarjes): analizimin periodik të konfigurimeve JSON të flamujve të veçorive përmes Statsig (një mjet që menaxhon flamujt e veçorive dhe që mund të përdoret për të kryer teste A/B e të tjera).

Si parazgjedhje, Statsig kontrollonte çdo minutë për konfigurime të rifreskuara, pa luhatje kohore, dhe konfigurimi përmbante çdo rregull prodhimi nga të gjitha shërbimet. Ndërkohë, ishte marrë vendimi arkitekturor për të ekzekutuar deri në 8 procese Python për pod, për përdorim më të lartë të CPU-së dhe vonesa më të ulëta. Së bashku, kjo nënkuptonte se çdo minutë secili pod kishte një çast kur të gjithë punëtorët e tij ngecnin në përpunimin e kërkesave në proces dhe, në vend të kësaj, shpenzonin ciklet e CPU-së duke analizuar një skedar gjigant konfigurimi.

Pasi profilizimi i CPU-së na ndihmoi të gjenim shkakun rrënjësor, zgjidhja ishte e thjeshtë: të vendosnim një konfigurim më të vogël e të synuar, të zgjatnim intervalin e rifreskimit dhe t’u shtonim luhatje kohore detyrave të tilla në sfond.

Për të mbajtur të ulët vonesën e asyncio, është gjithashtu thelbësore të ruhet një balancim i mirë i kërkesave mes proceseve të serverit; pa optimizim, grupimi i lidhjeve mund të veprojë në kundërshtim me këtë synim.

Me grupimin e lidhjeve në anën e klientit, një proces i vetëm klienti që bën shumë kërkesa të njëkohshme mund të krijojë vetëm pak lidhje me serverin dhe, si pasojë, t’ua dërgojë të gjithë ngarkesën vetëm pak proceseve. Para se të rregullonim mënyrën e balancimit të ngarkesës, përdorimi i shërbimit tonë ndryshonte shumë, ku disa procese në skajin e sipërm të shpërndarjes përpunonin 5–10 herë më shumë kërkesa të njëkohshme se mesatarja.

Këtë e zbuluam rastësisht gjatë një incidenti ku, megjithëse ndaluam klientin që po mbingarkonte një pjesë të shërbimit tonë, një nëngrup procesesh mbeti në gjendje të degraduar shumë kohë pasi kishte kaluar vala e trafikut. Në fakt, vumë re se këto procese pësonin degradim të pakontrolluar, duke marrë gjithnjë e më shumë kërkesa derisa i rinisëm. Sapo një pod mbingarkohej, një sjellje e caktuar bënte që edhe më shumë trafik të drejtohej tek ai pod i mbingarkuar. Ky ishte një lloj dështimi që disa nga kolegët tanë e njihnin mirë nga puna e mëparshme: dështimi metastabil⁠(hapet në një dritare të re).

Dyshuam se fajin e kishte grupi i lidhjeve dhe e testuam këtë dyshim duke kufizuar kohëzgjatjen maksimale të ripërdorimit të lidhjeve; kjo e kufizoi vërtet degradimin dhe konfirmoi drejtimin e hetimit tonë. Hetimi i mëtejshëm zbuloi se TCPConnector i aiohttp në Python përdor si parazgjedhje ripërdorimin LIFO: për kërkesën tjetër zgjidhet lidhja e kthyer më së fundi. Normalisht, kjo është një parazgjedhje e arsyeshme: ripërdorimi i lidhjeve të fundit u lejon lidhjeve shtesë, të krijuara për të përballuar valët e trafikut, të mbyllen pas afatit të pasivitetit, duke ulur kështu koston e mirëmbajtjes së lidhjeve shtesë. Në këtë rast, kjo krijoi për ne një dështim metastabil. Gjatë një vale kërkesash, kërkesat drejt serverëve më të ngadaltë e të mbingarkuar i kthenin lidhjet në grup më vonë dhe, për rrjedhojë, këto lidhje zgjidheshin më shpesh nga kërkesat pasuese, duke përqendruar gradualisht më shumë trafik te pod-et që tashmë kishin vështirësi. Modifikimi i grupit të lidhjeve për të përdorur ripërdorimin FIFO e ndërpreu këtë cikël reagimi dhe uli gjithashtu ndryshueshmërinë e kërkesave në gjendje të qëndrueshme.

Sot mbështetemi kryesisht te Istio dhe Envoy për grupimin e lidhjeve dhe për strategji më të mira balancimi që marrin parasysh ngarkesën e serverit në të gjithë infrastrukturën e OpenAI, duke e shmangur krejtësisht këtë problem.

Një efekt anësor i optimizimit për vonesë të ulët të asyncio dhe i numrit të madh të proceseve Python është se varësitë pasuese mund të mbingarkohen shumë lehtë nga numri i stërmadh i lidhjeve (fenomen i njohur si "tufë gjëmuese").

Një vendosje e zakonshme ditore—nëse nuk është konfiguruar të kryhet ngadalë—mund të shkaktojë luhatje të konsiderueshme të ngarkesës së CPU-së për shkak të ciklimit të lidhjeve. Ose një rrjedhje lidhjesh mund ta nxjerrë rrjetin jashtë funksionit duke ngopur portën NAT. Këto probleme nuk janë të pazakonta as për shërbime të tjera, por pragu për shkaktimin e tyre ulet ndjeshëm kur ka dhjetëfish më shumë procese, duke ngopur shpesh burime të lidhura me rrjetin që klientët, bazuar vetëm në kapacitetin e përpunimit, nuk presin t’u duhet t’i menaxhojnë në gjendje të qëndrueshme.

Mbështetemi gjithashtu te Envoy për të maksimizuar bashkimin e lidhjeve. E përdorim për t’i kaluar lidhjet HTTP/1 të Python në HTTP/2, për të përfituar nga multipleksimi, pastaj për t’i grupuar këto lidhje dhe për t’ua zgjatur jetëgjatësinë. Envoy na jep gjithashtu një pikë qendrore për zbatimin e kufijve të shpejtësisë së kërkesave dhe ndërprerësve të qarkut, të cilët do të ishin më pak efikas në secilin proces të pavarur Python.

Një nga arsyet pse mundëm ta shkallëzonim Python deri në këtë nivel ishte API-ja e kufizuar e Habitat, e cila e bën koston e përpunimit të kërkesave të parashikueshme. Në vend që t’u lejojë klientëve të ndërtojnë pyetje arbitrare SQL, të cilat mund të çojnë në skanime të gjera të tabelave ose në bashkime mes shumë tabelave, Habitat ofron një API të thjeshtë NoSQL. Kufizimi i funksionalitetit të API-së është një kompromis i qëllimshëm në projektimin e Habitat.

Synojmë të optimizojmë për kërkesa të thjeshta, të parashikueshme dhe me ngarkesë konstante. Nga përvoja jonë, këto sisteme janë shumë më të lehta për t’u shkallëzuar dhe më pak të prirura ndaj gabimeve ose keqpërdorimit. Kërkesat me shpërndarje të paparashikueshme janë të rrezikshme nga pikëpamja operacionale: ato ndërlikojnë izolimin dhe balancimin e ngarkesës, si dhe shkaktojnë rritje të menjëhershme të vonesës, të cilat janë të vështira për t’u menaxhuar gjatë shkallëzimit, si për shërbimin, ashtu edhe për klientët e tij.

Para se të kalonim te Habitat dhe Azure Cosmos DB, shumica e të dhënave online të OpenAI ruheshin në Postgres. Në atë kohë, ishte e lehtë të shqyrtonim të gjitha ndryshimet në pyetje dhe skema, për t’u siguruar që funksiononin siç duhej dhe kryheshin mbi të dhëna të indeksuara përpara se të viheshin në prodhim. Me rritjen e ekipit dhe të produkteve, kjo u bë shpejt e pamenaxhueshme dhe u kthye në një shkak të shpeshtë ndërprerjesh, ku një pyetje e vetme e re dhe me kosto të lartë në një rrjedhë kritike mund ta nxirrte bazën e të dhënave jashtë funksionit.

Problemi këtu qëndron te çekuilibri i kostos: shkrimi i pyetjeve SQL është i thjeshtë dhe me kosto të ulët, ndërsa ekzekutimi i tyre mund të jetë i kushtueshëm dhe i vështirë. Në Habitat e shmangim këtë dhe bëjmë që pyetjet me kosto të lartë të dallohen menjëherë në anën e klientit. Nuk ka pyetje të pakufizuara që mund ta mbingarkojnë Habitat, ndërsa bashkimet komplekse dhe përshkimet e grafeve kërkojnë që ekipet e produkteve të marrin përsipër një pjesë të punës së rëndë, gjë që në përgjithësi nxit projektime më efikase.

Habitat ofron një API NoSQL të modeluar rreth llojeve të objekteve dhe të lidhjeve të përcaktuara nga klienti, frymëzuar nga TAO⁠(hapet në një dritare të re). Klientët paracaktojnë objektet dhe lidhjet, si dhe mënyrën se si lidhen me njëri-tjetrin, por jo përmbajtjen e secilit lloj. Marrëdhëniet që krijohen ngjajnë me një graf, por vetë Habitat nuk mbështet pyetje tipike për përshkimin e grafit, përveç pyetjeve për lidhjet e drejtpërdrejta të një objekti të caktuar.

E ndajmë këtë graf në mënyrë që çdo objekt dhe lidhjet përkatëse të vendosen së bashku në një ndarje në nivelin e ruajtjes, por nuk bëjmë ndonjë përpjekje të posaçme në nivelin e bazës së të dhënave për t’i vendosur së bashku objektet dhe objektet e largëta drejt të cilave çojnë lidhjet e tyre. Si rezultat, modeli mund të ndahet lehtësisht në ndarje për shkallëzim horizontal, por përshkimet e grafit janë joefikase, pasi çdo kalim i caktuar nga një objekt te tjetri mund të kërkojë marrjen e të dhënave nga dy llogari krejtësisht të ndryshme të Azure Cosmos DB, të vendosura në rajone të ndryshme.

Për klientët me nevoja më komplekse për pyetje, ofrojmë një pamje dytësore jashtë linje të Habitat, të aksesueshme përmes Rockset. Përdorim kapjen e ndryshimeve të të dhënave (CDC) për të transmetuar vazhdimisht ndryshimet nga hapësira ruajtëse online drejt instancave të izoluara Rockset, pothuajse në kohë reale. Çdo ekip klienti është përgjegjës për shkallëzimin e instancës së vet Rockset sipas nevojave të tij për pyetje komplekse.

Konfigurimi i Rockset u krijon klientëve tanë vështirësi shtesë, por mendojmë se, në këtë fazë, ky është kompromisi i duhur: t’i bëjmë pyetjet e thjeshta zgjedhjen e parazgjedhur, duke ofruar një rrugë alternative për ata që kanë nevojë për pyetje komplekse. Ky projektim e izolon hapësirën tonë ruajtëse online nga ngarkesat analitike dhe të kërkimit që kërkojnë shumë operacione leximi.

Shtyrja për një vit e rishkrimit për t’u larguar nga Python na lejoi të përqendroheshim te sfida më urgjente dhe me më shumë ndikim gjatë rritjes sonë tejet të shpejtë. Me pjekjen e platformës dhe përshpejtimin e vazhdueshëm të rritjes, dhe duke qenë shërbimi i dytë më i madh në OpenAI për nga numri i bërthamave (dhe i katërti për nga shkalla e përdorimit të Envoy), më në fund erdhi koha të kalonim përtej Python. Në kulmin e vet, Python na ndihmoi të përpunonim mbi 20 milionë kërkesa në sekondë.

Në tremujorin e dytë të vitit 2026, vetëm me 2 inxhinierë, Codex dhe GPT‑5.5, mundëm ta rishkruanim të gjithë shërbimin në Rust. Shërbimi i ri Rust tani përpunon 95% të kërkesave tona në prodhim; në javët e ardhshme do ta nxjerrim plotësisht Python nga përdorimi. Të dhënat tona tregojnë se shërbimi Rust është 6 herë më efikas në përdorimin e CPU-së dhe 15 herë më efikas në përdorimin e memories se versioni Python, me vonesa mesatare dhe vonesa në skajin e sipërm të shpërndarjes dukshëm më të ulëta. Planifikojmë të ndajmë më shumë nga përvojat dhe njohuritë e nxjerra në një artikull të ardhshëm.

Shërbimi Python—dhe tani Rust—është vetëm një aspekt i Habitat. Në pjesën II të kësaj serie, ku shpjegojmë se si e shkallëzuam me shpejtësi hapësirën tonë ruajtëse online për t’u shërbyer mbi 1 miliard përdoruesve të ChatGPT, do të flasim për shtresën e ruajtjes dhe mënyrën se si Habitat menaxhon mbi 500 petabajt të dhëna dhe përpunon mbi 70 milionë kërkesa në sekondë.

Nëse dëshiron të punosh me sisteme OLTP në shkallë avangardë dhe të intereson kjo lloj inxhinierie, shiko këtë vend të lirë pune në ekipin tonë⁠.