Vòng phỏng vấn System Design thường là rào cản lớn nhất đối với các kỹ sư muốn nâng bậc lên Senior hoặc Lead. Rất nhiều ứng viên trượt không phải vì thiếu kiến thức công nghệ, mà vì sai lầm trong cách tiếp cận vấn đề và giao tiếp với interviewer. Bài viết này sẽ phân tích 5 lỗi chí mạng thường gặp nhất và cách bạn làm chủ cuộc phỏng vấn một cách tự tin.
1. Nhảy ngay vào vẽ kiến trúc mà không làm rõ yêu cầu (Scope Clarification)
Lỗi phổ biến nhất là ngay sau khi nhận đề bài như 'Thiết kế YouTube' hay 'Thiết kế URL Shortener', ứng viên lập tức vẽ các khối Load Balancer, Microservices, Caching và Database. Điều này chứng minh bạn đang làm việc theo phản xạ thay vì tư duy phân tích thực tế.
System Design trong 45 phút không bao giờ nhằm mục tiêu dựng lại toàn bộ một hệ thống khổng lồ. Bạn cần phải cùng interviewer xác định phạm vi hệ thống: Functional Requirements (tính năng cốt lõi cần giải quyết) và Non-functional Requirements (DAU/MAU, Read/Write throughput, Latency, Data Retention, SLA).
Cách diễn đạt nên tránh: 'Em sẽ dùng Microservices với Redis Cache để thiết kế hệ thống này.'
Cách diễn đạt tốt hơn: 'Trước khi đi vào chi tiết, em muốn làm rõ phạm vi bài toán: Chúng ta tập trung vào 2 tính năng chính là upload video và xem video trực tiếp, đúng không? Về quy mô, hệ thống này cần phục vụ khoảng bao nhiêu DAU và tỷ lệ Read/Write dự kiến là bao nhiêu?'
- Luôn dành 5–7 phút đầu tiên để đặt câu hỏi làm rõ Functional và Non-functional Requirements.
- Ước lượng sơ bộ (Back-of-the-envelope estimation) về QPS, Storage và Bandwidth trước khi chọn công nghệ.
2. Chọn công nghệ theo 'Trend' thay vì dựa trên 'Trade-offs'
Nhiều ứng viên đưa Kafka, Cassandra, Kubernetes hay GraphQL vào sơ đồ chỉ vì chúng đang 'hot', nhưng khi interviewer hỏi lý do chọn thì không giải thích được sự đánh đổi (trade-offs).
Trong thiết kế hệ thống, không có giải pháp nào hoàn hảo tuyệt đối, chỉ có giải pháp phù hợp nhất với ràng buộc bài toán. Chọn NoSQL mang lại khả năng scale ngang linh hoạt nhưng phải chấp nhận hy sinh ACID transactions chặt chẽ hoặc tính nhất quán dữ liệu tức thời (Eventual Consistency).
Cách diễn đạt nên tránh: 'Hệ thống này em sẽ dùng MongoDB vì nó nhanh và hiện đại hơn MySQL.'
Cách diễn đạt tốt hơn: 'Với yêu cầu Write-heavy và cấu trúc dữ liệu metadata không cố định, em ưu tiên Document Store như MongoDB hoặc DynamoDB để scale out tốt hơn. Đổi lại, hệ thống phải chấp nhận mô hình Eventual Consistency và cần cơ chế bù trừ ở tầng ứng dụng nếu xảy ra xung đột ghi.'
- Mỗi khi đề xuất một công nghệ, hãy chủ động nêu rõ ít nhất 1 ưu điểm và 1 nhược điểm/sự đánh đổi.
- Hiểu sâu định lý CAP theorem, ACID vs BASE, SQL vs NoSQL, Sync vs Async communication.
3. Độc thoại một chiều và biến buổi phỏng vấn thành bài thuyết trình
System Design là một buổi thảo luận kỹ thuật (collaborative whiteboarding session), không phải là bài kiểm tra trả bài hay một buổi thuyết trình độc thoại. Khi bạn nói liên tục 15-20 phút mà không dừng lại quan sát phản ứng của interviewer, bạn rất dễ đi lệch khỏi hướng mà họ muốn đào sâu.
Interviewers thường chủ động thả các gợi ý (hints) hoặc chuyển hướng bài toán. Nếu bạn quá mải mê nói, bạn sẽ bỏ lỡ cơ hội nhận diện tín hiệu điều chỉnh từ họ.
Cách diễn đạt nên tránh: Nói liên tục không ngừng cho đến khi vẽ xong toàn bộ hệ thống.
Cách diễn đạt tốt hơn: 'Đây là luồng xử lý tổng quan cho Write Path. Anh/chị thấy hướng tiếp cận này đã hợp lý chưa, hay mình muốn đi sâu vào giải pháp Partitioning cho cơ sở dữ liệu ngay lúc này?'
- Thường xuyên 'check-in' với người phỏng vấn sau mỗi module hoặc sau khi hoàn thành High-level Design.
- Lắng nghe kỹ các câu hỏi ngắt lời từ interviewer; đó là nơi họ muốn kiểm tra chiều sâu kiến thức của bạn.
4. Bỏ qua các Single Point of Failure (SPOF) và kịch bản lỗi
Một thiết kế chỉ hoạt động tốt trong điều kiện lý tưởng (Happy Path) là một thiết kế chưa hoàn chỉnh. Hệ thống phân tán luôn có rủi ro: server sập, network partition, database lock, cascading failure, hoặc cache stampede.
Các senior engineer luôn thể hiện bản lĩnh thông qua việc chủ động phân tích các điểm nghẽn (bottlenecks), SPOF và cách xử lý sự cố như Circuit Breaker, Rate Limiting, Retry with Exponential Backoff, Dead Letter Queue (DLQ).
Cách diễn đạt nên tránh: 'Dữ liệu được lưu vào Redis nên response time sẽ luôn dưới 10ms.'
Cách diễn đạt tốt hơn: 'Redis Cache là một SPOF tiềm ẩn ở tầng đọc. Để phòng ngừa Cache Breakdown khi key hết hạn hoặc Redis sập, em sẽ cấu hình Redis Sentinel/Cluster với Master-Replica, đồng thời dùng Mutex Lock hoặc Cache Aside kết hợp Probabilistic Early Expiration để tránh dồn tải trực tiếp xuống Database.'
- Chủ động rà soát lại diagram và chỉ ra ít nhất 2 điểm có thể xảy ra lỗi trong hệ thống.
- Đưa ra các phương án dự phòng: Read Replicas, Multi-region deployment, Graceful Degradation.
5. Sa đà vào chi tiết vụn vặt quá sớm thay vì đi từ High-Level xuống Low-Level
Nhiều ứng viên vừa bắt đầu đã loay hoay thiết kế chi tiết từng cột trong Database Schema, hay viết mã giả cho một thuật toán cụ thể, trong khi kiến trúc tổng thể (High-level architecture) và luồng dữ liệu (Data Flow) giữa các service còn chưa được định hình.
Quy trình chuẩn là đi theo mô hình phễu: từ bức tranh toàn cảnh (Client -> CDN -> API Gateway -> Services -> Message Queue/DB) rồi sau đó mới zoom vào các component phức tạp nhất theo yêu cầu của interviewer.
Cách diễn đạt nên tránh: 'Em sẽ thiết kế bảng User gồm các trường ID bigint, email varchar(255), created_at timestamp...' ngay từ phút thứ 5.
Cách diễn đạt tốt hơn: 'Em sẽ phác thảo High-level Architecture gồm luồng Client gửi request qua API Gateway đến Auth Service và Post Service trước. Sau khi thống nhất luồng tổng thể, em sẽ đi sâu vào Data Schema và cơ chế Fan-out của Feed Service.'
- Áp dụng quy tắc Top-Down: Requirements -> High-Level Design -> Detailed Component Design -> Bottlenecks & Scale.
- Chỉ đi sâu vào Low-Level (như DB indexing, locking strategy) khi đã chốt được High-Level Flow.
Ghi nhớ nhanh
- Dành 15-20% thời gian đầu để làm rõ Requirements và ước lượng tải (Back-of-the-envelope) thay vì vội vàng vẽ hệ thống.
- Mọi quyết định kiến trúc đều đi kèm đánh đổi (Trade-offs); hãy giải thích lý do chọn công nghệ thay vì chỉ liệt kê buzzwords.
- Biến buổi phỏng vấn thành cuộc thảo luận hai chiều: liên tục tương tác và check-in với interviewer.
- Luôn thiết kế cho kịch bản có lỗi (Design for Failure) bằng cách xác định SPOF, Bottlenecks và cơ chế phục hồi.