Çfarë ndodh kur dy përdorues ndryshojnë të njëjtën të dhënë në të njëjtën kohë?

Një sistem mund të funksionojë në mënyrë perfekte me qindra përdorues dhe të sillet krejt ndryshe kur aktiviteti rritet në mijëra kërkesa njëkohësisht.

Në atë pikë, sfida nuk është vetëm kapaciteti i serverëve. Shumë procese mund të lexojnë, ndryshojnë dhe shkëmbejnë të njëjtat të dhëna pothuajse në të njëjtën kohë. Një pagesë mund të jetë duke u konfirmuar ndërsa një proces tjetër kontrollon statusin e saj. Një dokument mund të përditësohet ndërsa një shërbim tjetër po e përdor. Një kërkesë mund të përsëritet sepse përgjigjja e parë është vonuar, edhe pse veprimi është kryer.

Në sisteme të tilla, shpejtësia ka vlerë vetëm kur shoqërohet me kontroll mbi atë që po ndodh paralelisht.

Kur sistemi rritet, ndryshon edhe natyra e problemit

Një nga keqkuptimet më të zakonshme rreth shkallëzimit është se një sistem më i madh ka nevojë kryesisht për më shumë fuqi përpunuese.

Në praktikë, rritja sjell edhe më shumë ndërveprime mes proceseve. Sa më shumë përdorues, shërbime dhe integrime veprojnë njëkohësisht, aq më shumë duhet të koordinohet mënyra si ndryshon informacioni.

Kjo bëhet veçanërisht e rëndësishme në platforma ku një veprim aktivizon disa procese të tjera. Një kërkesë e vetme mund të përditësojë një databazë, të komunikojë me një sistem tjetër, të gjenerojë një dokument dhe të dërgojë një njoftim.

Nga jashtë është një veprim. Brenda arkitekturës është një zinxhir procesesh që duhet të ruajnë të njëjtën logjikë edhe kur mijëra zinxhirë të tillë zhvillohen paralelisht.

E njëjta kërkesë mund të arrijë dy herë. Sistemi duhet ta dijë.

Një nga problemet më interesante të sistemeve të shpërndara është se një kërkesë e përsëritur nuk do të thotë domosdoshmërisht se përdoruesi e ka kryer dy herë të njëjtin veprim.

Një lidhje mund të ndërpritet pasi serveri e ka përpunuar kërkesën, por përpara se përgjigjja të arrijë te aplikacioni. Për aplikacionin, rezultati është i paqartë: veprimi u krye apo jo?

Në shumë arkitektura, përgjigjja është ta provojë përsëri.

Por nëse sistemi nuk është projektuar për këtë situatë, një retry mund të kthehet në një veprim të dytë: një pagesë tjetër, një regjistrim tjetër apo një proces të ekzekutuar dy herë.

Këtu hyn një parim shumë i rëndësishëm i sistemeve moderne: idempotency. Sistemi duhet të jetë në gjendje të njohë se një kërkesë është përpunuar më parë dhe, kur procesi e kërkon, të rikthejë rezultatin ekzistues në vend që ta ekzekutojë sërish.

Ky është një shembull i mirë se si besueshmëria e një sistemi ndërtohet për situatat që përdoruesi nuk i sheh kurrë.

Jo çdo gjë duhet të ndodhë në të njëjtën sekondë

Një tjetër ndryshim i rëndësishëm në arkitekturën e sistemeve me volum të lartë është mënyra si trajtohet koha.

Jo çdo proces duhet të përfundojë brenda së njëjtës kërkesë.

Disa veprime duhet të konfirmohen menjëherë. Të tjera mund të vendosen në radhë dhe të përpunohen disa momente më vonë. Për këtë arsye, sistemet moderne përdorin queues, events dhe procese asinkrone për të shpërndarë ngarkesën dhe për të shmangur që një pjesë e sistemit të mbajë të bllokuar pjesët e tjera.

Kjo krijon një arkitekturë më elastike, por sjell edhe një përgjegjësi tjetër: të gjitha pjesët duhet të dinë se në çfarë gjendjeje ndodhet procesi.

Një operacion mund të jetë pranuar, por ende jo përfunduar. Një shërbim mund ta ketë përpunuar, ndërsa një tjetër ende jo. Në këtë nivel, menaxhimi i gjendjes së procesit bëhet po aq i rëndësishëm sa vetë përpunimi i tij.

“E saktë” nuk do të thotë gjithmonë “e përditësuar në të njëjtën milisekondë kudo”

Kur një sistem përbëhet nga disa aplikacione, databaza dhe shërbime, lind një tjetër vendim arkitekturor: sa shpejt duhet të përhapet një ndryshim në të gjithë ekosistemin?

Për disa të dhëna, konsistenca duhet të jetë e menjëhershme. Për të tjera, një vonesë prej disa sekondash mund të jetë krejtësisht e pranueshme.

Ky dallim ka rëndësi sepse përpjekja për ta bërë çdo informacion të sinkronizohet menjëherë kudo mund të krijojë kompleksitet dhe ngarkesë të panevojshme.

Arkitektura e mirë nuk aplikon të njëjtën zgjidhje për çdo të dhënë. Ajo përcakton ku kërkohet konsistencë e menjëhershme, ku mund të pranohet sinkronizim gradual dhe cili sistem është burimi kryesor i informacionit.

Shkallëzimi është problem koordinimi, jo vetëm kapaciteti

Mund të shtohen serverë. Mund të rritet fuqia e databazës. Mund të shpërndahet trafiku në më shumë instanca.

Por nëse sistemi nuk ka rregulla të qarta për mënyrën si koordinohen veprimet, më shumë kapacitet mund të nënkuptojë thjesht më shumë procese që konkurrojnë për të njëjtat të dhëna me shpejtësi më të madhe.

Pikërisht këtu scalability lidhet me arkitekturën.

Në Soft & Solution Group, projektimi i sistemeve që duhet të funksionojnë në shkallë përfshin jo vetëm performancën dhe infrastrukturën, por edhe mënyrën si menaxhohen të dhënat, proceset paralele, komunikimi mes shërbimeve dhe sjellja e sistemit kur një pjesë e tij vonohet ose një kërkesë përsëritet.

Sepse një platformë e qëndrueshme duhet të ruajë të njëjtën logjikë edhe kur volumi ndryshon.

Arkitektura shihet më qartë pikërisht kur sistemi vihet nën presion

Në përdorim normal, shumë vendime arkitekturore janë të padukshme. Ato bëhen të rëndësishme kur mijëra kërkesa mbërrijnë njëkohësisht, një shërbim përgjigjet më ngadalë, një mesazh dërgohet dy herë ose disa procese përpiqen të ndryshojnë të njëjtin informacion.

Siç e përmbledh Ermal Beqiri, themelues i Soft & Solution Group:

“Në një sistem kompleks, çdo veprim është pjesë e një zinxhiri më të madh. Arkitektura krijon rregullin që i mban këto procese të koordinuara, të dhënat të sakta dhe sistemin të qëndrueshëm edhe kur shumë veprime zhvillohen njëkohësisht.”

Një sistem i projektuar për shkallë nuk synon thjesht të bëjë më shumë gjëra në të njëjtën kohë. Ai duhet të sigurojë që, ndërsa gjithçka ndodh paralelisht, sistemi vazhdon të sillet si një i tërë.