Trong bài này, bạn sẽ học:

• Các vấn đề phổ biến khi xây dựng hệ thống lớn.
• Giải pháp cụ thể cho từng vấn đề.
• Use case thực tế giúp bạn hiểu và áp dụng.

---

1️⃣ Dùng Caching để tăng tốc độ đọc (Read-heavy)

Vấn đề: Nếu hệ thống có lượng đọc cao (ví dụ: website thương mại điện tử), truy vấn DB liên tục gây quá tải, tăng latency.

Giải pháp: Dùng cache (Redis, Memcached) lưu các dữ liệu truy vấn phổ biến. Khi người dùng yêu cầu:

• Nếu cache có ⇒ trả kết quả ngay (nhanh).
• Nếu cache không có ⇒ đọc DB, đồng thời lưu vào cache cho lần sau.

Use case thực tế: Website bán hàng (Shopee, Tiki):

• Sản phẩm bán chạy (iPhone 15) có hàng triệu lượt xem/ngày.
• Thay vì query database SELECT * FROM products WHERE id=15 mỗi lần, cache chi tiết sản phẩm vào Redis.

Code sample (Python + Redis)

# Redis cache example
import redis
db = redis.Redis()

product_id = "15"
cached = db.get(product_id)

if cached:
    print("Cache hit:", cached)
else:
    result = query_product_from_db(product_id)
    db.set(product_id, result, ex=3600)  # Cache for 1 hour

---

2️⃣ Dùng Async Write và LSM-Tree DB cho High-write traffic

Vấn đề: App có lưu lượng ghi cao (ví dụ: app chat, mạng xã hội). Database bị nghẽn do phải ghi đồng bộ.

Giải pháp:

• Xử lý ghi bất đồng bộ (queue worker như Kafka, RabbitMQ).
• Dùng database tối ưu ghi như LSM Tree DB (Cassandra, RocksDB).

Use case thực tế: App chat (Zalo, Telegram): mỗi giây hàng ngàn tin nhắn.

• Tin nhắn đẩy vào queue.
• Worker ghi batch vào DB.

---

3️⃣ Redundancy và Failover (Tính sẵn sàng cao)

Vấn đề: Hệ thống chỉ có 1 server (Single Point of Failure). Server die = mất dịch vụ.

Giải pháp: Triển khai replication + failover.

• Master ↔ Replica
• Khi master die, failover tự động chuyển sang replica.

Use case thực tế: Website ngân hàng (MB Bank, Vietcombank):

• Database master-replica.
• Khi primary die, app chuyển qua replica, tránh downtime.

---

4️⃣ Dùng Load Balancer để phân phối tải

Vấn đề: Khi traffic cao (ví dụ Black Friday), 1 server chịu không nổi.

Giải pháp: Dùng Load Balancer (Nginx, AWS ALB):

• Phân phối request qua nhiều server.
• Nếu 1 server die, request tự chuyển server khác.

Use case thực tế: Trang web Tiki vào 11/11:

• Có thể scale lên 10 app server.
• Load balancer phân phối đều.

---

5️⃣ Dùng CDN để giảm latency

Vấn đề: Người dùng ở xa server chính ⇒ load image/video chậm.

Giải pháp: Dùng CDN (Cloudflare, AWS CloudFront):

• Lưu trữ file tĩnh gần người dùng.
• Giảm latency, giảm tải server chính.

Use case thực tế: Web tin tức VnExpress có người dùng toàn cầu.

• CDN cache ảnh, video gần US, EU, Asia.

---

6️⃣ Dùng Block Storage và Object Storage cho file lớn

Vấn đề: Lưu file lớn (video, hình ảnh, PDF) trên database làm DB nặng.

Giải pháp:

• Dùng Block Storage (EBS).
• Dùng Object Storage (S3).

Use case thực tế: App học online (Khan Academy):

• Video bài giảng lưu trên AWS S3.
• Metadata (title, description) lưu DB.

---

7️⃣ Dùng Centralized Logging (Log tập trung)

Vấn đề: Nhiều server, khó tìm log lỗi.

Giải pháp: Dùng bộ ELK (Elasticsearch, Logstash, Kibana):

• Tập trung log từ nhiều server.
• Có dashboard dễ tìm kiếm lỗi.

Use case thực tế: Hệ thống microservice (ShopeePay):

• Mỗi service push log vào ELK stack.
• DevOps search log dễ dàng.

---

8️⃣ Dùng Sharding + Index để tăng tốc query

Vấn đề: Database lớn (hàng tỷ bản ghi) ⇒ query chậm.

Giải pháp:

• Tạo Index cho trường hay query.
• Dùng Sharding chia DB ra nhiều node.

Use case thực tế: Hệ thống phân tích click (Google Analytics clone):

• Dữ liệu click của từng website shard theo website_id.
• Index trường timestamp, user_id.

SQL Index Example

CREATE INDEX idx_user_timestamp
ON clicks (user_id, timestamp);

---

Tổng kết

Vấn đề	Giải pháp
Đọc nhiều	Cache
Ghi nhiều	Async Write + LSM-Tree
Server die	Replication + Failover
Quá tải server	Load Balancer
Người dùng xa	CDN
File lớn	Object Storage
Nhiều log	ELK
DB chậm	Index + Sharding

---