Phỏng vấn System Design Backend là một trong những vòng thi 'khó nhằn' nhất đối với kỹ sư phần mềm. Nó không chỉ kiểm tra kiến thức về kiến trúc hệ thống, mà còn đánh giá tư duy giải quyết vấn đề, khả năng giao tiếp và cách bạn đưa ra các quyết định trade-off trong thực tế. Là một người đã từng ở cả hai phía - phỏng vấn viên và ứng viên - tôi hiểu rõ những áp lực và mong đợi trong vòng này. Dưới đây là 10 câu hỏi System Design Backend thường gặp nhất, cùng với những gợi ý thực chiến để bạn có thể tự tin vượt qua.
I. Các Câu Hỏi System Design Backend Thường Gặp Nhất
1. Thiết kế một hệ thống URL Shortener (như Bitly)
Đây là câu hỏi kinh điển. Nhà tuyển dụng muốn xem bạn hiểu về cách tạo và quản lý các short URL, khả năng mở rộng hệ thống và xử lý lượng truy cập lớn.
- Yêu cầu cơ bản: Tạo URL ngắn từ URL dài, chuyển hướng URL ngắn về URL dài gốc.
- Các điểm cần thảo luận:
- Schema Database: Cách lưu trữ URL dài, URL ngắn, số lượt truy cập. Dùng SQL hay NoSQL?
- Thuật toán tạo Short URL: Base62 encoding (mã hóa ID tăng dần), hashing (MD5/SHA1) rồi xử lý xung đột (collision).
- Xử lý xung đột: Nếu dùng hashing, làm thế nào khi hai URL dài khác nhau lại cho ra cùng một short URL? (Thêm salt, thử lại).
- Độ bền và khả năng mở rộng: Làm sao để hệ thống có thể chịu được hàng triệu request/giây? Sử dụng caching (Redis), load balancer, sharding database.
- API Design: Các API để tạo và truy xuất URL.
- Metrics: Đếm số lượt truy cập.
2. Thiết kế một hệ thống Chat (như WhatsApp/Messenger)
Đây là một câu hỏi phức tạp, kiểm tra kiến thức của bạn về giao tiếp real-time, hàng đợi tin nhắn, và khả năng mở rộng cho hàng tỷ người dùng.
- Yêu cầu cơ bản: Gửi/nhận tin nhắn 1-1, tin nhắn nhóm, trạng thái online/offline, thông báo.
- Các điểm cần thảo luận:
- Giao thức: WebSocket cho kết nối real-time, hoặc HTTP Long Polling/SSE.
- Kiến trúc: Message Queues (Kafka, RabbitMQ) để đảm bảo tin nhắn được gửi đi, dịch vụ Presence để quản lý trạng thái online/offline.
- Lưu trữ tin nhắn: NoSQL database (Cassandra, MongoDB) cho khả năng ghi/đọc cao, lưu trữ lịch sử tin nhắn.
- Push Notifications: Cách gửi thông báo đến người dùng offline.
- Đảm bảo tin nhắn: Xử lý mất gói tin, thứ tự tin nhắn, trạng thái đọc/gửi.
- Scale: Phân vùng dữ liệu (sharding), load balancing các server chat.
3. Thiết kế một hệ thống News Feed (như Facebook/Twitter)
Câu hỏi này tập trung vào việc quản lý lượng dữ liệu khổng lồ và phân phối nội dung đến hàng triệu người dùng một cách hiệu quả, đặc biệt là chiến lược fan-out.
- Yêu cầu cơ bản: Hiển thị bài đăng từ những người dùng theo dõi, sắp xếp theo thời gian hoặc mức độ liên quan.
- Các điểm cần thảo luận:
- Fan-out on write (push model): Khi người dùng đăng bài, đẩy bài đó vào feed của tất cả người theo dõi. Ưu điểm là đọc nhanh, nhược điểm là ghi chậm cho người nổi tiếng.
- Fan-out on read (pull model): Khi người dùng yêu cầu feed, tổng hợp các bài đăng từ những người họ theo dõi. Ưu điểm là ghi nhanh, nhược điểm là đọc chậm, cần caching mạnh.
- Hybrid approach: Kết hợp cả hai.
- Caching: Redis để lưu trữ feed đã tạo sẵn, thông tin người dùng.
- Data Storage: Database cho bài đăng và mối quan hệ theo dõi.
- Latency: Cách giảm độ trễ khi tạo và hiển thị feed.
4. Thiết kế một hệ thống Distributed Cache (như Memcached/Redis)
Câu hỏi này kiểm tra sự hiểu biết về cách cải thiện hiệu suất hệ thống thông qua caching, và làm thế nào để quản lý cache trong một môi trường phân tán.
- Yêu cầu cơ bản: Lưu trữ dữ liệu tạm thời để tăng tốc độ truy cập, giảm tải cho database.
- Các điểm cần thảo luận:
- Cơ chế phân phối: Hashing, Consistent Hashing để phân phối dữ liệu lên các node cache.
- Chính sách eviction: LRU (Least Recently Used), LFU (Least Frequently Used), FIFO, Random.
- Replication: Để đảm bảo tính sẵn sàng và độ bền khi một node cache gặp sự cố.
- Cache invalidation: Cách cập nhật hoặc xóa dữ liệu trong cache khi dữ liệu gốc thay đổi.
- Cache hit/miss ratio: Metrics quan trọng.
5. Thiết kế một hệ thống Rate Limiter
Đây là một hệ thống quan trọng để bảo vệ API và tài nguyên khỏi lạm dụng, tấn công DDoS, hoặc đảm bảo công bằng giữa các người dùng.
- Yêu cầu cơ bản: Giới hạn số lượng yêu cầu mà một người dùng/IP/client có thể gửi trong một khoảng thời gian nhất định.
- Các điểm cần thảo luận:
- Thuật toán: Leaky Bucket, Token Bucket, Fixed Window Counter, Sliding Window Log/Counter. Nêu ưu nhược điểm của từng loại.
- Vị trí đặt: Gateway level, service level.
- Phân tán: Làm sao để rate limiter hoạt động chính xác trong môi trường nhiều server? Dùng Redis để lưu trữ counters dùng chung.
- Xử lý vượt ngưỡng: Trả về lỗi 429 Too Many Requests, thêm header Retry-After.
6. Thiết kế một hệ thống Đánh giá/Review sản phẩm
Nghe có vẻ đơn giản, nhưng hệ thống review ẩn chứa nhiều thách thức về chống spam, gian lận, và tính toán điểm trung bình.
- Yêu cầu cơ bản: Người dùng có thể viết review và cho điểm sản phẩm, hiển thị review và điểm trung bình.
- Các điểm cần thảo luận:
- Data Model: Lưu trữ review (người dùng, sản phẩm, điểm, nội dung, thời gian).
- Chống spam/gian lận: Giới hạn số review/người dùng/sản phẩm, kiểm duyệt thủ công/tự động (AI/ML), phát hiện hành vi bất thường.
- Tính toán điểm trung bình: Tính toán bất đồng bộ (cron job, message queue) để tránh ảnh hưởng đến hiệu năng khi có nhiều review.
- Hiển thị: Phân trang, bộ lọc (theo điểm, thời gian), sắp xếp.
- Scaling: Cần xử lý lượng lớn review cho các sản phẩm phổ biến.
7. Thiết kế một hệ thống Notification Service (SMS, Email, Push)
Hệ thống thông báo là xương sống của mọi ứng dụng hiện đại, đòi hỏi khả năng gửi tin cậy và mở rộng cho nhiều kênh khác nhau.
- Yêu cầu cơ bản: Gửi thông báo qua nhiều kênh (SMS, email, push notification), xử lý bất đồng bộ.
- Các điểm cần thảo luận:
- Message Queue: Kafka hoặc RabbitMQ để xử lý bất đồng bộ, đệm các yêu cầu gửi thông báo.
- Các kênh: Module riêng cho từng loại (SMS Gateway, SMTP server cho email, FCM/APNs cho push).
- Templates: Quản lý các mẫu thông báo động.
- Retry Mechanism: Cách xử lý khi gửi thất bại.
- Logging & Monitoring: Theo dõi trạng thái gửi, debug lỗi.
- Opt-out: Cho phép người dùng dừng nhận thông báo.
8. Thiết kế một hệ thống Recommendation Engine
Câu hỏi này đi sâu vào cách thu thập, xử lý dữ liệu và sử dụng các thuật toán cơ bản để gợi ý sản phẩm/nội dung cho người dùng.
- Yêu cầu cơ bản: Gợi ý sản phẩm/nội dung liên quan cho người dùng.
- Các điểm cần thảo luận:
- Các loại thuật toán: Content-based filtering, Collaborative filtering (User-based, Item-based), Hybrid.
- Thu thập dữ liệu: Lịch sử duyệt, mua hàng, tương tác của người dùng.
- Processing pipeline: Batch processing (Hadoop, Spark) để tính toán offline, real-time processing cho các gợi ý ngay lập tức.
- Lưu trữ gợi ý: Cache hoặc NoSQL database.
- A/B Testing: Để đánh giá hiệu quả của các thuật toán.
9. Thiết kế một hệ thống Distributed ID Generator (như Snowflake)
Khi làm việc với các hệ thống phân tán, việc tạo ra các ID duy nhất, tăng dần mà không có điểm nghẽn là một thách thức quan trọng.
- Yêu cầu cơ bản: Tạo ra các ID duy nhất, tăng dần theo thời gian, có thể phân phối trên nhiều server.
- Các điểm cần thảo luận:
- UUID: Ưu điểm (duy nhất toàn cầu), nhược điểm (không tăng dần, kích thước lớn).
- Database auto-increment: Nhược điểm (điểm nghẽn khi scale).
- Snowflake-like ID: Kết hợp timestamp, worker ID (ID của server/node), sequence number. Ưu điểm (tăng dần, duy nhất, phân tán, có thể giải mã thời gian).
- Clock skew: Xử lý khi đồng hồ giữa các server bị lệch.
10. Thiết kế một hệ thống Data Ingestion Pipeline
Đây là câu hỏi về việc thu thập, chuyển đổi và tải dữ liệu từ nhiều nguồn khác nhau vào một hệ thống lưu trữ tập trung.
- Yêu cầu cơ bản: Thu thập dữ liệu từ các nguồn khác nhau (logs, database, external APIs), xử lý và lưu trữ.
- Các điểm cần thảo luận:
- Nguồn dữ liệu: Database Change Data Capture (CDC), Kafka/message queues, S3, APIs.
- ETL/ELT: Extract, Transform, Load. Lựa chọn giữa xử lý trước khi tải hay sau khi tải.
- Công cụ: Kafka Connect, Flink, Spark, NiFi.
- Data Lake/Warehouse: Nơi lưu trữ cuối cùng (S3, HDFS, Snowflake).
- Schema Evolution: Cách xử lý khi schema dữ liệu nguồn thay đổi.
- Monitoring: Giám sát luồng dữ liệu, lỗi.
II. Lời Khuyên Chung Khi Phỏng Vấn System Design
Dù gặp câu hỏi nào, hãy luôn tuân thủ một quy trình tư duy có cấu trúc:
- 1. Đặt Câu Hỏi Làm Rõ (Clarify Requirements): Luôn bắt đầu bằng việc hỏi rõ yêu cầu chức năng (functional requirements) và phi chức năng (non-functional requirements) như số lượng người dùng, TPS (transactions per second), độ trễ chấp nhận được, độ bền, độ sẵn sàng.