System Design

Load Balancing

Load Balancer — trafikni bir nechta serverlar o’rtasida taqsimlaydigan tizim komponenti.

Muammo

Bitta server million foydalanuvchiga xizmat qila olmaydi:

              ┌─────────┐
1M users ───→ │ Server  │ ←  Overloaded!
              └─────────┘

Natija:

Sekin javob (5+ sekund)
Timeout errors
Server crash

Yechim: Load Balancer

                ┌─────────────┐
                │    Load     │
     Users ───→ │  Balancer   │
                └──────┬──────┘
                       │
       ┌───────────────┼───────────────┐
       ▼               ▼               ▼
   ┌───────┐       ┌───────┐       ┌───────┐
   │Server1│       │Server2│       │Server3│
   └───────┘       └───────┘       └───────┘
   300K users      400K users      300K users

Har bir server 300-400K foydalanuvchiga xizmat → barchasi yaxshi ishlaydi

Load Balancing algoritmlari

1. Round Robin

Navbat bilan serverga yuborish:

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1 (qaytadan)

Afzalliklari:

Juda oddiy
Teng taqsimlash

Kamchiliklari:

Serverlar har xil bo’lsa mos emas
Requestlar har xil og’irlikda bo’lsa mos emas

2. Weighted Round Robin

Kuchli serverga ko’proq trafik:

Server 1 (8 CPU):  40% trafik
Server 2 (4 CPU):  20% trafik
Server 3 (8 CPU):  40% trafik

Qachon: Serverlar turli konfiguratsiyada

3. Least Connections

Eng kam ulanishli serverga yuborish:

Server 1: 100 connections
Server 2: 50 connections  ← Bu yerga yuboradi
Server 3: 80 connections

Afzalliklari:

Yuklama real-time balanslanadi
Long-running requestlar uchun yaxshi

Qachon: WebSocket, streaming, file uploads

4. Least Response Time

Eng tez javob bergan serverga yuborish:

Server 1: 100ms avg
Server 2: 50ms avg   ← Bu yerga yuboradi
Server 3: 150ms avg

Afzalliklari:

Eng yaxshi performance
Sekin serverlardan qochish

Kamchiliklari:

Murakkab implementation
Monitoring overhead

5. IP Hash

User IP asosida bitta serverga biriktirish:

hash(192.168.1.1) % 3 = 0 → Server 1
hash(192.168.1.2) % 3 = 1 → Server 2
hash(192.168.1.3) % 3 = 2 → Server 3

Afzalliklari:

Bir xil user har doim bir xil serverga
Session sticky (local cache ishlaydi)

Kamchiliklari:

Notekis taqsimlash mumkin
Server qo’shilsa hash o’zgaradi

Layer 4 vs Layer 7 Load Balancing

Layer 4 (Transport Layer)

IP va Port asosida routing:

Client → LB → Server
         │
         └─ IP: 192.168.1.1, Port: 443

Afzalliklari:

Juda tez (packet-level)
Kam resurs talab qiladi

Kamchiliklari:

Content-based routing yo’q
SSL termination qiyin

Ishlatiladi: TCP/UDP traffic, high performance kerak

Layer 7 (Application Layer)

HTTP content asosida routing:

example.com/api    → API Servers
example.com/static → Static File Servers
example.com/admin  → Admin Servers

Afzalliklari:

Content-based routing
SSL termination
Request modification
Advanced features (rate limiting, auth)

Kamchiliklari:

Sekinroq (parse HTTP)
Ko’proq resurs

Ishlatiladi: HTTP/HTTPS, microservices

Health Checks

Load balancer serverlar “tirik” yoki yo’qligini tekshiradi:

// Har 10 sekundda
GET /health → Server 1
  200 OK → Trafikni yuboradi

GET /health → Server 2
  Timeout → Trafikni yubormaydi

Health check endpoint:

// Express.js
app.get('/health', (req, res) => {
  // Database ulanish
  // Cache ulanish
  // Disk bo'sh joy
  if (allGood) {
    res.status(200).send('OK');
  } else {
    res.status(503).send('Unhealthy');
  }
});

Session Persistence (Sticky Sessions)

Muammo: User login qildi → Server 1 (session saqlandi) → Keyingi request → Server 2 (session yo’q!)

Yechim 1: Sticky Sessions

User ilk marta → Server 1
User keyingi safar → Server 1 (har doim)

Qanday:

Cookie bilan: lb-server=server1
IP hash bilan

Kamchiliklari:

Server o’lsa session yo’qoladi
Notekis taqsimlash

Yechim 2: Shared Session Store (Yaxshiroq!)

User → Server 1 → Redis (session)
User → Server 2 → Redis (bir xil session)

Stateless serverlar + centralized session = ideal.

High Availability

Load balancer o’zi single point of failure bo’lmaslik kerak:

Active-Passive

      ┌─────────────┐
      │ LB Primary  │ Active
      └─────────────┘
            │
      ┌─────────────┐
      │ LB Secondary│ 💤 Standby
      └─────────────┘

Primary ishlamasa → Secondary aktivlanadi (30-60 sekund)

Active-Active

      ┌─────────────┐
      │ LB Primary  │ 50% traffic
      └─────────────┘

      ┌─────────────┐
      │ LB Secondary│ 50% traffic
      └─────────────┘

Ikkalasi ham ishlaydi → 0 downtime

Load Balancer texnologiyalari

Hardware Load Balancers

F5 Networks, Citrix NetScaler
Juda tez va ishonchli
$$$ Qimmat (100K+ USD)

Software Load Balancers

Nginx, HAProxy
Bepul va flexible
Linux serverda ishlatish mumkin

Cloud Load Balancers

AWS ELB/ALB, Google Cloud Load Balancer
Fully managed
Auto-scaling
Pay-as-you-go

Nginx misoli

upstream backend {
    # Least connections algoritm
    least_conn;
    
    # Serverlar
    server server1.example.com weight=3;
    server server2.example.com weight=2;
    server server3.example.com weight=1;
    
    # Health check
    server server4.example.com max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    
    location / {
        proxy_pass http://backend;
        
        # Headers
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Global Load Balancing (DNS)

Foydalanuvchini eng yaqin data centerga yo’naltirish:

US user      → US data center
Europe user  → Europe data center
Asia user    → Asia data center

Qanday:

GeoDNS (cloudflare, Route53)
Latency-based routing
Health-based failover

Real-world misollar

Netflix

AWS ELB (Elastic Load Balancer)
Zuul API Gateway (application-level)
Global traffic management

Instagram

HAProxy frontend
Nginx backend
10K+ req/sec per load balancer

Facebook

Custom load balancer
Layer 4 va Layer 7 kombinatsiyasi
Millionlab concurrent connections

Best Practices

Health checks o’rnating — 10-30s interval
Monitoring qo’ying — latency, error rate, connections
Auto-scaling qiling — traffic spike’larga tayyor bo’ling
Multi-AZ deploy — single data center failure
Session external saqlang — Redis/Memcached
SSL termination — load balancerda qiling
Timeouts sozlang — hang qilgan requestlarni kesing

Xulosa

Load Balancer:

Trafikni taqsimlash
High availability
Scalability
Performance

Asosiy algoritmlar:

Round Robin → oddiy
Least Connections → long requests
IP Hash → session persistence

Layer:

Layer 4 → tez, oddiy
Layer 7 → content routing, advanced

Keyingi dars: Vertical vs Horizontal Scaling strategiyalari.