Kinh nghiệm Thiết kế Hệ thống Backend: Từ Lý Thuyết Đến Thực Chiến Phỏng Vấn

System Design (Thiết kế hệ thống) là vòng phỏng vấn mang tính quyết định đối với các kỹ sư Backend từ cấp độ Mid-level trở lên. Không có một đáp án duy nhất cho các bài toán thiết kế, nhà tuyển dụng đánh giá bạn dựa trên tư duy đánh đổi (trade-offs), khả năng phân tích yêu cầu và cách bạn giải quyết các điểm nghẽn (bottlenecks) khi hệ thống tăng trưởng.

1. Phân Tích Yêu Cầu và Ước Tính Tài Nguyên (Capacity Estimation)

Mỗi buổi phỏng vấn System Design luôn bắt đầu bằng các yêu cầu mơ hồ từ người phỏng vấn. Nhiệm vụ của bạn là làm rõ yêu cầu chức năng (Functional Requirements) và phi chức năng (Non-Functional Requirements).

Yêu cầu chức năng và phi chức năng

• Chức năng: Hệ thống làm gì? (Ví dụ: Rút gọn URL, đăng tải và xem video, đặt phòng khách sạn).
• Phi chức năng: Độ trễ (Latency) thấp, tính sẵn sàng cao (High Availability), khả năng mở rộng (Scalability), và tính nhất quán dữ liệu (Consistency).

Ước tính tải (Back-of-the-envelope estimation)

Bạn cần nắm vững cách quy đổi các con số cơ bản để ước tính băng thông, dung lượng lưu trữ và số lượng request mỗi giây (QPS). Ví dụ với hệ thống có 100 triệu người dùng hoạt động hàng ngày (DAU) và mỗi người dùng tạo ra 5 request đọc mỗi ngày:

QPS Trung bình = (100,000,000 * 5) / 86400 giây ≈ 5,787 request/giây. Đỉnh điểm (Peak QPS) thường gấp 2 đến 3 lần trung bình, tức là khoảng 15,000 QPS.

2. Kiến Trúc Cốt Lõi và Các Mẫu Thiết Kế (Design Patterns)

Khi đã có ước tính tải, bạn cần xây dựng kiến trúc tổng quan. Hầu hết các hệ thống hiện đại đều chuyển dịch từ Monolith sang Microservices hoặc sử dụng kiến trúc phân tầng (Layered Architecture).

Cân Bằng Tải (Load Balancing)

Load Balancer (LB) là thành phần đứng trước các service để phân phối traffic. Các thuật toán phổ biến bao gồm Round Robin, Least Connections, và Consistent Hashing (rất hữu ích khi thiết kế hệ thống Caching phân tán).

Caching Chiến Lược

Caching giúp giảm tải trực tiếp cho cơ sở dữ liệu quan hệ. Các mô hình caching phổ biến:

• Cache-Aside: Ứng dụng kiểm tra cache trước, nếu không có (cache miss) thì đọc từ DB rồi ghi ngược lại cache.
• Write-Through: Dữ liệu được ghi vào cache và DB cùng một lúc.
• Write-Behind (Write-Back): Ghi vào cache trước, sau đó bất đồng bộ ghi xuống DB. Tối ưu hiệu năng ghi nhưng rủi ro mất dữ liệu nếu cache sập.

3. Cơ Sở Dữ Liệu: SQL vs NoSQL và Chiến Lược Phân Mảnh

Việc lựa chọn sai cơ sở dữ liệu là lỗi phổ biến nhất trong phỏng vấn System Design.

Sharding và Partitioning

Khi dữ liệu vượt quá dung lượng của một máy chủ cơ sở dữ liệu, bạn cần phân mảnh dữ liệu. Các chiến lược sharding gồm:

• Range Based: Dựa theo khoảng giá trị (ví dụ: ID từ 1-1000 nằm ở DB 1). Dễ dẫn đến lệch tải (hotspot).
• List Based: Phân chia theo danh mục cố định (ví dụ: khu vực địa lý).
• Hash Based: Dùng hàm băm trên khóa chính để quyết định shard. Giúp phân phối đều dữ liệu nhưng khó scale khi thêm shard mới nếu không dùng Consistent Hashing.

4. Best Practices và Các Lỗi Thường Gặp

Để ghi điểm với người phỏng vấn, hãy luôn ghi nhớ các nguyên tắc thực chiến sau:

• Đừng vội chọn Microservices: Luôn bắt đầu bằng thiết kế hướng Modular Monolith trừ khi bài toán yêu cầu rõ ràng về việc tách đội ngũ hoặc scale độc lập các thành phần.
• Xử lý điểm đơn (Single Point of Failure - SPOF): Luôn có phương án dự phòng (Redundancy) cho Load Balancer, Database và Message Queue.
• Bất đồng bộ (Asynchronous Processing): Sử dụng Message Queue (Kafka, RabbitMQ) cho các tác vụ nặng không cần trả kết quả ngay lập tức (như gửi email, xử lý video).

5. Checklist Phỏng Vấn System Design

Trước khi kết thúc phần thiết kế, hãy tự kiểm tra lại hệ thống của bạn qua các điểm sau:

1. Đã làm rõ yêu cầu chức năng và giới hạn hệ thống chưa?
2. Đã tính toán được QPS và dung lượng lưu trữ chưa?
3. Đã giải quyết bài toán SPOF cho các tầng quan trọng chưa?
4. Đã có giải pháp Rate Limiting để chống tấn công DDoS hoặc spam chưa?
5. Đã đề xuất giải pháp giám sát (Monitoring) và Logging chưa?

6. Câu Hỏi Thường Gặp (FAQ)

Làm sao để chọn giữa Redis và Memcached?

Redis hỗ trợ cấu trúc dữ liệu phức tạp (Sorted Sets, Hashes), hỗ trợ persistence (lưu dữ liệu xuống đĩa) và Replication. Memcached đơn giản hơn, là thuần túy Key-Value lưu trên RAM, tối ưu cho đa luồng (multi-threaded). Trong phần lớn trường hợp hiện đại, Redis là lựa chọn mặc định.

Khi nào nên dùng gRPC thay vì REST API?

gRPC sử dụng HTTP/2 và Protocol Buffers (binary), giúp nén dữ liệu nhỏ hơn và truyền tải nhanh hơn REST/JSON đáng kể. Nó phù hợp cho giao tiếp nội bộ giữa các Microservices (Internal Communication). REST/JSON vẫn phù hợp hơn cho Public API phục vụ client web/mobile.