System Design

CAP teoremasi

CAP Theorem — distributed systemda uchtalasini birga olib bo’lmaydi:

Consistency (Izchillik)
Availability (Mavjudlik)
Partition Tolerance (Tarmoq ajralishi bardoshligi)

Faqat 2 tasini tanlashingiz mumkin.

CAP nima?

C - Consistency

Barcha node’lar bir xil ma’lumotni ko’radi:

Write → Node 1 (value = 100)
Read → Node 2 (value = 100)

Har qanday read eng oxirgi write’ni qaytaradi.

A - Availability

Har qaysi request javob oladi (hatto error bo’lmasa ham):

Request → Any node → Response 
(Hatto ba'zi node'lar down bo'lsa ham)

P - Partition Tolerance

Tarmoq ajralishi (network partition) bo’lsa ham ishlaydi:

Datacenter 1  ←  ✂️ ✂️  → Datacenter 2
(aloqa uzildi, lekin har biri ishlaydi)

Network partition inevitable — Internet’da har doim bo’lishi mumkin.

Nega uchtalasi birga emas?

Scenario: Network Partition

     Client
        ↓
   ┌────┴────┐
   ▼         ▼
┌──────┐  ┌──────┐
│Node 1│  │Node 2│
└──────┘  └──────┘
   ↕         ↕
   ✂️ Network partition!

Tanlov:

Option 1: CP (Consistency + Partition Tolerance)

Client → Node 1: UPDATE value = 100
Node 1 → Node 2: ✂️ (can't sync)
Node 1: "Error: Can't guarantee consistency" 

Availability qurbon qilindi

Option 2: AP (Availability + Partition Tolerance)

Client → Node 1: UPDATE value = 100 
Client → Node 2: READ value = 50 (eski qiymat) 

Consistency qurbon qilindi

Option 3: CA (Consistency + Availability)

Network partition bo'lmasligi kerak
→ Single datacenter, no distribution
→ Distributed system emas!

Real distributed systems: Partition tolerance shart (tarmoq har doim muammo bo’lishi mumkin).

Tanlov: CP yoki AP?

CP Systems (Consistency prioriteti)

Partition vaqtida: Availability qurbon qilinadi.

Network partition:
→ Write reject qilinadi
→ Read reject qilinadi (yoki eski data)
→ Consistency saqlanadi

CP Examples

1. MongoDB (default):

// Write concern: majority
db.users.insertOne(
  { name: 'Ali' },
  { writeConcern: { w: 'majority' } }
);

Majority node’lar sync bo’lmasa → Error

2. HBase:

Region Server down → Region unavailable
Consistent view muhim

3. Redis (with clustering):

Master down → Failover (10-30s unavailable)
Consistency > availability

4. Zookeeper:

Quorum yo'q → Service unavailable
Distributed coordination (consistency shart)

Qachon CP?

Financial systems: Pul yo’qolishi mumkin emas
Inventory management: Overselling muammo
Configuration management: Inconsistent config xavfli
Distributed locks: Coordination kerak

AP Systems (Availability prioriteti)

Partition vaqtida: Consistency qurbon qilinadi (eventual consistency).

Network partition:
→ Har ikkala side ham yoza/o'qiy oladi
→ Ma'lumot vaqtincha inconsistent
→ Keyinroq sync (eventual consistency)

AP Examples

1. Cassandra:

-- Write succeeds if ANY node responds
CONSISTENCY ANY;
INSERT INTO users VALUES (123, 'Ali');

Eventually replicate qilinadi.

2. DynamoDB:

// Eventual consistency (default)
const result = await dynamodb.get({
  TableName: 'Users',
  Key: { id: 123 },
  ConsistentRead: false // AP mode
});

3. CouchDB:

Multi-master, conflict resolution
Both nodes write → merge later

4. DNS:

DNS servers inconsistent bo'lishi mumkin
But always available

Qachon AP?

Social media: Tweet 1-2 sekund kech ko’rinsa muammo yo’q
Analytics: Approximate numbers OK
Caching: Stale data qabul qilinadi
Content delivery: Eventual consistency yetarli

PACELC Teoremasi

CAP kengaytmasi:

If Partition:
  Choose C or A
Else (no partition):
  Choose Latency or Consistency

Trade-off: Latency vs Consistency

Low latency:

Read from nearest replica (eventual consistency)
→ Fast but stale data possible

Strong consistency:

Read from master or quorum
→ Slow but always fresh

PACELC Examples

Cassandra:

Partition: AP (availability)
Else: EL (eventual consistency, low latency)

MongoDB:

Partition: CP (consistency)
Else: PC (strong consistency, higher latency)

Consistency Levels

Ko’p database’lar tunable consistency beradi:

Cassandra Consistency Levels

-- Strong consistency
CONSISTENCY QUORUM; -- N/2 + 1 nodes must respond

-- Eventual consistency
CONSISTENCY ONE; -- 1 node response enough

-- Any
CONSISTENCY ANY; -- Hinted handoff (fastest)

Trade-off: Consistency ↑ = Latency ↑

MongoDB Read Concern

// Strong consistency
db.collection.find().readConcern('majority');

// Eventual consistency
db.collection.find().readConcern('local');

DynamoDB Consistency

// Strong consistency
const result = await dynamodb.get({
  ConsistentRead: true // Wait for all replicas
});

// Eventual consistency (default)
const result = await dynamodb.get({
  ConsistentRead: false // Fastest replica
});

Real-world Architectures

Instagram (CP-leaning)

PostgreSQL: CP (transactions)
Cassandra: Tunable (eventual for feeds)
Redis: CP (session)

Feeds: AP (eventual OK)
Payments: CP (consistency must)

Netflix (AP)

Cassandra: AP (availability crucial)
EVCache: AP
Downtime > Stale data

"Show something > show nothing"

Google Spanner (CP with low latency)

TrueTime API: Synchronized clocks
Paxos: Consensus (CP)
But: Low latency (geographic replication)

Trade-off: Complexity + cost

Eventual Consistency in Practice

Time 0s:  Ali posts → Node 1
Time 0.1s: Node 1 → Node 2 (replicating)
Time 0.2s: Vali reads → Node 2 (eski, post yo'q) 
Time 0.5s: Replication done
Time 1s:  Vali reads → Node 2 (yangi, post bor)

Eventual consistency: 0.5-1 sekund.

Conflict Resolution

Example: Concurrent edits

User A: profile.bio = "Backend developer"
User B: profile.bio = "Frontend developer"
(same time, different nodes)

Strategies:

1. Last Write Wins (LWW):

Timestamp-based
Latest: profile.bio = "Frontend developer"

2. Version Vectors:

Track all writes, merge intelligently

3. CRDTs (Conflict-free Replicated Data Types):

Math-based merge

4. Application-level:

Flag conflict, let user resolve

Choosing CP vs AP

Decision Matrix

Use Case	Choice	Reason
Banking	CP	Money loss unacceptable
E-commerce inventory	CP	Overselling bad UX
Social feed	AP	Stale OK, availability crucial
Analytics	AP	Approximate OK
Configuration	CP	Inconsistent config dangerous
DNS	AP	Availability > consistency
Caching	AP	Stale acceptable

Hybrid Approach (Ko’p qo’llaniladi)

Real systems ikkalasini ishlatadi:

Critical data → CP database (PostgreSQL)
Non-critical → AP database (Cassandra)
Cache → AP (Redis eventual)

Example: E-commerce

Orders, Inventory → PostgreSQL (CP)
Product catalog → MongoDB (tunable)
Recommendations → Cassandra (AP)
Session → Redis (CP)
CDN → AP (eventual)

Xulosa

CAP Theorem:

Distributed systemda 3 tadan 2 tasini tanlash
Partition tolerance shart (tarmoq ishonchsiz)
Tanlov: CP yoki AP?

CP (Consistency + Partition):

Availability qurbon qilish
Financial, inventory, coordination
MongoDB, HBase, Zookeeper

AP (Availability + Partition):

Eventual consistency
Social media, analytics, cache
Cassandra, DynamoDB, CouchDB

Real-world:

Ko’pincha hybrid
Critical → CP
Non-critical → AP
Tunable consistency

Keyingi dars: Caching asoslari - tezlikni oshirish.