6 Sai Lầm Kinh Điển Khi Phỏng Vấn System Design Và Cách Khắc Phục Chuẩn Senior

1. Nhảy bổ vào vẽ kiến trúc ngay khi vừa nhận đề

Lỗi phổ biến nhất của các ứng viên Mid-level là vừa nghe đề bài (ví dụ: 'Thiết kế hệ thống URL Shortener') đã vội vã vẽ Load Balancer, Microservices, Redis Cache và Database lên bảng. Điều này chứng minh bạn đang thiết kế dựa trên phản xạ thuộc lòng chứ không dựa trên yêu cầu thực tế.

Người phỏng vấn muốn thấy bạn làm rõ phạm vi (Scope clarification) và xác định đúng các yêu cầu chức năng (Functional Requirements) lẫn phi chức năng (Non-functional Requirements) trước khi đặt viên gạch đầu tiên.

Cách khắc phục: Dành ít nhất 5 phút đầu tiên để đặt câu hỏi làm rõ các ràng buộc kỹ thuật và phạm vi bài toán.

• Cách nói chưa tốt: 'Vâng, với bài toán này em sẽ dùng 1 cụm Load Balancer Nginx, kết nối vào 3 service Go, lưu data vào Cassandra...'
• Cách diễn đạt chuẩn Senior: 'Trước khi đi vào thiết kế chi tiết, em muốn làm rõ phạm vi MVP. Chúng ta đang ưu tiên tính năng cốt lõi nào: chỉ rút gọn link và redirect, hay cần cả custom alias và analytics theo thời gian thực?'

2. Lạm dụng Buzzwords và Over-engineering

Đưa Apache Kafka, Kubernetes, Event Sourcing hay NoSQL Cluster vào một hệ thống chỉ phục vụ vài trăm người dùng là biểu hiện rõ ràng của việc lạm dụng từ khóa kỹ thuật (Buzzword Bingo) mà không có căn cứ thực tế.

Một Senior Engineer luôn tuân thủ nguyên tắc KISS (Keep It Simple, Stupid) và YAGNI (You Aren't Gonna Need It). Bạn nên bắt đầu bằng một thiết kế đơn giản, hoạt động được, sau đó chỉ mở rộng khi xác định được điểm nghẽn (bottleneck) cụ thể dựa trên số liệu tải.

Hãy nhớ rằng việc chọn một Relational Database (như PostgreSQL) kết hợp Indexing tối ưu thường giải quyết tốt hơn nhiều bài toán ở giai đoạn khởi đầu so với việc phân tán dữ liệu phức tạp.

• Cách nói chưa tốt: 'Em sẽ đẩy toàn bộ event qua Kafka và lưu vào DynamoDB để đảm bảo hệ thống có thể mở rộng vô hạn.'
• Cách diễn đạt chuẩn Senior: 'Với lưu lượng ban đầu khoảng 500 Write QPS và yêu cầu tính toàn vẹn dữ liệu tài chính cao, em đề xuất dùng PostgreSQL với mô hình Master-Slave. Khi lượng write tăng đột biến vượt ngưỡng chịu tải của master, chúng ta mới cân nhắc sharding hoặc đưa Message Queue vào để buffer.'

3. Biến buổi phỏng vấn thành một màn độc thoại

Nhiều ứng viên nói liên tục 20 phút mà không dừng lại quan sát phản ứng của interviewer. Phỏng vấn System Design bản chất là một buổi thảo luận kỹ thuật (Collaborative Design Session) mô phỏng cách bạn làm việc với đồng đội trong dự án thực tế.

Nếu bạn độc thoại, bạn sẽ bỏ lỡ những gợi ý (hints) cực kỳ quan trọng mà interviewer đang cố gắng đưa ra để kéo bạn ra khỏi ngõ cụt.

Hãy chủ động chia nhỏ bài trình bày thành các mốc (checkpoints) và xin ý kiến phản hồi trước khi đào sâu vào một module cụ thể.

• Cách nói chưa tốt: (Nói liên tục không ngừng nghỉ về cách implement thuật toán hash)
• Cách diễn đạt chuẩn Senior: 'Em vừa hoàn thành thiết kế tầng API và Data Model tổng quan. Chúng ta có thể đi sâu vào cơ chế Cache Invalidation hoặc bàn về chiến lược Sharding Database, anh/chị muốn em tập trung vào phần nào trước?'

4. Bỏ qua việc phân tích đánh đổi (Trade-offs)

Trong thiết kế hệ thống phân tán, không có giải pháp hoàn hảo (No Silver Bullet) — mọi quyết định đều đi kèm với cái giá phải trả. Việc khẳng định một công nghệ hay kiến trúc là 'tốt nhất' mà không nêu ra nhược điểm là lỗi trừ điểm rất nặng.

Interviewer đánh giá cao ứng viên hiểu rõ Định lý CAP, sự đánh đổi giữa Latency vs Consistency, Availability vs Partition Tolerance, cũng như chi phí hạ tầng (Cost) vs độ phức tạp vận hành (Operational Complexity).

Mỗi khi bạn chọn một giải pháp (như Cache, Asynchronous Worker, Denormalization), hãy luôn giải thích bạn được gì và mất gì.

• Cách nói chưa tốt: 'Em sẽ đặt Redis cache ở trước Database để hệ thống luôn phản hồi dưới 5ms.'
• Cách diễn đạt chuẩn Senior: 'Dùng Redis Cache giúp giảm read latency xuống dưới 5ms và giảm tải cho DB. Tuy nhiên, trade-off ở đây là chúng ta phải chấp nhận Eventual Consistency và đối mặt với bài toán Cache Invalidation khi dữ liệu gốc thay đổi.'

5. Ước tính quy mô (Back-of-the-envelope) một cách hời hợt hoặc bịa số

Phần ước tính dung lượng và tải (Scale estimation) không phải là thủ tục cho có, mà là nền tảng số liệu để quyết định kiến trúc: cần bao nhiêu server, dung lượng đĩa cứng trong 5 năm là bao nhiêu, và băng thông mạng (Bandwidth) có bị nghẽn không.

Nhiều ứng viên đưa ra những con số vô căn cứ hoặc tính toán sai đơn vị nghiêm trọng (nhầm lẫn giữa Byte và Bit, MB và GB), dẫn đến việc chọn giải pháp lưu trữ sai lệch hoàn toàn.

Hãy ghi nhớ các hằng số cơ bản (ví dụ: 1 ngày có ~86.400 giây, làm tròn thành 100.000 để tính nhẩm) và thực hiện phép tính theo các bước rõ ràng: DAU -> QPS (Read/Write) -> Storage per day/year -> Bandwidth.

• Cách nói chưa tốt: 'Em đoán hệ thống cần khoảng vài terabyte bộ nhớ.'
• Cách diễn đạt chuẩn Senior: 'Với 10 triệu DAU và mỗi user tạo trung bình 2 request/ngày, chúng ta có ~20 triệu write request/ngày, tương đương ~230 Write QPS. Mỗi bản ghi nặng ~500 bytes, vậy mỗi ngày cần 10GB storage, và 5 năm sẽ cần khoảng 18TB chưa tính replication factor.'

6. Quên tính đến các điểm chết (Single Point of Failure - SPOF) và rủi ro

Một bản thiết kế chỉ hoạt động tốt trong kịch bản lý tưởng (Happy Path) là thiết kế thiếu thực tế. Hệ thống phân tán luôn có thể gặp sự cố: database chết, network partition, message queue bị tràn, hoặc cache bị sập đột ngột (Cache Avalanche).

Ứng viên cao cấp luôn chủ động đưa ra các phương án dự phòng: Data Replication, Multi-AZ deployment, Circuit Breaker, Rate Limiting và Dead Letter Queue (DLQ) để đảm bảo High Availability và Fault Tolerance.

• Cách nói chưa tốt: 'Dữ liệu được lưu ở database chính nên không sợ mất.'
• Cách diễn đạt chuẩn Senior: 'Tầng Database hiện tại đang là SPOF. Em sẽ thiết kế mô hình Multi-AZ với 1 Master và 2 Read Replicas, đồng thời cấu hình Auto-failover để tự động thăng cấp Replica lên làm Master nếu node chính mất kết nối quá 30 giây.'