Một trong những lý do phổ biến nhất khiến các Senior Software Engineer rớt vòng System Design tại các công ty tier-1 không phải vì họ thiết kế hệ thống sai, mà vì họ thiết kế hệ thống quá phức tạp so với yêu cầu thực tế.
Khi ứng viên phụ thuộc vào ChatGPT hay Claude để ôn tập, họ vô tình thừa hưởng một lỗ hổng chí mạng: Sự thiên lệch dữ liệu huấn luyện (Training Data Bias). Bài viết này mổ xẻ nguyên nhân AI khiến bạn mắc lỗi Over-engineering và cách khắc phục bằng tư duy tính toán nền tảng (First-principles capacity planning).
Nguồn Gốc Của Cạm Bẫy: AI Học Từ Đâu?
Các mô hình Ngôn ngữ Lớn (LLM) được huấn luyện dựa trên kho tàng dữ liệu khổng lồ từ Internet. Trong lĩnh vực kỹ thuật phần mềm, dữ liệu chất lượng cao nhất thường đến từ Engineering Blogs của các gã khổng lồ công nghệ: Netflix, Uber, Meta, hay Airbnb.
Những bài viết này không thảo luận về việc dựng một server Monolith với database Postgres đơn giản. Họ viết về Microservices, Kubernetes (K8s), Distributed Message Queues (Kafka), và Multi-cloud Active-Active Failovers.
Hệ quả là, khi bạn đưa cho AI một bài toán System Design cơ bản (ví dụ: "Thiết kế hệ thống rút gọn URL"), phản xạ mặc định của AI là ném toàn bộ các công nghệ "đao to búa lớn" vào kiến trúc.
Tiêu Chí
Phản Xạ Của AI (Học từ Big Tech)
Thực Tế Bài Toán Yêu Cầu
Kiến trúc
Microservices phức tạp, chia nhỏ mọi domain.
Monolithic hoắc Service-Oriented (SOA) đơn giản.
Cơ sở dữ liệu
NoSQL (Cassandra/DynamoDB) + Sharding ngay từ đầu.
RDBMS (PostgreSQL) + Vertical Scaling.
Giao tiếp
Bất đồng bộ qua Kafka / RabbitMQ.
RESTful API / gRPC gọi trực tiếp.
Quy luật Đánh đổi (The Trade-off Rule): Mọi công nghệ phân tán (distributed system) được đưa vào kiến trúc đều giải quyết bài toán Khả năng mở rộng (Scalability), nhưng cái giá phải trả là Độ phức tạp vận hành (Operational Complexity) và Tính nhất quán dữ liệu (Data Consistency). Nếu bạn không chứng minh được hệ thống cần mở rộng đến mức đó, bạn sẽ bị đánh rớt vì over-engineering.
Sự Thật Bị Lãng Quên: Một Server Có Thể Chịu Tải Bao Nhiêu?
Trong một cuộc phỏng vấn, khi bạn vội vàng vẽ ra một hệ thống load balancer kết nối với 10 nodes K8s cho một ứng dụng nội bộ, Interviewer sẽ nhìn bạn với ánh mắt ái ngại.
Thực tế, phần cứng hiện đại vô cùng mạnh mẽ. Một server cỡ trung (ví dụ: AWS EC2 c6g.4xlarge) được cấu hình tốt hoàn toàn có thể xử lý hàng nghìn request mỗi giây (RPS). Nếu bạn áp dụng microservices và message queues cho một hệ thống chỉ có50 RPS, bạn đang tự đào mồ chôn mình trong vòng phỏng vấn.
Giải Pháp: Thiết Kế Dựa Trên Toán Học (Capacity Planning)
Để thoát khỏi cái bóng của AI, bạn phải bắt đầu mọi buổi phỏng vấn System Design bằng những câu hỏi định lượng. Đừng vội vẽ các khối hình. Hãy làm toán.
Các Bước Định Lượng Bắt Buộc:
Làm rõ quy mô người dùng: Total users, Daily Active Users (DAU), Concurrent users.
Hành vi người dùng: Tần suất gửi request/user/ngày?
Tỷ lệ Read/Write: Hệ thống thiên về đọc hay ghi?
Tính toán Throughput (RPS): Đây là con số quyết định kiến trúc của bạn.
[BẢN ĐỒ QUYẾT ĐỊNH DỰA TRÊN THROUGHPUT]
Tính toán RPS (Requests Per Second)
│
├─── RPS < 100
│ └─> Một Server + Monolithic DB (Postgres/MySQL).
│ Tập trung vào Vertical Scaling.
│
├─── RPS: 1,000 - 10,000
│ └─> Tách Read/Write (DB Replicas).
│ Thêm Caching Layer (Redis/Memcached).
│ Horizontal Scaling cho App Servers.
│
└─── RPS > 100,000
└─> Đổi sang NoSQL / Database Sharding.
Áp dụng Message Queues (Kafka) để buffer Write.
Microservices để scale các components độc lập.
Nếu Interviewer nói ứng dụng chỉ có 10,000 người dùng nội bộ, bạn dừng lại ở nhánh đầu tiên. Hãy giải thích rõ ràng: "Dựa trên mức 50 RPS, một server đơn kết hợp với Postgres là đủ. Việc đưa Kafka hay Microservices vào lúc này là lãng phí tài nguyên và tăng chi phí bảo trì không cần thiết." Đây chính là câu trả lời của một Senior Engineer thực thụ.
Bài Học Mở Rộng Cho Product Managers (PM)
Engineers
Product Managers
The Trigger
AI đề xuất kiến trúc quy mô Netflix.
AI đề xuất các bộ tính năng phức tạp.
The Metric Missed
Bỏ qua Throughput (RPS).
Bỏ qua việc đánh giá quy mô vấn đề (Quy mô thị trường / Tần suất).
The Fix
Tính toán sơ bộ.
Minimal Viable Product (MVP) validation.
Tư duy rập khuôn từ AI không chỉ giới hạn ở kỹ sư. Các PM cũng thường mắc hội chứng Solutionism (Nghiện giải pháp) khi dùng AI để chuẩn bị cho vòng Product Sense.
AI thường đề xuất các tính năng đồ sộ như "Công cụ gợi ý bằng AI thời gian thực" hoặc "Hệ thống Gamification đa nền tảng". Tương tự như System Design, việc đưa ra giải pháp quá phức tạp khi chưa đo lường đúng quy mô vấn đề (Problem Sizing) cho thấy bạn thiếu nhạy bén về kinh doanh.
Với Kỹ sư: Lấy Throughput (RPS) làm điểm neo kiến trúc.
Với PM: Lấy Quy mô Vấn đề (TAM / Tần suất Pain point) làm điểm neo giải pháp. Xây dựng MVP đơn giản nhất để kiểm chứng trước khi scale lên những mô hình phức tạp.
Trí tuệ nhân tạo là một thư viện giải pháp khổng lồ, nhưng sự nhạy bén trong việc chọn lọc giải pháp phù hợp với quy mô thực tế mới là kỹ năng giúp bạn đỗ phỏng vấn tại các công ty tier-1.
Case StudyApr 11, 2026
Bài Toán "Chấm Xanh" Của Slack: Cơn Ác Mộng Kiến Trúc Thời Gian Thực
Việc hiển thị trạng thái online tưởng chừng cơ bản nhưng lại là bài toán hạ tầng khổng lồ ở quy mô lớn. Phân tích cách Slack cấu trúc lại mô hình Pub/Sub để cân bằng giữa độ chính xác realtime và chi phí máy chủ.
