- vừa được xem lúc

8 vấn đề phổ biến trong System Design và cách giải quyết (dành cho Developer)

0 0 1

Người đăng: Phan Ngoc

Theo Viblo Asia

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.

image.png


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 WriteLSM-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 StorageObject 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

Bình luận

Bài viết tương tự

- vừa được xem lúc

[Bài dịch] - Thiết Kế Hệ Thống Cho Hàng Triệu Người Dùng

Thiết kế hệ thống hỗ trợ hàng triệu người dùng là một thử thách không nhỏ, nó đòi hỏi sự cải tiến liên tục và không ngừng. Ở bài viết, chúng ta sẽ xây dựng một hệ thống hỗ trợ một người dùng và dần dầ

0 0 50

- vừa được xem lúc

[System design] - Redis vs Kafka vs RabbitMQ

Khi sử dụng giao tiếp không đồng bộ trong hệ thống microservice, phổ biến nhất đó là chúng ta sẽ sử dụng một message broker. Message broker đảm bảo giao tiếp giữa các microservice một cách đáng tin cậ

0 0 60

- vừa được xem lúc

Nx Workspace - Anh Cả trong việc xây dựng frontend architecture

Chào anh em bạn hữu gần xa. Rãnh rỗi quá không biết làm gì nên chia sẻ cho anh em xíu về System Design.

0 0 105

- vừa được xem lúc

Các Thuật Toán Thường Dùng Cho Bộ Giới Hạn Truy Cập

Trong bất kỳ hệ thống nào thì một bộ giới hạn truy cập cũng là một yêu cầu cần thiết đế đáp ứng các yêu cầu về bảo mật cũng như tính an toàn hệ thống. .

0 0 30

- vừa được xem lúc

[System design] - Redis High Availibility với Sentinel và Replication

Bối cảnh. Bạn dùng redis để đệm dữ liệu cho 1 ứng dụng chat.

0 0 39

- vừa được xem lúc

[System design] - Keepalived High Availability

Đối với những mô hình dịch vụ cần đảm bảo tính sẵn sàng cao (High Availability – HA), thì việc hệ thống bị down là không thể chấp nhận được. Hiện có rất nhiều phần mềm, giải pháp để đảm bảo tính HA ch

0 0 43