Sistem Dizaynı (System Design) Nədir? Milyonlarla İstifadəçi üçün Arxitektura Bələdçisi

Təsəvvür edin ki, yeni bir startap qurmusunuz və möhtəşəm bir mobil tətbiq və ya veb platforma yaratmısınız. İlk günlərdə hər şey qaydasındadır: platformanızda cəmi 100 aktiv istifadəçi var və aylıq 5 dollarlıq sadə bir virtual server (VPS) bütün sorğuları asanlıqla idarə edir. Lakin məhsulunuz viral olur, sosial şəbəkələrdə trendə çevrilir və bir neçə gün ərzində istifadəçi sayı 100-dən 1 milyona yüksəlir. Birdən-birə serveriniz çökür, verilənlər bazası (database) kilidlənir və istifadəçilər xəta mesajları ilə qarşılaşırlar.

Bu ssenari texnologiya dünyasında ən çox rast gəlinən uğursuzluq hekayələrindən biridir. Məhz bu məqamda köməyə Sistem Dizaynı (System Design) gəlir. Sistem dizaynı, bir proqram təminatının yalnız işlək olmasını deyil, həm də milyonlarla istifadəçi altında çökmədən, sürətli və təhlükəsiz şəkildə fəaliyyət göstərməsini təmin edən memarlıq sənətidir.

Bu bələdçidə biz yüksək yüklü (high-load) sistemlərin arxitekturasını, miqyaslanma (scaling) strategiyalarını, keşləmə (caching) mexanizmlərini və verilənlər bazasının optimallaşdırılmasını ən sadə və praktiki yollarla izah edəcəyik.

---

1. Şaquli (Vertical) və Üfüqi (Horizontal) Miqyaslanma#

Sisteminizə gələn yük artdıqda, bu yükü qarşılamaq üçün iki əsas miqyaslanma (scaling) yolunuz var: Şaquli və Üfüqi.

Şaquli Miqyaslanma (Vertical Scaling / Scale-up): Mövcud olan tək bir serverin gücünü artırmaqdır. Yəni, serverə daha çox RAM, daha güclü CPU (mərkəzi prosessor) və ya daha sürətli SSD disklər əlavə edirsiniz. Bu, ilkin mərhələdə çox asandır, çünki proqram kodunda heç bir dəyişiklik etməyə ehtiyac qalmır.

Üfüqi Miqyaslanma (Horizontal Scaling / Scale-out): Sistemə eyni gücdə yeni serverlər əlavə etməkdir. Tək bir nəhəng server yerinə, yan-yana işləyən 10, 50 və ya 100 kiçik serverdən ibarət bir şəbəkə qurursunuz.

Hansını Seçməli? (Müqayisə Cədvəli)

Sistem dizaynı edərkən bu iki yanaşmanın üstünlüklərini və çatışmazlıqlarını bilmək çox vacibdir:

Müasir böyük miqyaslı sistemlər (məsələn, Netflix, Uber, Instagram) tamamilə üfüqi miqyaslanma üzərində qurulmuşdur. Çünki heç bir super-kompüter təkbaşına saniyədə yüz minlərlə sorğunu idarə edə bilməz.

---

2. Yük Balanslaşdırıcılar (Load Balancers): Trafikin Ağıllı Paylanması#

Üfüqi miqyaslanmadan istifadə etdikdə, qarşımıza yeni bir problem çıxır: Gələn milyonlarla istifadəçi sorğusunu bu çoxsaylı serverlər arasında necə ədalətli və bərabər paylamalıyıq?

Bu problemi həll edən komponent Yük Balanslaşdırıcı (Load Balancer) adlanır. Load Balancer, istifadəçi ilə serverlər arasında dayanan bir növ "yol polisi"dir. O, gələn hər bir sorğunu qəbul edir və əvvəlcədən müəyyən edilmiş alqoritmlərə əsasən boş olan və ya ən az yüklənmiş serverə yönləndirir.

Ən Populyar Load Balancing Alqoritmləri:

1. Round Robin: Sorğuları sırayla serverlərə paylayır (1-ci sorğu Server A-ya, 2-ci Server B-yə, 3-cü Server C-yə və s.).
2. Least Connections: Sorğunu hazırda ən az aktiv bağlantısı olan serverə göndərir.
3. IP Hash: İstifadəçinin IP ünvanını riyazi olaraq hesablayır və həmin istifadəçini həmişə eyni serverə yönləndirir (bu, sessiya məlumatlarının qorunması üçün faydalıdır).

Nginx ilə Sadə Load Balancer Konfiqurasiyası

Aşağıda ən populyar veb serverlərdən biri olan Nginx vasitəsilə sadə bir yük balanslaşdırıcının necə qurulduğunu göstərən konfiqurasiya nümunəsi verilmişdir:

# Nginx Load Balancer Konfiqurasiyası
http {
    # Gələn sorğuların paylanacağı serverlər qrupu
    upstream my_backend_servers {
        # 'weight' parametri ilə güclü serverə daha çox yük verə bilərik
        server backend1.example.com weight=3; 
        server backend2.example.com;
        server backend3.example.com;
    }

    server {
        listen 80;
        server_name my-startup.com;

        location / {
            # Bütün gələn müraciətləri yuxarıdakı serverlər qrupuna yönləndir
            proxy_pass http://my_backend_servers;
            
            # İstifadəçinin real IP ünvanını arxa plan serverlərinə ötür
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        } 
    }
}

---

3. Keşləmə (Caching) Strategiyaları: Sistem Sürətinin Artırılması#

Sistem dizaynında ən qızıl qaydalardan biri budur: "Ən sürətli sorğu, heç vaxt icra olunmayan sorğudur."

Hər dəfə istifadəçi ana səhifəni açdıqda verilənlər bazasına (database) müraciət etmək həm vaxt aparır, həm də bazanı yükləyir. Verilənlər bazası sorğuları diskdən oxunduğu üçün nisbətən yavaşdır. Keşləmə (Caching) isə tez-tez tələb olunan məlumatları müvəqqəti olaraq ultra-sürətli operativ yaddaşda (RAM) saxlamaq texnologiyasıdır.

Keş Harada Tətbiq Olunur?

• Brauzer Səviyyəsində: Şəkillər, CSS və JavaScript faylları istifadəçinin öz kompüterində keşlənir.
• CDN (Content Delivery Network): Statik fayllar istifadəçiyə coğrafi cəhətdən ən yaxın olan serverlərdə (məsələn, Cloudflare) saxlanılır.
• Tətbiq Səviyyəsində (Application Cache): Verilənlər bazasından gələn mürəkkəb sorğuların nəticələri Redis və ya Memcached kimi RAM-da işləyən bazalarda saxlanılır.

Cache-Aside (Dairəvi Keşləmə) Strategiyası

Bu, ən çox istifadə olunan keşləmə strategiyasıdır. İş prinsipi olduqca sadədir:

1. Tətbiq məlumatı tələb edir.
2. İlk olaraq keşə (Redis) baxılır (Cache Hit).
3. Məlumat keşdə varsa, dərhal istifadəçiyə qaytarılır.
4. Məlumat keşdə yoxdursa (Cache Miss), verilənlər bazasından oxunur, keşə yazılır və sonra istifadəçiyə qaytarılır.

[İstifadəçi] ---> [Tətbiq] --(1. Keşdə var?)--> [Redis (Cache)]
                     |                               |
                     | (Xeyr, Cache Miss)            | (Bəli, Cache Hit)
                     v                               v
             [Verilənlər Bazası] -------------> [İstifadəçiyə Cavab]

---

4. Verilənlər Bazası Miqyaslanması (Database Scaling)#

Sistem böyüdükcə ən böyük darboğaz (bottleneck) həmişə verilənlər bazasında yaranır. Çünki tətbiq serverlərini üfüqi olaraq asanlıqla artıra bilsək də, bütün bu serverlərin eyni verilənlər bazasına yazması və oxuması qarışıqlıq yaradır. Bazanı miqyaslamaq üçün aşağıdakı üsullardan istifadə olunur:

A. Replikasiya (Database Replication - Master-Slave)

Bu yanaşmada verilənlər bazası iki və ya daha çox serverə bölünür:

• Master (Əsas) DB: Yalnız məlumatların yazılması (Write), yenilənməsi (Update) və silinməsi (Delete) əməliyyatlarını yerləşdirir.
• Slave (Köməkçi) DB-lər: Master bazadakı məlumatları anlıq olaraq kopyalayır (replicate edir) və yalnız oxuma (Read) sorğularına cavab verir.

Sosial şəbəkələr kimi layihələrdə oxuma sorğuları (məsələn, postları görmək) yazma sorğularından (məsələn, post paylaşmaq) 10 dəfə çox olduğu üçün bu strategiya bazanın yükünü inanılmaz dərəcədə azaldır.

B. Şardinq (Sharding / Horizontal Partitioning)

Şardinq, nəhəng bir verilənlər bazası cədvəlini müəyyən bir məntiqə əsasən daha kiçik hissələrə bölərək fərqli serverlərdə saxlamaqdır.

Məsələn, 10 milyonluq istifadəçi cədvəliniz varsa:

• İstifadəçi ID-si 1 ilə 5 milyon arasında olanlar Server A-da saxlana bilər.
• İstifadəçi ID-si 5 milyon 1 ilə 10 milyon arasında olanlar Server B-də saxlana bilər.

---

5. Asinxron Rabitə və Mesaj Növbələri (Message Queues)#

Sinxron sistemlərdə hər bir əməliyyat bir-birini gözləyir. Məsələn, istifadəçi qeydiyyatdan keçdikdə, sistem eyni anda həm istifadəçini bazaya yazır, həm xoş gəldiniz e-maili göndərir, həm də profil şəkli yüklənirsə onu sıxır. E-mail serveri yavaş işləyirsə, istifadəçi səhifənin yüklənməsini saniyələrlə gözləməli olur.

Yüksək performanslı sistemlərdə bu cür ağır işlər asinxron olaraq arxa plana keçirilir. Bunun üçün Mesaj Növbələrindən (Message Queues - RabbitMQ, Apache Kafka) istifadə olunur.

İş prinsipi: İstifadəçi qeydiyyat düyməsini sıxdıqda, tətbiq dərhal mesaj növbəsinə "İstifadəçi X qeydiyyatdan keçdi" mesajını atır və istifadəçiyə dərhal "Qeydiyyat uğurludur!" cavabını qaytarır. Arxa planda işləyən müstəqil proqramlar (Workers) isə bu növbədən mesajları götürərək e-maili göndərir və şəkilləri emal edir. İstifadəçi isə heç bir gecikmə hiss etmir.

---

6. Addım-addım Tətbiq Planı: Sıfırdan 1 Milyon İstifadəçiyə Gedən Yol#

Sisteminizi birdən-birə ən mürəkkəb arxitektura ilə qurmaq həm vaxt itkisidir, həm də maliyyə cəhətdən səmərəsizdir (buna Over-engineering deyilir). İnkişaf mərhələli şəkildə aparılmalıdır:

Addım 1: Tək Server (1 - 1,000 İstifadəçi)

Hər şey bir serverin daxilindədir: Veb server (Nginx), Tətbiq (Node.js, Python, PHP və s.) və Verilənlər Bazası (PostgreSQL, MySQL).

Addım 2: Verilənlər Bazasının Ayrılması (1,000 - 10,000 İstifadəçi)

Tətbiq serveri ilə Verilənlər Bazası serverini fiziki olaraq bir-birindən ayırın. Bu, hər iki serverin resurslarını sərbəst istifadə etməsinə şərait yaradır.

Addım 3: Keş və CDN Əlavə Edilməsi (10,000 - 100,000 İstifadəçi)

Statik faylları CDN-ə yönləndirin. Tez-tez sorğulanan verilənlər bazası nəticələrini Redis-də keşləyin. Bu mərhələdə verilənlər bazasına gələn yükün təxminən 70%-i azalacaq.

Addım 4: Üfüqi Miqyaslanma və Load Balancer (100,000 - 500,000 İstifadəçi)

Tətbiq serverlərinin sayını artırın (məsələn, 3 ədəd server). Qarşılarına bir Nginx Load Balancer yerləşdirin. İndi serverlərdən biri sıradan çıxsa belə, sisteminiz işləməyə davam edəcək.

Addım 5: DB Replikasiyası və Mesaj Növbələri (500,000 - 1,000,000+ İstifadəçi)

Verilənlər bazasını Master-Slave arxitekturasına keçirin. Ağır və vaxt aparan prosesləri (məsələn, bildirişlərin göndərilməsi, hesabatların hazırlanması) RabbitMQ və ya Kafka vasitəsilə asinxron edin.

---

Nəticə#

Sistem dizaynı tək bir düzgün cavabı olmayan, tamamilə kompromislər (trade-offs) üzərində qurulmuş bir elmdir. Sisteminizi qurarkən hər zaman layihənizin ehtiyaclarını, büdcənizi və komandanızın texniki biliklərini nəzərə almalısınız.

Unutmayın ki, ən yaxşı sistem dizaynı ən mürəkkəb olanı deyil, mövcud problemi ən az xərclə və ən stabil şəkildə həll edən dizayndır. Startapınızın ilkin mərhələsində sadəliyə üstünlük verin, lakin gələcək böyüməni (scalability) nəzərə alaraq modulyar arxitektura qurmağı unutmayın.