Barqarorlik va Masshtablanuvchanlik (Scalability & Reliability)

Endi arxitektor uchun juda katta mavzu:

Scalability & reliability - sistema ko‘p yuklamada ham ishlashi va nosozliklarda ham butunlay yiqilmasligi.

Bu mavzu quyidagilarni o‘z ichiga oladi: horizontal vs vertical scaling, stateless design, database sharding & partitioning, read replicas & CQRS at DB level, SLA/SLO/SLI definitions, chaos engineering.

1. Scalability nima?

Scalability - sistema yuklama oshganda o‘sishga qodir bo‘lishi.

Masalan:

Bugun: 1 000 user
3 oy keyin: 50 000 user
1 yil keyin: 1 000 000 user

Agar sistema ko‘proq user, request, data, transaction ko‘tara olsa - bu scalable system.

Oddiy misol

Sales Agent app backend bor:

Supervisor App
Sales Agent App
        |
    Backend API
        |
    PostgreSQL

Avval 50 agent ishlaydi. Keyin 5 000 agent ishlasa:

• login sekinlashmasligi kerak;

• order yuborish timeout bermasligi kerak;

• report ochilishi 30 sekund bo‘lmasligi kerak;

• database CPU 100% bo‘lib qolmasligi kerak.

Mana shu scalability masalasi.

2. Reliability nima?

Reliability - sistema nosozlik bo‘lsa ham kutilgan darajada ishlashda davom etishi.

Masalan:

• bitta server o‘chdi;

• database replica kechikdi;

• Kafka vaqtincha ishlamay qoldi;

• payment provider javob bermayapti;

• network sekinlashdi;

• bitta servis crash bo‘ldi.

Reliable system bunday holatlarda:

Butunlay yiqilmaydi
Xatoni izolyatsiya qiladi
Retry / fallback ishlatadi
Userga tushunarli javob qaytaradi
Data yo‘qotmaydi
Monitoring orqali tez aniqlanadi

3. Scalability va Reliability farqi

Yaxshi arxitektor ikkisini ham o‘ylaydi.

Scalable, lekin unreliable system:
Ko‘p request ko‘taradi, lekin bitta DB muammosida yiqiladi.

Reliable, lekin unscalable system:
Nosozlikka chidamli, lekin user ko‘payganda sekinlashadi.

4. Vertical Scaling

Vertical scaling nima?

Vertical scaling - bitta serverni kuchaytirish.

Masalan:

2 CPU / 4 GB RAM  →  8 CPU / 32 GB RAM

Yoki:

Kichik VPS → kuchli dedicated server

Afzalliklari

Kamchiliklari

Qachon vertical scaling yetadi?

Vertical scaling yaxshi:

• loyiha hali kichik bo‘lsa;

• traffic oldindan taxmin qilinsa;

• team kichik bo‘lsa;

• operational complexity oshirishni xohlamasangiz;

• tez yechim kerak bo‘lsa.

Arxitektor xulosasi:

Vertical scaling - yomon emas. Ko‘p bizneslar uchun uzoq vaqt yetarli bo‘ladi. Lekin u reliability muammosini to‘liq hal qilmaydi.

5. Horizontal Scaling

Horizontal scaling nima?

Horizontal scaling - bitta katta server o‘rniga bir nechta app instance ishlatish.

             Load Balancer
                  |
     ┌────────────┼────────────┐
     |            |            |
 App Instance  App Instance  App Instance
     |            |            |
     └────────────┼────────────┘
                  |
              Database

Masalan Spring Boot app’dan 3 ta instance:

sales-api-1
sales-api-2
sales-api-3

Requestlar Load Balancer orqali tarqatiladi.

Afzalliklari

Kamchiliklari

6. Stateless Design

Stateless nima?

Stateless application - app instance o‘z ichida user session yoki muhim holat saqlamaydi.

Yomon holat:

User login bo‘ldi → session sales-api-1 RAM ichida saqlandi
Keyingi request sales-api-2 ga tushdi → session topilmadi

Bu horizontal scalingda muammo.

To‘g‘ri holat

Session yoki state tashqi joyda bo‘ladi:

JWT token
Redis session store
Database
Object storage
Message broker

Shunda request qaysi instance’ga tushishi muhim emas.

User Request
    |
Load Balancer
    |
sales-api-1 yoki sales-api-2 yoki sales-api-3
    |
Shared Redis / DB / Token validation

Stateless design qoidalari

Java/Spring Boot misol

Yomon:

@Component
public class LoginSessionStore {
    private final Map<String, UserSession> sessions = new ConcurrentHashMap<>();
}

Bu bitta instance ichida ishlaydi. Lekin 3 instance bo‘lsa, muammo.

Yaxshi:

JWT access token
yoki
Spring Session + Redis

7. Database Bottleneck

Ko‘p systemlarda backend scale qilinadi, lekin database bitta qoladi.

App x10 scale qilindi
Database esa bitta

Natija:

Backend ko‘p request yuboradi
Database CPU 100%
Connection pool to‘ladi
Timeout boshlanadi

Shuning uchun arxitektor faqat application scaling emas, data scalingni ham o‘ylashi kerak.

8. Read Replicas

Read replica nima?

Read replica - asosiy database’dan nusxa olib, o‘qish uchun ishlatiladigan database.

              Write
App  ─────────────────→ Primary DB
                           |
                           | replication
                           ↓
                      Read Replica
                           ↑
              Read queries |

Yozish primary DB’ga ketadi. O‘qish replica’dan olinadi.

Qachon foydali?

Masalan:

• dashboard;

• report;

• product list;

• order history;

• search;

• analytics query.

Agar o‘qish yozishdan 10 baravar ko‘p bo‘lsa, read replica foydali bo‘ladi.

Kamchiligi

Eng katta muammo:

Replication lag

Ya’ni primary DB’dagi yangi data replica’ga biroz kechikib boradi.

Masalan:

User order yaratdi
Primary DB’da order bor
Replica hali yangilanmagan
User order history ochdi
Order ko‘rinmadi

Buni arxitektor hisobga olishi kerak.

Yechimlar

9. CQRS at DB Level

CQRS’ni oldingi mavzularda architecture pattern sifatida ko‘rdik. DB level’da esa bu shunday:

Write DB → normal relational model
Read DB  → query uchun optimallashtirilgan model

Masalan:

Order write model:
orders
order_items
payments
deliveries

Order read model:
order_summary_view

Read model frontend uchun tayyor bo‘ladi.

Misol

Mobile app order history ochadi:

{
  "orderId": 1001,
  "status": "PAID",
  "total": 250000,
  "agentName": "Ali",
  "customerName": "Do‘kon 24",
  "createdAt": "2026-05-20"
}

Agar buni har safar 6 ta JOIN bilan olsak, sekinlashishi mumkin.

CQRS read model:

order_history_view

Bu table/view oldindan tayyorlangan bo‘ladi.

Afzallik

Kamchiligi

10. Partitioning

Partitioning nima?

Partitioning - bitta katta table’ni ichki bo‘laklarga ajratish.

Masalan orders table’da 200 million row bor.

Uni vaqt bo‘yicha bo‘lish mumkin:

orders_2025
orders_2026_01
orders_2026_02
orders_2026_03

Yoki PostgreSQL declarative partitioning:

orders
 ├── orders_2026_01
 ├── orders_2026_02
 └── orders_2026_03

Application hali ham orders table bilan ishlagandek ko‘radi.

Qachon kerak?

Partitioning foydali:

• table juda katta bo‘lsa;

• query ko‘pincha sana bo‘yicha filtr qilsa;

• eski datani arxivlash kerak bo‘lsa;

• indexlar juda kattalashib ketgan bo‘lsa;

• delete/archive operatsiyalari og‘ir bo‘lsa.

Misol

Sales app’da agent visit logs bor:

agent_visits

Har kuni millionlab visit record tushsa, vaqt bo‘yicha partition qilish mumkin:

agent_visits_2026_01
agent_visits_2026_02
agent_visits_2026_03

Query:

SELECT *
FROM agent_visits
WHERE created_at >= '2026-05-01'
  AND created_at < '2026-06-01';

Database faqat kerakli partition’ni o‘qiydi.

11. Sharding

Sharding nima?

Sharding - data’ni bir nechta alohida database/serverlarga bo‘lish.

Partitioning bitta DB ichida bo‘lishi mumkin.
Sharding esa ko‘pincha bir nechta DB instance degani.

Shard 1 → users 1-100000
Shard 2 → users 100001-200000
Shard 3 → users 200001-300000

Yoki tenant bo‘yicha:

Shard A → company_1, company_2
Shard B → company_3, company_4
Shard C → company_5, company_6

Qachon kerak?

Sharding kerak bo‘lishi mumkin:

• bitta database hajm yoki trafficni ko‘tara olmasa;

• multi-tenant SaaS juda kattalashsa;

• data isolation kerak bo‘lsa;

• region bo‘yicha data ajratish kerak bo‘lsa;

• write traffic juda yuqori bo‘lsa.

Sharding kamchiliklari

Sharding juda qimmat architecture qaror.

Arxitektor xulosasi

Sharding - oxirgi bosqichdagi scaling vositasi. Avval indexing, query optimization, caching, read replicas, partitioning ko‘rib chiqiladi.

12. SLA, SLO, SLI

Reliability’ni gapirganda aniq raqam kerak. "Tez ishlasin", "kam yiqilsin" - bu yetarli emas.

SLI - Service Level Indicator

SLI - o‘lchanadigan metrika.

Masalan:

API latency
Error rate
Availability
Successful request ratio
Payment success rate
Queue processing delay

Misollar:

p95 latency = 250ms
error rate = 0.2%
availability = 99.9%

SLO - Service Level Objective

SLO - maqsad.

Masalan:

95% API requests must complete under 300ms.
Monthly availability must be 99.9%.
Payment success rate must be 99.5%.

Ya’ni SLO - biz erishmoqchi bo‘lgan reliability target.

SLA - Service Level Agreement

SLA - mijoz bilan shartnoma darajasidagi majburiyat.

Masalan:

Agar availability 99.5% dan past bo‘lsa,
mijozga compensation beriladi.

SLA odatda biznes/legal hujjat.

Farqi

Misol

SLI:
p95 latency, error rate, uptime

SLO:
p95 latency < 300ms for 99% of requests
monthly uptime >= 99.9%

SLA:
if uptime < 99.5%, customer gets service credit

13. Availability: 99%, 99.9%, 99.99%

Availability raqamining ma’nosi bor.

Farq juda katta.

99.99% deyish oson, lekin unga erishish qimmat:

• multi-instance;

• auto healing;

• failover;

• backup;

• observability;

• on-call;

• incident response;

• redundancy;

• chaos testing.

14. Error Budget

Error budget nima?

Agar SLO 99.9% bo‘lsa, demak 0.1% xatoga ruxsat bor.

100% - 99.9% = 0.1% error budget

Bu system qanchalik "xato qilishga haqqi bor" degani.

Nega kerak?

Agar team error budgetni tugatgan bo‘lsa:

Yangi feature chiqarishni kamaytirish
Reliability muammolarini tuzatish
Performance va stabilityga fokus qilish

Agar error budget yaxshi bo‘lsa:

Yangi feature va experimentlarga ko‘proq joy bor

Arxitektor product va engineering orasida shu balansni tushuntiradi.

15. Reliability patterns

1. Timeout

External service chaqirilganda cheksiz kutish mumkin emas.

Yomon:

Payment provider javob bermayapti
Order service 60 sekund osilib qoldi
Threadlar tugadi
Butun app sekinlashdi

Yaxshi:

Payment timeout = 3 sekund
Timeout bo‘lsa FAILED/PENDING holat
Keyin retry yoki manual check

2. Retry

Vaqtinchalik xatolarda retry foydali.

Lekin noto‘g‘ri retry xavfli.

Yomon:

1000 request xato oldi
Har biri 5 marta retry qildi
Service yanada ko‘proq bosim ostida qoldi

Yaxshi:

Retry with exponential backoff
Retry limit
Jitter
Idempotency key

3. Circuit Breaker

Agar external service doim xato bersa, uni vaqtincha chaqirmaslik kerak.

Order Service → Payment Service

Payment Service yiqilgan bo‘lsa:

Circuit open
Order Service darhol fallback qaytaradi
Threadlarni band qilmaydi

Java’da ko‘pincha:

Resilience4j

ishlatiladi.

4. Bulkhead

Bulkhead - resurslarni izolyatsiya qilish.

Masalan:

Payment calls uchun alohida thread pool
Notification calls uchun alohida thread pool
Report generation uchun alohida pool

Agar report sekinlashsa, paymentni o‘ldirmaydi.

5. Rate Limiting

Rate limiting - juda ko‘p request kelganda chegaralash.

Masalan:

Har user uchun 100 request/minute
Har IP uchun 1000 request/hour

Bu systemni himoya qiladi:

• abuse;

• bot;

• accidental traffic spike;

• DDoS’ning kichik ko‘rinishlari;

• expensive endpointlarni haddan tashqari ishlatish.

6. Graceful Degradation

System hammasini bajara olmasa ham, eng muhim qismini ishlatadi.

Masalan:

Recommendation service ishlamayapti
Lekin product list ochiladi
Faqat recommendation block yashiriladi

Yoki:

Report service sekin
Lekin order yaratish ishlayveradi

16. Chaos Engineering

Chaos engineering nima?

Chaos engineering - systemni ataylab boshqarilgan nosozliklarga duchor qilib, uning chidamliligini tekshirish.

Savol:

"Agar production’da bu buzilsa nima bo‘ladi?"

Buni production kutib o‘tirmasdan, nazoratli test qilinadi.

Misollar

Bitta app instance o‘chirib qo‘yiladi
Database replica kechiktiriladi
Network latency qo‘shiladi
Kafka broker o‘chiriladi
Payment API timeout qiladi
Disk to‘lib qoladi
CPU 100% bo‘ladi

Maqsad - system qanday javob berishini ko‘rish.

Chaos Monkey

Chaos Monkey - Netflix tomonidan mashhur qilingan yondashuv: production muhitida instance’larni tasodifiy o‘chirib, system resilience’ni tekshirish.

Lekin buni hamma projectga darrov qo‘llash kerak emas.

Chaos engineering qachon kerak?

Kerak:

• katta distributed system;

• yuqori availability talabi;

• microservices ko‘p;

• failover bor, lekin sinovdan o‘tmagan;

• incidentlar qimmatga tushadi.

Kerak emas yoki ehtiyotkorlik bilan:

• kichik loyiha;

• monitoring yo‘q;

• rollback yo‘q;

• on-call yo‘q;

• backup tekshirilmagan;

• team tayyor emas.

17. Scalability checklist

Arxitektor sifatida scaling haqida o‘ylaganda quyidagilar tekshiriladi:

Application statelessmi?
Load balancer bormi?
Health check bormi?
Database connection pool to‘g‘ri sozlanganmi?
Slow querylar bormi?
Indexlar to‘g‘rimi?
Cache kerakmi?
Read/write ratio qanday?
Read replica kerakmi?
Queue kerakmi?
Background joblar duplicate ishlamayaptimi?
Rate limiting bormi?
Monitoring bormi?

18. Reliability checklist

Reliability uchun:

Timeoutlar belgilanganmi?
Retry policy bormi?
Retry idempotentmi?
Circuit breaker kerakmi?
Fallback bormi?
DLQ bormi?
Backup bor va restore test qilinganmi?
Alertlar bor?
Error rate kuzatiladimi?
p95/p99 latency kuzatiladimi?
Incident response jarayoni bormi?
Single point of failure qayerda?

19. Real loyiha misoli: Sales Agent backend

Tasavvur qilamiz:

2 Android app:
- Supervisor
- Sales Agent

Backend:
- auth
- agents
- customers
- visits
- orders
- reports
- notifications

Boshlang‘ich architecture

Android Apps
    |
Nginx / Load Balancer
    |
Spring Boot Modular Monolith
    |
PostgreSQL
    |
Redis

1-bosqich: oddiy, lekin sog‘lom

1 app instance
1 PostgreSQL
Redis cache/session
Basic monitoring
Daily backup

Bu MVP uchun yetadi.

2-bosqich: horizontal scaling

Load Balancer
   |
 ┌──────────────┬──────────────┐
 API instance 1 API instance 2
   |
 PostgreSQL + Redis

Talab:

• app stateless;

• JWT yoki Redis session;

• file upload local diskka emas, object storage’ga;

• scheduled job faqat bitta instance’da ishlashi;

• idempotency key.

3-bosqich: read scaling

Agar reportlar DB’ni qiynasa:

Primary PostgreSQL → write
Read Replica       → reports/read-heavy queries

Yoki:

orders → write model
order_report_summary → read model

4-bosqich: async processing

Notification, report export, heavy tasks:

Order Created
     |
 RabbitMQ/Kafka
     |
Notification Worker
Report Worker

Order yaratish notification yuborilishini kutmaydi.

5-bosqich: reliability

Qo‘shiladi:

Timeout
Retry with backoff
Circuit breaker
DLQ
Health checks
Alerting
Backup restore test
Rate limiting

20. Katta xatolar

1. Scalingni faqat server kuchaytirish deb o‘ylash

Serverni kuchaytirish vaqtinchalik yordam beradi. Lekin bottleneck query, lock, connection pool yoki architecture’da bo‘lishi mumkin.

2. Stateless qilmasdan horizontal scale qilish

Agar session local RAM’da bo‘lsa, 3 ta instance muammo chiqaradi.

3. Retry’ni noto‘g‘ri ishlatish

Retry noto‘g‘ri sozlansa, yiqilayotgan serviceni butunlay ezib tashlaydi.

4. Replica lagni unutish

Read replica ishlatilsa, data kechikishi bor. User yangi yaratgan orderini ko‘rmasligi mumkin.

5. SLA’ni texnik imkoniyatsiz va’da qilish

99.99% availability uchun infrastructure, monitoring, process, odam va pul kerak.

6. Shardingni juda erta qilish

Sharding ko‘p muammoga sabab bo‘ladi. Juda katta scale bo‘lmaguncha undan qochgan yaxshi.

21. Arxitektor uchun qaror tartibi

Scaling muammo chiqsa, tartib bilan tekshirish kerak:

1. Metrics borligini tekshir
2. Bottleneckni top
3. Query/index optimization qil
4. Cache qo‘sh
5. Connection pool sozla
6. App instance ko‘paytir
7. Read replica qo‘sh
8. Partitioning qil
9. Async queue qo‘sh
10. Oxirida sharding/microservices ko‘rib chiq

Ya’ni darrov:

"Microservices qilamiz"

deyish arxitektor yondashuvi emas.

22. Yakuniy formula

Scalability = traffic oshganda o‘sish qobiliyati
Reliability = nosozlik bo‘lsa ham ishlash qobiliyati

Architectning asosiy vazifasi:

Qayerda bottleneck chiqishini oldindan ko‘rish
Single point of failurelarni kamaytirish
Systemni stateless va observable qilish
SLO/SLI bilan aniq o‘lchash
Keraksiz complexity qo‘shmaslik

Eng muhim xulosa

Scalable system ko‘p request ko‘taradi. Reliable system muammo bo‘lganda ham yashaydi. Yaxshi architecture ikkalasini balans qiladi.

Java/Spring Boot loyihalar uchun amaliy start:

Modular Monolith
+ Stateless API
+ PostgreSQL
+ Redis
+ Load Balancer
+ Metrics/Logs/Tracing
+ Timeout/Retry/Circuit Breaker
+ Read Replica kerak bo‘lganda
+ Sharding faqat juda katta scale’da