Məqalə | Süni İntellekt Dövründə Proqram Təminatı Memarlığının Əsasları

Proqram mühəndisliyi intizamı, generativ süni intellektin (Generative AI) və böyük dil modellərinin (LLM) kodlaşdırma köməkçiləri kimi ekosistemə inteqrasiya olunması ilə birlikdə tarixinin ən böyük transformasiyalarından birini keçirir. Bu gün alqoritmlər təbii dil əmrlərini saniyələr içində minlərlə sətirlik funksional koda çevirə bilirlər. Ancaq bu misilsiz sürət özü ilə birlikdə çox kritik bir illüziya gətirir: Kodun işləməsi, o kodun doğru bir memarlıq təməlinə, miqyaslanma (scalability) qabiliyyətinə və ya davamlılığa sahib olduğu mənasına gəlmir. Corctaun Universitetinin Təhlükəsizlik və İnkişaf edən Texnologiyalar Mərkəzi tərəfindən aparılan araşdırmalar, proqramçıların süni intellekt tərəfindən yaradılan koda həddindən artıq güvənməyə meylli olduğunu və bu kodların ümumiyyətlə insan tərəfindən yazılanlardan daha təhlükəsiz və ya memarlıq baxımından daha sağlam olduğuna dair yanlış bir inanc daşıdıqlarını ortaya qoymuşdur. Əslində isə, süni intellekt modelləri proqram memarlığının geniş kontekstini, təşkilati biznes hədəflərini, spesifik performans daralma nöqtələrini (bottlenecks) və ya sistemin gələcəkdəki böyümə trayektoriyasını anlaya bilmirlər; yalnız təlim məlumatlarındakı statistik nümunələri (patterns) təkrarlayırlar.

Təməl proqram təminatı mövzularını və memarlıq anlayışlarını mənimsəmədən süni intellektdən istifadə edən bir proqramçı, qısa müddətdə sürətli nəticələr versə də, uzun müddətdə baxımı qeyri-mümkün, təhlükəsizlik boşluqları ilə dolu və performansı gözlənilməz olan nəhəng bir "proqram təminatı zibilliyi" (software junkyard) qurmağa məhkumdur. Süni intellekt tərəfindən yaradılan dizaynlar tez-tez çeviklik mexanizmlərini (retry, circuit breaker) göz ardı edir, gərəksiz abstraksiyalarla (hallucinated abstractions) sistemi mürəkkəbləşdirir və autentifikasiya kimi əsas təhlükəsizlik tədbirlərini ötürür. Buna qarşılıq olaraq, sistem dizaynı, dizayn nümunələri (design patterns), proqram memarlığı və müşahidə edilə bilmə (observability) kimi anlayışlara dərindən hakim olan bir proqram mühəndisi, süni intellekti sadə bir kod istehsalçısı olmaqdan çıxarıb, güclü sistemlər quran strateji bir memarlıq köməkçisinə çevirir. Bu hesabat müasir proqram sistemlərinin qurulmasında həyati əhəmiyyət kəsb edən bu təməl anlayışları, nəzəri əsasları, praktiki tətbiqləri və süni intellekt dövründəki strateji əhəmiyyətləri ilə birlikdə peşəkar bir perspektivdən əhatəli şəkildə incələyir.

1. Proqram Təminatı Dizayn Nümunələri (Design Patterns)

Proqram təminatı dizayn nümunələri, proqramçıların sistem memarlıqlarını qurarkən qarşılaşdıqları ümumi problemlərə qarşı inkişaf etdirilmiş, zamanla sınaqdan keçirilmiş və sübut olunmuş tipik həll şablonlarıdır. Bu nümunələr birbaşa kopyalanıb yapışdırıla bilən hazır kod blokları və ya kitabxanalar deyil, müəyyən bir dizayn probleminin necə həll ediləcəyini göstərən, müəyyən bir kontekstə görə fərdiləşdirilə bilən konseptual planlardır (blueprints). Dizayn nümunələri, mürəkkəblik səviyyələrinə, tətbiq miqyaslarına və əsas məqsədlərinə görə adətən üç əsas kateqoriyaya bölünür: Yaradıcı (Creational), Struktur (Structural) və Davranışsal (Behavioral) nümunələr. Obyekt yaratma proseslərini idarə edən, siniflər arası asılılıqları tənzimləyən və alqoritmik məsuliyyətləri paylayan bu nümunələr, süni intellekt tərəfindən yaradılan kodların standartlaşdırılması və anlaşılanlığının artırılması üçün ortaq bir ünsiyyət dili təmin edirlər.

1.1. Yaradıcı Nümunələr: Singleton və Factory

Yaradıcı nümunələr sistemin vəziyyətinə və kontekstinə uyğun obyekt yaratma mexanizmləri təqdim edərək kodun çevikliyini, yenidən istifadə edilə bilməsini və modulluğunu artırırlar. Birbaşa obyekt yaratma (instantiation) proseslərinin yarada biləcəyi sıx bağlılıq (tight coupling) problemlərinin qarşısını alırlar.

Singleton (Tək) Nümunəsi: Singleton, bir sinfin tətbiqetmənin həyat dövrü ərzində yalnız tək bir nüsxəsinin (instance) var olmasını təmin edən və sistemdəki bütün komponentlərə bu nüsxəyə çata bilmələri üçün qlobal bir giriş nöqtəsi təmin edən olduqca yayılmış bir yaradıcı nümunədir. Konseptual olaraq tətbiqetmənin nüvəsində, sistem resurslarının koordinasiyalı bir şəkildə idarə edilməsi lazım olan hallarda istifadə olunur. Tətbiq mexanizmi əsasən iki addıma əsaslanır: İlk olaraq, sinfin qurucu metodu (constructor) xaricdən girişə bağlanaraq (private edilərək) new açar sözü ilə birbaşa obyekt yaradılmasının qarşısı alınır; ikinci olaraq, sinfin öz daxilində yaradılan tək nüsxəni qaytaran statik bir yaratma metodu (adətən getInstance adlandırılır) təyin edilir. Eynilə bir ölkənin yalnız bir rəsmi hökuməti olması kimi, kimlikləri nə olursa olsun, bu titul səlahiyyətli qrupa giriş təmin edən qlobal bir nöqtəni təmsil edir.

Bu nümunə; verilənlər bazası bağlantı hovuzları (connection pools), tətbiq konfiqurasiya menecerləri, loglama sistemləri və thread hovuzları kimi paylaşılan resurslara sinxron (ehtiyac duyulan anda) girişi idarə etmək üçün idealdır. Java proqramlaşdırma dilindəki Runtime sinfi, sistemin iş vaxtı mühitini təmsil edən klassik bir Singleton nümunəsidir. Ancaq Singleton istifadəsinin ciddi memarlıq riskləri mövcuddur. Dizayn, "Tək Məsuliyyət Prinsipi"ni (Single Responsibility Principle) pozur, çünki sinif həm öz həyat dövrünü idarə etməklə, həm də əsas iş məntiqini icra etməklə vəzifələndirilmişdir. Bundan əlavə, çoxlu iş parçacığı (multithreaded) mühitlərində obyektin ilk tələb anında yaradılması (lazy initialization), eyni vaxtda müraciətlər gəldiyində birdən çox obyektin yaradılmasına səbəb ola bilər; bu da performansı aşağı salan kilid (lock) mexanizmlərinin istifadəsini məcbur edir. Süni intellekt köməkçiləri ümumiyyətlə ən qısa həlli təqdim etməyə meylli olduqlarından, asılılıq inyeksiyası (dependency injection) istifadə etmək əvəzinə Singleton-ı pis bir dizaynın (məsələn komponentlərin bir-birini çox tanıdığı spagetti kodun) üzərini örtmək üçün tez-tez tövsiyə edə bilərlər.

Factory (Fabrik) Nümunəsi: Factory nümunəsi, obyekt yaratma məntiqini müştəri (client) kodundan mücərrədləşdirərək (abstracting) alt siniflərin və ya interfeyslərin hansı obyektlərin yaradılacağına qərar verməsinə imkan tanıyan başqa bir kritik yaradıcı nümunədir. Sistem bir sinfin hansı tip obyektlərə ehtiyac duyacağını əvvəlcədən proqnozlaşdıra bilmədikdə və ya obyekt yaratma proseslərini mərkəzi bir strukturda toplayaraq kod təkrarının qarşısını almaq istədikdə bu nümunəyə müraciət edilir. Əsas strukturunda bir fabrik interfeysi, bu interfeysi tətbiq edən konkret fabrik sinifləri, yaradılacaq məhsulların interfeysləri və konkret məhsul sinifləri yer alır.

İstifadə ssenariləri arasında əməliyyat sisteminə görə fərqli düymə tipləri istehsal edən UI kitabxanaları, MySQL və ya PostgreSQL kimi fərqli verilənlər bazalarına bağlantı təmin edən məlumatlara giriş təbəqələri və ya oyun mühərriklərində fərqli düşmən tiplərinin istehsalı sayıla bilər. Java-nın Calendar sinfi bu modelin real dünyadakı yansımalarından biridir. Factory nümunəsinin istifadəsi "Açıq-Qapalı Prinsipi"nə (Open-Closed Principle) tam uyğun gəlir; sistemə yeni bir məhsul tipi əlavə edilmək istəndikdə, mövcud müştəri kodunu dəyişdirmək əvəzinə sadəcə yeni bir konkret fabrik sinfi əlavə etmək kifayətdir. Ancaq bu çeviklik, hər yeni məhsul ailəsi üçün yeni siniflər və interfeyslər yazılmasını tələb etdiyindən kod bazasında ciddi bir abstraksiya yükü (abstraction overhead) yarada bilər. Süni intellekt əsaslı kod istehsalı alətlərinin tez-tez kontekstdən kənar fabriklər ("over-engineered generic factories") yaradaraq sadə bir əməliyyatı gərəksiz yerə mürəkkəbləşdirdiyi (memarlıq aşınması) məlumdur.

1.2. Davranışsal Nümunələr: Observer

Davranışsal nümunələr alqoritmlərin icrası, obyektlər arasında məsuliyyətlərin bölüşdürülməsi və rabitə şəbəkələrinin idarə edilməsi ilə məşğul olur.

Observer (Müşahidəçi) Nümunəsi: Observer nümunəsi obyektlər arasında bir-çox (one-to-many) bir asılılıq şəbəkəsi quraraq, diqqət mərkəzindəki bir obyektin (Yayımçı/Subject) vəziyyətində hər hansı bir dəyişiklik olduqda, ona bağlı olan bütün digər obyektlərin (Abunəçilər/Observers) avtomatik olaraq xəbərdar edilməsini (notify) və yenilənməsini təmin edən davranışsal bir mexanizmdir. Sistemdəki iki əsas aktyor Publisher (Yayımçı) və Subscriber (Abunəçi) interfeysləridir. Yayımçılar, yeni abunəçilərin siyahıya qoşulmasına və ya siyahıdan çıxmasına imkan tanıyan dinamik bir abunə infrastrukturu barındırırlar. Yeni bir hadisə (event) baş verdikdə yayımçı abunə siyahısını axtarir və hər bir abunəçi obyektində təyin olunmuş bildiriş (update) metodunu çağırır.

Bu nümunə xüsusilə hadisə işləmə sistemlərində (event handling), mesajlaşma platformalarındakı yayımla-abunə ol (pub-sub) mexanizmlərində və istifadəçi interfeyslərini məlumatlardan ayıran Model-View-Controller (MVC) memarlıqlarında sistemin qəlbini təşkil edir. Java Swing və JavaFX daxilindəki hadisə dinləyici (event listener) infrastrukturu birbaşa Observer prinsipləri ilə dizayn edilmişdir. Observer nümunəsi obyektlər arası zəif bağlılığı (loose coupling) mükəmməl şəkildə təmin etsə də, tətbiq mərhələsində diqqət yetirilməzsə, yayımçılar və müşahidəçilər arasında dövri istinadlar (circular references) yarana bilər və yaddaş sızıntılarına (memory leaks) səbəb ola bilər. Bu riski azaltmaq üçün zibil toplayıcının (garbage collector) obyektləri silə bilməsinə imkan tanıyan zəif istinadlardan (weak references) istifadə edilməsi tövsiyə olunur.

Aşağıdakı cədvəl, analiz edilən dizayn nümunələrinin əsas xüsusiyyətlərini və süni intellekt inteqrasiyasındakı potensial risklərini strukturlaşdırılmış şəkildə müqayisə edir:

Dizayn Nümunəsi	Kateqoriya	Əsas Məqsədi və Həll etdiyi Problem	Tez-tez İstifadə Sahələri	Sİ İstifadəsində Mümkün Risklər və Xətalar
Singleton	Yaradıcı	Sinfin yalnız tək bir nüsxəsinin olmasını və qlobal girişi təmin etmək.	Bağlantı hovuzları, konfiqurasiya menecerləri, loglayıcılar.	Çoxlu iş parçacığı təhlükəsizliyi olmayan kod istehsalı, spagetti kodun maskalanması, test edilə bilmənin pozulması.
Factory	Yaradıcı	Obyekt yaratma məntiqini müştəridən mücərrədləşdirmək, polimorfizm ilə çeviklik təmin etmək.	UI komponent istehsalçıları, verilənlər bazası sürücü seçimləri.	Gərəksiz abstraksiya təbəqələri yaratma, həddindən artıq mühəndislik (over-engineering), dərin irsiyyət zəncirləri yaratma.
Observer	Davranışsal	Obyektlər arası bir-çox asılılıq quraraq dinamik hadisə bildirişləri təmin etmək.	MVC memarlıqları, pub-sub sistemləri, event-driven UI.	Dövri istinadlar səbəbindən yaddaş sızıntıları, yaddaş təmizləmə əməliyyatlarının (cleanup) atlanması.

2. Paylanmış Sistemlərdə Çeviklik Nümunələri (Resiliency Patterns)

Müasir, bulud-doğma (cloud-native) və mikroservis əsaslı tətbiqlərdə, aparat nasazlıqları, şəbəkə paket itkiləri, virtual maşın çökmələri və ya ani trafik sıçrayışları nəticəsində yaranan vaxt aşımı (timeout) səbəbindən sistemin hər hansı bir hissəsində xəta (failure) yaşanması bir ehtimal deyil, qəti bir həqiqətdir. Kifayət qədər böyük bir yük altında sistem hər zaman qismən nasazlıq və bərpa vəziyyətində olacaqdır. Əgər proqram memarlığı bu qaçınılmaz xətaları idarə edəcək şəkildə dizayn edilməyibsə, hədəflənən kiçik bir pozulma sürətlə sistem miqyasında bir fəlakətə (cascading failure) çevrilə bilər. Çeviklik nümunələri (Resiliency Patterns) bu qismən xətaların izolyasiyasını təmin etmək, təsir dairəsini (blast radius) məhdudlaşdırmaq, kritik istifadəçi səyahətlərini qorumaq və sistemin öz-özünü bərpa etməsinə və ya nəzarətli şəkildə pisləşməsinə (graceful degradation) imkan tanımaq üçün inkişaf etdirilmiş struktur müdafiə mexanizmləridir.

Süni intellekt köməkçiləri ümumiyyətlə yalnız onlara verilən "xoşbəxt yol" (happy path) ssenariləri üzərindən kod istehsal etdikləri üçün çeviklik mexanizmlərini (vaxt aşımı, yenidən cəhd, dövrə açıcı) koda inteqrasiya etməyi unudurlar; bu da süni intellektlə istehsal edilmiş kodun test mühitlərində qüsursuz işlədiyi halda, real istehsal (production) trafiki altında qəfildən çökməsinə səbəb olur. Buna görə də proqramçıların bu nümunələri əllə (manual) tələb etməsi və tətbiq etməsi məcburidir.

2.1. Yenidən Cəhd (Retry) Nümunəsi

Paylanmış bir bulud mühitində, servislər və uzaq resurslar arasındakı çağırışlar ümumiyyətlə çox qısa bir müddət ərzində (bir neçə millisaniyə və ya saniyə) öz-özünə düzələn "müvəqqəti" (transient) xətalar səbəbindən uğursuz ola bilər. Bu xətalar; qısa müddətli şəbəkə dalğalanmaları, HTTP 408 (İstək Vaxt Aşımı), HTTP 429 (Çox İstək) və ya HTTP 503 (Servis Əlçatmazdır) kimi müvəqqəti status kodları ilə özünü göstərir. Retry nümunəsi, uğursuz olan bir şəbəkə çağırışını və ya əməliyyatı, tənzimlənə bilən bir müddət gözlədikdən sonra müəyyən bir saya qədər yenidən sınayaraq sistemin istifadəçiyə hiss etdirmədən bərpa olunmasını təmin edir.

Ancaq Retry mexanizmi nəzarətsiz istifadə edildikdə sistemin fəlakəti ola bilər. Milyonlarla istəyin eyni anda uğursuz olub, dərhal ardınca eyni anda təkrar istək göndərməsi, hədəf servisə bir DDoS (Dağıtılmış Xidmətdən İmtina) hücumu edilməsinə, yəni "yenidən cəhd fırtınalarına" (retry storms) yol açır. Buna görə də peşəkar tətbiqlərdə mütləq "Eksponensial Geri Çəkilmə" (Exponential Backoff) və "Təsadüfilik" (Jitter) tətbiq edilməlidir. Məsələn, ilk istək HTTP 500 xətası alarsa sistem 2 saniyə gözləyir; ikinci cəhddə xəta davam edərsə gözləmə müddəti ikiqat artırılaraq 4 saniyəyə, üçüncüdə 8 saniyəyə qaldırılır. Jitter əlavə edilməsi isə bu gözləmə müddətlərinə millisaniyəlik təsadüfi kənarlaşmalar əlavə edərək bütün müştərilərin eyni anda serverə yüklənməsinin qarşısını alır. Əlavə olaraq, Retry nümunəsinin tətbiq edildiyi bütün əməliyyatların "idempotent" (neçə dəfə icra edilirsə edilsin verilənlər bazasında eyni nəticəni verən, yan təsir yaratmayan) olması məlumat uyğunsuzluqlarının qarşısını almaq üçün məcburidir.

2.2. Dövrə Açıcı (Circuit Breaker) Nümunəsi

Retry nümunəsi, xətanın müvəqqəti olduğu və əməliyyatın qısa müddət sonra uğurlu olacağı ehtimalına əsaslanır. Ancaq bir verilənlər bazası fiziki olaraq çökmüşsə və ya bir hədəf servis tamamilə oflayndırsa, davamlı olaraq yenidən cəhd etmək yalnız CPU dövrlərini israf edir, yaddaşları doldurur və tətbiq parçacıqlarının asılı qalmasına (thread exhaustion) səbəb olur. Dövrə Açıcı (Circuit Breaker) nümunəsi, uğursuzluq ehtimalı çox yüksək olan əməliyyatların icrasını əngəlləyərək həm çağıran tətbiqin kilidlənməsinin qarşısını alır, həm də xətalı servisə bərpa olunması üçün vaxt tanıyır.

Dövrə açıcılar, elektrik sistemlərindəki qoruyucular (sigortalar) kimi davranan və üç əsas vəziyyətə malik olan bir vəziyyət maşını (state machine) olaraq dizayn edilirlər :

Qapalı (Closed): İstəklər normal olaraq hədəf servisə ötürülür. Sistem arxa planda ardıcıl xətaları və gecikmə (latency) metriklərini davamlı olaraq ölçür. Xəta sayı əvvəlcədən təyin olunmuş bir həddi keçərsə (məsələn ardıcıl 100 uğursuz istək), sistem Açıq vəziyyətə keçir.
Açıq (Open): Hədəf servisə gedən bütün trafik dərhal dayandırılır və istəklər hədəfə çatmadan "Sürətli Uğursuzluq" (Fail Fast) yanaşması ilə birbaşa xəta və ya standart geri dönüş (fallback) qaytarır. Bu, sistemdəki növbə yığılmasını dayandırır.
Yarı Açıq (Half-Open): Tənzimlənmiş bir fasilə müddəti (DurationOfBreak) keçdikdən sonra dövrə açıcı, hədəf servisin düzəlib-düzəlmədiyini test etmək üçün məhdud sayda "zond" (probe) istəyinin keçməsinə icazə verir. Əgər bu sınaq istəkləri uğurlu olarsa sistem problemin həll olunduğuna qənaət gətirərək Qapalı vəziyyətə keçir; uğursuz olarsa fasilə müddətini sıfırlayaraq Açıq vəziyyətə qayıdır. Tipik bir memarlıqda Retry və Circuit Breaker birlikdə istifadə olunur; tətbiq, Retry nümunəsini bir Circuit Breaker üzərindən çağıraraq həm müvəqqəti xətaları aşır, həm də qalıcı nasazlıqlarda sürətlə reaksiya verir.

2.3. Bölmə (Bulkhead) və Vaxt Aşımı (Timeout)

Bölmə (Bulkhead) Nümunəsi: Adını dənizçilik terminologiyasından, gəmilərin gövdəsini su keçirməyən kompartmanlara ayıran bölmələrdən alan bu nümunə, proqram sistemlərində tam bir fəlakətin qarşısını almaq üçün istifadə olunur. Əgər bütün xüsusiyyətlər və mikroservislər eyni resurs hovuzunu (eyni verilənlər bazası bağlantılarını, eyni prosessor thread-lərini) paylaşırsa, arxa planda işləyən və intensiv resurs istehlak edən "səs-küylü bir qonşu" (noisy workload), ödəniş etmək istəyən müştərilərin sistem resurslarını tükədərək bütün platformanı çökdürə bilər. Bulkhead nümunəsi, kritik və kritik olmayan əməliyyatlar üçün ayrı thread/bağlantı hovuzları yaradaraq resursları izolyasiya edir və problemin təsir dairəsini bir alt sistemlə məhdudlaşdırır.

Vaxt Aşımı (Timeout) Nümunəsi: Paylanmış memarlıqlarda ən təhlükəli vəziyyət tətbiqin çökməsi deyil, tətbiqin asılı (hanging) qalmasıdır. Hədəf servisdən heç vaxt cavab gəlməməsi, o servisi gözləyən thread-lərin sonsuza qədər bloklanması deməkdir. Timeout nümunəsi, çağıran komponentin bir cavab üçün gözləyəcəyi maksimum müddəti qəti şəkildə məhdudlaşdırır; müddət bitdikdə əməliyyat dayandırılaraq resurslar dərhal sərbəst buraxılır.

2.4. Geri Çəkilmə (Fallback) və Nəzarətli Pisləşmə (Graceful Degradation)

Bir istək uğursuz olduqda (Retry limitləri dolduqda və ya Circuit Breaker dövrəni açdıqda), müasir sistemlər son istifadəçiyə anlamsız bir server xətası (HTTP 500) göstərmək əvəzinə alternativ strategiyalar tətbiq etməlidir. Geri çəkilmə ssenariləri aşağıdakıları əhatə edə bilər:

Nəzarətli Pisləşmə (Graceful Degradation): Elektron ticarət platformasında fərdiləşdirilmiş məhsul tövsiyə servisi çökərsə, sistem xəta fırlatmaq əvəzinə standart (ən çox satılanlar) məhsul siyahısını göstərərək əsas istifadəçi axınını davam etdirməlidir.
Köhnə Keş (Stale Cache): Mənbə servisə çatmaq mümkün olmadıqda, istifadəçilərə açıq şəkildə "məlumatların aktual olmadığı" bildirilərək keşdə qalan son etibarlı məlumatlar təqdim edilə bilər.
Asinxron Bərpa: Kritik əməliyyatlar (məsələn sifariş təsdiqi) bir mesaj növbəsinə alınır və hədəf sistem ayağa qalxdıqda asinxron olaraq işlənməyə davam edir.

Aşağıdakı cədvəl, tez-tez rast gəlinən sistem xətalarını və bu xətalarla mübarizə aparmaq üçün istifadə edilməsi lazım olan doğru çeviklik nümunələrini ümumiləşdirir:

Xəta Simptomu / Problemin Mənbəyi	İdeal Çeviklik Nümunəsi	İşləmə Mexanizmi və Əsas Məqsədi
Şəbəkə dalğalanmaları, qısamüddətli qırılmalar (HTTP 503, 408)	Retry (Yenidən Cəhd)	Müəyyən bir limit daxilində, eksponensial geri çəkilmə (exponential backoff) ilə əməliyyatı təkrarlayaraq müvəqqəti problemləri aşmaq
Verilənlər bazasının çökməsi, hədəf servisin tamamilə əlçatmaz olması	Circuit Breaker	Problemli hədəfə gedən trafiki kəsərək (Fail Fast) resurs israfının qarşısını almaq və sistemə bərpa olunması üçün vaxt vermək
Arxa plan əməliyyatının bütün sistem resurslarını (CPU/RAM) istehlak etməsi	Bulkhead (Bölmə)	Kritik əməliyyatlar üçün ayrı bağlantı/thread hovuzları ayıraraq problemi tək bir sahəyə həbs etmək (izolyasiya)
Servisin cavab vermədən sonsuza qədər asılı qalması (Hanging)	Timeout (Vaxt Aşımı)	Maksimum gözləmə müddətini təyin edərək bağlantıların və thread-lərin bloklanmasının qarşısını almaq
Servis xətası sonrası istifadəçi təcrübəsinin kəsilməsi	Fallback (Geri Çəkilmə)	Xəta fırlatmaq əvəzinə köhnə keşi istifadə etmək və ya nəzarətli pisləşmə (graceful degradation) ilə axını qorumaq

3. Proqram Təminatı Memarlığı (Software Architecture)

Proqram memarlığı bir sistemin ən yüksək səviyyəli struktur dizaynıdır. Tətbiqin necə hissələrə bölünəcəyi, bu hissələrin bir-biri ilə necə əlaqə quracağı, məlumatların harada və necə saxlanılacağı kimi dəyişdirilməsi ən bahalı və ən çətin qərarlar memarlıq mərhələsində qəbul edilir. Təşkilati hədəflər, komandanın böyüklüyü, bazara çıxış vaxtı (time to market) və gələcəkdəki miqyaslanma ehtiyacları, doğru memarlıq yanaşmasının seçilməsində kritik amillərdir.

3.1. Monolitik Memarlıq (Monolithic Architecture)

Monolitik memarlıq, tətbiqin istifadəçi interfeysi (UI), server tərəfi iş məntiqi, məlumatlara giriş təbəqəsi və verilənlər bazası inteqrasiyalarının tək, nəhəng bir icra edilə bilən fayl (executable) və ya tək bir kod bazası (codebase) daxilində birləşmiş bir struktur olaraq inkişaf etdirilməsidir. Tarixən sənaye standartı olan bu model, adətən buzlaq böyüklüyündə, sağlam amma çevik olmayan strukturlara bənzədilir.

Üstünlükləri və Güclü Yönləri: İnkişaf dövrünün başlanğıc mərhələsində, xüsusilə kiçik komandalar və hələ məhsul-bazar uyğunluğunu axtaran startaplar üçün bənzərsiz bir sürət təqdim edir. Tətbiqin hamısı tək bir qovluqda yerləşdiyi üçün kompilyasiya və yerləşdirmə (deployment) prosesləri son dərəcə sadədir. Hər şey tək bir yerdə işlədiyi üçün uçdan-uca testlər (end-to-end testing) sürətlə edilə bilər və xəta anında istəyi başdan sona izləmək (debugging) mikroservislərə nisbətən çox daha asandır. Əlavə olaraq, şəbəkə üzərindən məlumat ötürülməsi olmadığı (ünsiyyət yaddaş daxili metod çağırışları ilə edildiyi) üçün başlanğıcda performansı olduqca yüksəkdir.
Dezavantajları və Sərhədləri: Kod bazası zamanla böyüyüb mürəkkəbləşdikcə (sprawl), kiçik bir mətn dəyişikliyi belə bütün nəhəng tətbiqin yenidən kompilyasiya edilməsini, test edilməsini və yerləşdirilməsini məcbur edir; bu da proqramçı sürətini və çevikliyi (agility) öldürür. Monolitlər "sıx bağlılığa" (tight coupling) məhkumdur; bir modulda edilən kiçik bir xəta bütün sistemin çökməsinə səbəb ola bilər. Texnoloji çeviklik sıfıra yaxındır; layihəyə tək bir proqramlaşdırma dili və ya çərçivə (framework) ilə başlanılıbsa yeni texnologiyaları sistemə inteqrasiya etmək qeyri-mümkün hala gəlir (Tech stack lock-in). Miqyaslanma baxımından böyük bir israf yaradır; tətbiqin yalnız "Ödəniş" modulunda bir darboğaz olsa belə, bütün monolitik tətbiqin yeni serverlərdə şaquli və ya üfüqi olaraq kopyalanması lazımdır ki, bu da son dərəcə bahalıdır.

3.2. Mikroservis Memarlığı (Microservices Architecture)

Mikroservis memarlığı, böyük və hantal monolitik quruluşu, hər biri öz iş məntiqinə, öz müstəqil verilənlər bazasına və tək bir spesifik iş hədəfinə sahib olan kiçik, müstəqil olaraq yerləşdirilə bilən xidmətlər kolleksiyasına ayırma fəlsəfəsidir. Mürəkkəbliyi ortadan qaldırmaz, ancaq tapşırıqları izolyasiya edilmiş proseslərə bölərək mürəkkəbliyi daha görünən və idarə edilə bilən hala gətirir.

Üstünlükləri və Güclü Yönləri: Ən böyük gücü müstəqil miqyaslanabilmə (independent scalability) və xəta izolyasiyasıdır (fault isolation). Tələb artdıqda yalnız darboğaz yaşayan servis (məsələn səbət servisi) üfüqi olaraq miqyaslanır, resurslardan səmərəli istifadə edilir. Hər mikroservis komandası, həll edəcəkləri problemə ən uyğun proqramlaşdırma dilini, verilənlər bazasını (polyglot persistence) və alətlər dəstini seçməkdə sərbəstdir (Technology flexibility). Davamlı inteqrasiya və davamlı çatdırılma (CI/CD) boru kəmərləri (pipelines) sayəsində komandalar bir-birini gözləmədən avtonom işləyə və bazara çıxış müddətini sürətləndirə bilərlər. Bir servisin çökməsi, doğru çeviklik nümunələri (məsələn Circuit Breaker) istifadə edildiyi təqdirdə bütün tətbiqi çökdürməz.
Dezavantajları və Əməliyyat Yükü: Müstəqillik, dəhşətli bir əməliyyat mürəkkəbliyi gətirir. Qabaqcıl DevOps təcrübələri, izləmə alətləri, konteyner orkestrasyonu (Kubernetes) olmadan mikroservislər idarə edilə bilməz. Servislər bir-biri ilə artıq yaddaş üzərindən deyil, şəbəkə (network) üzərindən REST və ya gRPC ilə danışdıqları üçün ciddi şəbəkə gecikmələri (network latency) yaşanır. Paylanmış məlumat idarəetməsi səbəbindən məlumat ardıcıllığını təmin etmək, inteqrasiya testlərini aparmaq və xəta ayırmaq (tracing requests across services) çox zəhmətlidir. Uber nümunəsində olduğu kimi, tək bir istəyin minlərlə mikroservis üzərindən keçməsi "Paylanmış İzləmə" (Distributed Tracing) zərurətini doğurur.

3.3. Hadisəyə Əsaslanan Memarlıq (Event-Driven Architecture)

Mikroservislər nə qədər müstəqil qurulsa da, əgər bir-biri ilə sinxron (eşzamanlı) RESTful API-lər üzərindən əlaqə qururlarsa, bu vəziyyət "gizli asılılıqlar" yaradır. API əsaslı ünsiyyətdə Servis A işləməyə davam etmək üçün Servis B-dən cavab gözləmək məcburiyyətindədir. Əgər Servis B yavaşlayarsa və ya çökərsə, gözləmə müddətləri zəncirvari olaraq artar (cascading failures), thread-lər bloklanar və miqyaslama üstünlüyü yox olar; bu quruluş əslində paylanmış bir monolitdən fərqlənmir.

Hadisəyə Əsaslanan Memarlıq (EDA) bu tıxanmaları aradan qaldırmaq üçün asinxron kommunikasiya modelini mənimsəyir. Sistem bir-birini gözləyən API istəkləri əvəzinə, bir vəziyyət dəyişikliyi olduqda (məsələn: "İstifadəçi Qeydiyyatdan Keçdi") mərkəzi bir vasitəçiyə (Message Broker - Apache Kafka və s.) bir "Hadisə" (Event) göndərir (Publish). Bu hadisə ilə maraqlanan bütün digər servislər (Mükafat servisi, E-poçt servisi), bu vasitəçiyə abunə (Subscribe) olaraq hadisələri öz sürətləri ilə çəkir və işləyirlər.

EDA-nın əsas üstünlüyü fövqəladə dərəcədə zəif bağlılıq (loose coupling) təmin etməsidir; hadisə yayımlayan servisin, o hadisəni istehlak edən servislərin kim olduğundan, ayaqda olub-olmadıqlarından xəbəri belə yoxdur. Bu vəziyyət şəbəkə trafikini optimallaşdırır, tıxanmaları (blocking) əngəlləyir və sistemin çevikliyini maksimuma çatdırır. Ancaq EDA dizaynı, sistemin qəti ardıcıl (strong consistency) quruluşundan imtina edib, "Son Ardıcıllıq" (Eventual Consistency) modelini qəbul etməsini tələb edir; məlumatlar fərqli servislərdə anlıq olaraq sinxronizasiya olmaya bilər, lakin zamanla ardıcıl hala gəlirlər. Həmçinin hadisələrin sırasını qorumaq (event ordering) və mürəkkəb iş axınlarını izləmək (debugging) klassik metodlara nisbətən daha yüksək mühəndislik bacarığı tələb edir.

Memarlıq Yanaşması	Ünsiyyət Stili və Məlumat Axını	Miqyaslanabilmə	İstifadə Çətinliyi və Əsas Dezavantajlar
Monolitik	Yaddaş daxili (In-memory) sinxron çağırışlar. Mərkəzi verilənlər bazası.	Aşağı. Yalnız şaquli və ya tətbiqin hamısı üfüqi olaraq miqyaslana bilər	Dəyişim çətinliyi, texnologiya kilidi (lock-in), böyük komandaların toqquşması
Mikroservislər (RESTful)	Şəbəkə üzərindən sinxron API çağırışları (REST/gRPC). Paylanmış məlumat depoları.	Yüksək. Hər servis tələbə görə müstəqil miqyaslanır.	Şəbəkə gecikməsi, API asılılıq zənciri səbəbindən darboğaz yaranması, əməliyyat mürəkkəbliyi
Hadisəyə Əsaslanan (EDA)	Message Broker (Kafka və s.) üzərindən asinxron "Yayımla-Abunə Ol" ünsiyyəti	Çox Yüksək. Servislər bir-birini gözləməz, anlıq yükləri növbələr əmir	Son ardıcıllıq (Eventual consistency) idarəetməsi, mürəkkəb xəta izləmə, hadisə sıralamasını zəmanət etmə çətinliyi

3.4. Təmiz Memarlıq (Clean Architecture)

Proqram sənayesində bir memarlığın uğuru, iş məntiqinin (business rules) xarici dünyadakı texnoloji dəyişikliklərdən (istifadəçi interfeysləri, verilənlər bazaları, xarici framework-lər) nə qədər qorunduğu ilə ölçülür. Robert C. Martin (Uncle Bob) tərəfindən ədəbiyyata gətirilən Təmiz Memarlıq (Clean Architecture), Soğan Memarlığı (Onion Architecture) və Heksaqonal Memarlıq (Ports and Adapters) kimi yanaşmaların ən yaxşı xüsusiyyətlərini birləşdirən bütöv bir fəlsəfədir. Sistemin qəlbini xarici təsirlərdən təcrid edərək test edilə bilməni, davamlılığı və müstəqilliyi mərkəzə alır.

Memarlığın nüvəsində, sistemin ən mücərrəd və ən stabil komponentlərindən, ən konkret və ən dəyişkən komponentlərinə doğru genişlənən dörd konsentrik təbəqə yerləşir :

Mövcudluqlar (Entities - Nüvə): Sistemin ən iç təbəqəsində, qurum səviyyəsində qüvvədə olan yüksək səviyyəli, kritik iş qaydalarını əhatə edən Mövcudluqlar yerləşir. Bu təbəqə xarici dünyadan tamamilə izolyasiya edilmişdir; səhifə naviqasiyasındakı bir dəyişiklik və ya verilənlər bazası tipinin dəyişdirilməsi bu obyektlərə qətiyyən təsir etməməlidir.
İstifadə Ssenariləri (Use Cases / Interactors): Bir xarici təbəqədə yerləşən bu bölgə, tətbiqə xas iş qaydalarını ehtiva edir. Məlumat axınını təşkil edir və Mövcudluqların öz iş qaydalarını istifadə edərək sistemin hədəflərinə (məsələn "Bank Transferi" əməliyyatı) çatmasını təmin edirlər.
İnterfeys Adaptorları (Interface Adapters): İç təbəqələrin anladığı format ilə xarici dünyanın (Verilənlər bazası, UI, Web) anladığı format arasında bir körpü və tərcüməçi rolunu oynayırlar. Ənənəvi MVC (Model-View-Controller) strukturları ilə verilənlər bazası Repository implementasiyaları bu təbəqədə yerləşir. SQL sorğularının yazıldığı ən iç sərhəd buradır.
Çərçivələr və Sürücülər (Frameworks and Drivers): Ən xarici təbəqədir və sistemin detallarını barındırır. Verilənlər bazası idarəetmə sistemləri, Web Framework-ləri, UI kitabxanaları və digər xarici cihaz inteqrasiyaları burada yerləşir. Bu komponentlər tez-tez dəyişməyə meyllidir.

Təmiz Memarlığın Onurğası: Asılılıq Qaydası (The Dependency Rule)

Təmiz memarlığı işlək edən mütləq qanun, "Asılılıq Qaydası"dır. Bu qaydaya görə, mənbə kod asılılıqları yalnız içəriyə doğru işarə edə bilər. İçdəki bir çəmbərdə (təbəqədə) yerləşən heç bir sinif, funksiya, dəyişən və ya məlumat formatı, xarici çəmbərdəki bir struktura istinad verə bilməz və ya onun adını çəkə bilməz.

Ancaq bir İstifadə Ssenarisinin (iç təbəqə), nəticəni ekranda göstərmək üçün Presenter-ı (xarici təbəqə) çağırması lazım olduqda və ya verilənlər bazasından məlumat oxuması lazım olduqda bir ziddiyyət yaranır. Asılılıq içəriyə doğru olarkən nəzarət axını xaricə necə çıxır? Budur, burada "Asılılığın Tərsinə Çevrilməsi Prinsipi" (Dependency Inversion Principle - SOLID-in D hərfi) dövrəyə girir. İç təbəqə öz daxilində bir "İnterfeys" (Interface) təyin edir və kodu bu interfeys üzərindən işlədir. Xarici təbəqədəki verilənlər bazası və ya UI adaptoru bu interfeysi tətbiq edir (implement edir). Beləliklə, asılılıq yenə interfeysin olduğu iç təbəqəyə doğru qalarkən, işləmə zamanında (runtime) nəzarət xaricə ötürülmüş olur.

Süni intellekt köməkçiləri ümumiyyətlə ən sürətli həlli istehsal etmək üçün təbəqələri bir-birinə qarışdıran (məsələn, birbaşa Entity sinfi daxilində SQL sorğusu yazan) kodlar yaradırlar. Təmiz Memarlıq qaydalarına hakim olan bir proqramçı, Sİ-nin istehsal etdiyi bu struktur pozuntularını (architectural smells) dərhal fərq edib düzəldə bilər; əks halda nəzarətsiz buraxılan bir Sİ kodu bütün sistemin çevikliyini qalıcı olaraq məhv edir.

4. Sistem Dizaynı Anlayışları (System Design Concepts)

Bir tətbiqin istifadəçi sayı onlarla şəxsdən milyonlarla şəxsə yüksəldikdə, yaxşı bir proqram memarlığı tək başına kifayət etmir; altda yatan sistem dizaynının fiziki infrastruktur limitlərini aşacaq şəkildə qurulması lazımdır. Sistem dizaynı tutum problemlərini həll etmə, məlumat böyüməsini idarə etmə və fəlakət ssenarilərinə qarşı aparat səviyyəsində tolerantlıq təmin etmə sənətidir.

4.1. Miqyaslandırma (Scaling) və Yük Tənzimləyicilər (Load Balancers)

Trafikin artdığı hallarda sistem mühəndislərinin qarşısında iki əsas seçim var:

Şaquli Miqyaslandırma (Vertical Scaling - Scale-Up): Mövcud tək bir serverin resurslarını (CPU, RAM, Yaddaş) fiziki olaraq artırmaq deməkdir. Tətbiqdə heç bir dəyişiklik tələb etməməsi böyük bir üstünlükdür. Ancaq aparatın çatıla biləcək mütləq bir fiziki sərhədi var və sistem tək bir maşına bağlı qaldığı üçün "Tək Nöqtə Xətası" (Single Point of Failure - SPOF) riski daşıyır; server çökərsə bütün tətbiq qapanır.
Üfüqi Miqyaslandırma (Horizontal Scaling - Scale-Out): Sistemə tutum qatmaq üçün daha güclü bir maşın almaq əvəzinə, şəbəkəyə eyni tətbiqi işlədən yeni kompüterlər (düyünlər/nodes) əlavə etməkdir. Sistemə xəta tolerantlığı (fault-tolerance), ehtiyatlılıq (redundancy) və limitsiz böyümə tutumu qazandırır.

Sistem üfüqi olaraq miqyaslandıqda (məsələn 3 veb server olduqda), istifadəçi istəklərinin hansı serverə yönləndiriləcəyini təyin edən bir "trafik polisi"nə ehtiyac duyulur. Bu vəzifəni Yük Tənzimləyicilər (Load Balancers) öz üzərinə götürür. Yük tənzimləyicilər, istifadəçi tələblərini arxadakı resurs hovuzuna ən səmərəli şəkildə paylayaraq heç bir serverin boş (idle) qalmamasını və ya təkbaşına həddindən artıq yüklənməməsini təmin edir. İstəkləri sırayla paylayan "Round Robin", server tutumlarına görə paylayan "Weighted" (Ağırlıqlı) və ya istəklərin məzmununa görə paylayan "Hashing" kimi müxtəlif alqoritmlərdən istifadə edirlər. Bundan əlavə serverlərin sağlamlığını (Health Checks) periyodik olaraq yoxlayaraq, çökən bir maşına trafik göndərilməsinin qarşısını alırlar.

4.2. Verilənlər Bazası Paradiqmaları: SQL və NoSQL

Sistem dizaynındakı ən kritik ayrılma nöqtələrindən biri məlumat saxlama yanaşmasıdır. Ənənəvi SQL və müasir NoSQL sistemləri arasındakı seçim sadəcə bir texnologiya seçimi deyil, miqyaslanma modelinin seçimidir.

SQL (Relyasiyalı) Verilənlər Bazaları (MySQL, PostgreSQL):

Məlumatları sətirlər və sütunlar şəklində strukturlaşdırılmış cədvəllərdə, qəti bir sxem (predefined schema) ilə saxlayırlar. Hər hansı bir struktur dəyişikliyi, bahalı və təhlükəli sxem miqrasiyaları (schema migrations) tələb edir.
Maliyyə sistemləri kimi məlumat bütövlüyünün xətasız olması lazım olan yerlərdə ACID (Atomicity, Consistency, Isolation, Durability) prinsiplərini güzəştsiz tətbiq edirlər. Bir pul köçürmə əməliyyatı tam mənası ilə ya bütün cədvəllərdə baş verir, ya da heç birində baş vermir (Atomicity).
Relyasiyalı bütövlüyü qoruma mexanizmləri və birləşdirmə (Join) əməliyyatları səbəbiylə təbiətləri etibarilə üfüqi deyil, şaquli olaraq miqyaslanmağa (Scale-Up) daha meyllidirlər. Paylanmış məlumat parçalama (Sharding) tətbiq edilə bilsə də, ACID qaydaları səbəbindən olduqca çətin və qırılqandır.

NoSQL (Relyasiyalı Olmayan) Verilənlər Bazaları (MongoDB, Redis, Cassandra):

İnternet dövrünün "Böyük Məlumat" (Big Data) və yüksək həcmli məlumat axını ehtiyaclarına cavab vermək üçün dizayn edilmişlər. Məlumatı dinamik sxemlərlə sənəd (JSON), açar-dəyər (Key-Value), sütun (Columnar) və ya qraf (Graph) strukturları kimi saxlayırlar.
SQL-in ACID strukturuna qarşılıq NoSQL, CAP Teoremi və BASE (Basically Available, Soft-state, Eventually consistent) prinsiplərini mənimsəyir. Sistem hər an əlçatan olmağı (Availability) və bölünmə tolerantlığını (Partition Tolerance) zəmanət edərkən, mükəmməl anlıq ardıcıllıqdan (Consistency) imtina edərək "son ardıcıllığı" (Eventual Consistency) üstün tutur.
Ən böyük üstünlükləri limitsiz potensialla üfüqi miqyaslanabilmələridir (Scale-Out). Əmtəə aparatlarına (commodity hardware) məlumat kopyaları paylanaraq (Sharding/Replication) yüksək oxuma/yazma sürətlərinə çatılır.

4.3. Sürət Taktikaları: Keşləmə (Caching) və Mesaj Növbələri (Message Queues)

Keşləmə: İstifadəçilərin sistemin sürətini (latency) qavramasında ən həlledici elementdir. Fiziki disklərə (HDD/SSD) edilən verilənlər bazası sorğuları həmişə yavaşdır. Bunu aşmaq üçün tez-tez istifadə olunan məlumatlar millisaniyə altı (sub-millisecond) reaksiya verən In-Memory (Yaddaş Daxili) sistemlərə, məsələn Redis kimi Açar-Dəyər məlumat depolarına alınır. İkinci bir metod isə Məzmun Çatdırılma Şəbəkələri (CDN) istifadə etməkdir; statik fayllar (şəkillər, HTML faylları) orijinal server əvəzinə, istifadəçinin fiziki coğrafiyasına ən yaxın olan proxy serverlərində keşlənərək yüksək əlçatanlıq təmin edilir.

Mesaj Növbələri (RabbitMQ, Kafka): Sistemlər arasında şok əmici (shock absorber) rolunu oynayırlar. Bir tətbiqə yüksək trafik gəldikdə (məsələn, Qara Cümə endirimlərində), bütün istəklər eyni anda işlənməyə çalışılarsa verilənlər bazası çökər. Mesaj növbələri asinxron işləməni mümkün edir; istəklər (məsələn video emalı və ya sifariş qeydiyyatı) növbəyə alınır, veb server istifadəçiyə dərhal cavab qaytarır və arxa plandakı işçi (worker) servislər sıraya girən tapşırıqları öz tutumları daxilində əritməyə başlayır. Bu sayədə məlumat itkisinin qarşısı alınır və sistemin çevikliyi dramatik şəkildə artır.

5. Etibarlılıq, Miqyaslanabilmə və Müşahidə Edilə Bilmə (Observability)

Ənənəvi "izləmə" (monitoring), sistemin mövcud vəziyyəti haqqında əvvəlcədən təyin olunmuş hədlərin (məsələn, CPU istifadəsi %80-i keçdimi?) vəziyyətini hesabat verir. Ancaq müasir, paylanmış və çox təbəqəli memarlıqlarda xətalar gözlənilməz yollarla ortaya çıxır. "Müşahidə edilə bilmə" (Observability), sistemin xarici çıxışlarına (istehsal etdiyi məlumatlara) baxaraq daxili vəziyyətini, mürəkkəb davranışlarını və "niyə" bir şeylərin səhv getdiyini proaktiv şəkildə anlama sənətidir. Müşahidə edilə bilmə, bilinməyən problem rejimlərini (unknown unknowns) kəşf etməyə imkan tanıyır.

Güclü bir müşahidə sistemi, bir-birini dəstəkləyən üç əsas məlumat sütunu (Three Pillars of Observability) üzərində qurulur :

Müşahidə Edilə Bilmə Sütunu	Xarakterik Xüsusiyyətləri və Əhatəli Analizi	Ən Uyğun İstifadə Ssenarisi və Təmin etdiyi Dəyər
Metriklər (Metrics)	Sistem performansını zamanla (intervals) ifadə edən yüngül, toplanıla bilən ədədi məlumatlardır (CPU istifadəsi, yaddaş istehlakı, gecikmə müddəti, xəta dərəcələri). Saxlanılması son dərəcə ucuzdur və zaman seriyası verilənlər bazalarında (Prometheus kimi) tutulurlar	Sistem performansının nəbzini tutmaq, qeyri-adi vəziyyətləri anında təsbit edərək (anomaly detection) real vaxtlı siqnalları tetikləmək. "Sistemdə bir problem varmı?" sualının cavabıdır
Loglar (Logs)	Sistemdə baş verən kəsikli (discrete) hadisələrin zaman damğalı, tarixi və dəyişdirilə bilməyən (immutable) mətn və ya JSON əsaslı dökümüdür. Əhatəli xəta mesajlarını və hadisə kontekstini (stack trace) ehtiva edir. Yüksək trafikli mühitlərdə böyük yaddaş sahələri tələb etdiyindən bahalıdır	Problem anında kök səbəb analizi (root cause analysis) etmək, ətraflı xəta ayırmaq (debugging) və sistemin təhlükəsizlik auditi ilə qanuni uyğunluq (compliance) qeydlərini tutmaq. "Problemin detalı və səbəbi tam olaraq nədir?" sualını cavablandırır.
İzləmələr (Traces)	Paylanmış memarlıqlarda tək bir istifadəçi istəyinin şəbəkə daxilindəki uçdan-uca səyahətinin (request flow) xəritəsini çıxarır. Hər servis keçidi bir "Span" yaradır və bütün proses Trace ID ilə birləşdirilərək valideyn-övlad əlaqəsiylə vizuallaşdırılır	Mikroservis mühitlərindəki performans darboğazlarını, gizli şəbəkə gecikmələrini və uğursuz xidmət asılılıqlarını izolyasiya etmək. "İstək hansı servisdə tıxandı və niyə asılı qaldı?" sualını həll edir

5.1. Xidmət Səviyyəsinin İdarə Edilməsi: SLA, SLO və SLI

Müşahidə məlumatlarını yalnız texniki göstəricilər kimi qiymətləndirmək yanlışdır; bu məlumatlar birbaşa biznes hədəfləri və müştəri məmnuniyyəti ilə əlaqələndirilməlidir. Sistem etibarlılığı bu üç termin ətrafında idarə olunur :

SLA (Service Level Agreement): Müştəri ilə şirkət arasında imzalanan qanuni və maliyyə sanksiyaları olan xidmət müqaviləsidir (Məsələn; "Sistem il ərzində %99.9 əlçatan olacaqdır"). Pozulması təzminat tələb edir.
SLO (Service Level Objective): SLA-nı qorumaq üçün mühəndislik və əməliyyat komandalarının təyin etdiyi daha sərt daxili hədəflərdir. Siqnallar və sistem memarlığı bu hədəflərə uyğun optimallaşdırılır.
SLI (Service Level Indicator): SLO və SLA-nın qarşılanıb-qarşılanmadığını göstərən anlıq, real ölçüm məlumatlarıdır (Məsələn; "Son 1 saatda uğur dərəcəsi %99.95").

SLO mərkəzli bir memarlıq izləmə, xüsusilə süni intellekt alətləri kod yazarkən həyati əhəmiyyətə malikdir. Sİ yaddaşı optimallaşdırmayan, xətalı təmizləmə (cleanup) edən və ya gərəksiz obyektlər (large objects) yaradan kodlar yaza bilər. Bunlar test mərhələsində tutula bilməz, lakin istehsal mühitinə keçdikdən sonra yaddaş idarəetməsi üzərindəki təzyiq (memory pressure) artır; SLO ölçümləri, P95/P99 gecikmələrinin zamanla sinsi bir şəkildə yüksəldiyini anında ortaya çıxararaq gizli memarlıq eroziyasını ifşa edir.

5.2. Məlumatları Korelyasiya Etmək və Tam Yığın (Full-Stack) Müşahidə Edilə Bilmə

Metriklər, loglar və izləmələr öz başlarına güclü olsa da, müasir SRE (Site Reliability Engineering) əməliyyatlarında əsas dəyər bu məlumatların bir-biri ilə korelyasiya edilməsiylə (əlaqələndirilməsiylə) ortaya çıxır. Paylanmış sistemlərdə mühəndislərin yaşadığı ən böyük çətinlik, fərqli alətlərin təmin etdiyi məlumatları uyğunlaşdırmağa çalışarkən yaşadıqları vaxt itkisi və kontekst keçididir (context-switching / Tab Hell).

Mükəmməl korelyasiya edilmiş bir hadisə müdaxiləsi bu şəkildə işləyir: Əvvəlcə aparat səviyyəsindəki bir Metrik, sifariş API-sində anlıq CPU yüksəlməsi və gecikmə olduğunu bildirərək siqnal yaradır. Mühəndis bu siqnala kliklədikdə birbaşa bir İzləmə (Trace) qrafikinə yönləndirilir; burada problemin tətbiqin hamısından deyil, ödəniş doğrulama servisindən (span) qaynaqlandığı təsbit edilir. Son olaraq, bu spesifik span-ə aid "Trace ID" sayəsində milyonlarla sətir arasından tam olaraq o xətanı yaradan Log qeydinə enilir və kod səviyyəsindəki xəta (məsələn verilənlər bazası bağlantı qırıqlığı və ya yetkiləndirmə xətası) net biçimdə görülərək təmir edilir. Bu ardıcıl proses, problemin təsbit edilməsindən həllinə qədər keçən orta müddəti (MTTR - Mean Time to Resolution) möhtəşəm ölçüdə azaldır.