Hành trình “từ ngáo ngơ tới ngộ ra chân lý”
Để tôi nói thẳng luôn nhé.
Có một thời gian, hễ thấy video hay blog nào nhắc đến “System Design” là tôi bấm skip ngay và luôn.
Trong đầu nghĩ: “Ơ cái này chắc toàn dành cho mấy ông senior engineer, kiến trúc sư hệ thống các kiểu, chứ tầm thường phàm nhân như mình thì thôi khỏi.”
Và tôi đã lầm to.
Bởi vì một ngày đẹp trời, đi phỏng vấn, người ta hỏi tôi:
“Bạn thử design một app gọi xe giống Uber xem nào?”
Tôi đứng hình.
Lắp bắp nói về REST API.
Có nhắc nhẹ MySQL.
Rồi… im luôn.
Không biết làm sao để scale, không biết queue để làm gì, thậm chí không rõ lưu tọa độ real-time thì nhét vào đâu.
Hôm đó tôi thề: chuyện này không được lặp lại.
Và đây là cách tôi đi từ mù tịt → sang tự tin chém system design trong phỏng vấn, thậm chí còn góp ý design cho dự án công ty.
1. Thừa nhận mình “ngáo” và thấy cũng chẳng sao
System Design ban đầu nghe rất hầm hố.
Người ta vứt vào mặt bạn nào là: sharding, CQRS, load balancer, eventual consistency…
Lúc đầu tôi thấy mình đúng dốt. Nhưng rồi mới nhận ra:
Ai học cũng mù mờ ban đầu thôi.
System design không phải một chương sách mà đọc xong là xong. Nó là một combo của:
-
Dữ liệu chạy kiểu gì
-
Các service buôn chuyện với nhau ra sao
-
Hệ thống chịu tải khủng thế nào mà không xỉu
-
Và làm sao để vừa nhanh, vừa khỏe, vừa không die
Khi tôi chấp nhận rằng học cái này cần thời gian, tôi thấy nhẹ nhõm hẳn.
Ngưng tìm sự hoàn hảo, tập trung vào “win nhỏ nhỏ” trước.
2. Bẻ nhỏ “System Design” thành mấy miếng gọn gàng
System Design thực ra là cả mớ lego. Thế là tôi vẽ sơ đồ học cho mình:
a) Basics
-
Gõ URL thì chuyện gì xảy ra
-
DNS, Load Balancer, CDN là cái gì
-
TCP vs UDP, HTTP vs HTTPS
=> Mấy cái cơ bản này mà trước giờ tôi coi thường, ai ngờ học xong thấy mở não.
Ví dụ DNS chính là danh bạ điện thoại của internet, còn CDN là lý do YouTube load nhanh như chớp.
b) Data & Storage
-
SQL vs NoSQL
-
Indexing, Replication, Sharding
-
Khi nào chọn MongoDB, khi nào PostgreSQL
=> Tôi từng dại dột chọn Mongo để lưu transaction. Sau này ăn quả đắng.
c) Scaling Techniques
-
Scale ngang vs scale dọc
-
Cache (Redis, Memcached)
-
Load balancing (round-robin, IP hashing)
=> Đoạn này học vui, cảm giác mình sắp design được app cho cả triệu người dùng (trên giấy thôi chứ prod thì còn lâu).
d) Architecture Patterns
-
Monolith vs Microservices
-
Event-driven Architecture
-
Pub/Sub, Queue (Kafka, RabbitMQ)
=> Lúc này mới hiểu tại sao Netflix thích microservices. Không phải chạy trend, mà vì scale khủng khiếp.
3. Xem người thật làm, không chỉ nghe giảng
Tôi bỏ xem tutorial kiểu “thầy đọc – trò chép”, chuyển sang xem mock interview.
Tin tôi đi, cuộc đời sang trang.
Vì khi ai đó nghĩ thành tiếng, sai rồi sửa, giải thích trade-off, thì mình mới học được cách nghĩ, không phải copy.
Các kênh tôi nghiền:
-
Gaurav Sen: giải thích từ gốc rễ
-
Exponent: mock interview như đi thi thật
-
ByteByteGo: vừa visual vừa kể chuyện
Nhờ đó tôi học được cách:
-
Hỏi câu clarify chuẩn
-
Định nghĩa functional vs non-functional requirement
-
Walkthrough API, DB, scaling logic
-
Luôn nói về trade-off, không chỉ đưa ra lựa chọn
4. Bắt đầu vẽ bậy (trên giấy cũng được)
Bất ngờ nhất: vẽ giúp tôi ngộ ra nhiều thứ.
Tôi không biết vẽ đẹp, nhưng vẽ sơ sơ client → load balancer → app server → DB là thấy sáng mắt ra.
Nhờ vẽ:
-
Request flow trở nên rõ ràng
-
Nhìn ra chỗ nghẽn cổ chai
-
Biết đặt cache chỗ nào, nhét queue lúc nào
Tới giờ kẹt bài toán, tôi vẫn cầm giấy bút vẽ nguệch ngoạc. Thường nó cho tôi insight mà đọc chữ không bao giờ có.
5. Thực chiến với các bài tập System Design
Học cơ bản xong, tôi ngưng xem video và tự tay design.
Cách luyện của tôi:
-
Chọn hệ thống thật: WhatsApp, YouTube, Zomato, Instagram
-
Viết functional requirement
-
Thêm non-functional (scale, latency, availability)
-
Estimate (số user, QPS, DB size)
-
Vẽ high-level architecture
-
Đi sâu vào: DB schema, API, scaling, failure, edge case
Tôi viết 1 thiết kế/tuần. Không chỉ 1 solution mà nhiều option.
Vì phỏng vấn (và đi làm) hiếm khi có đáp án tuyệt đối. Quan trọng là giải thích tại sao chọn A mà không chọn B.
6. Đem áp dụng ngay vào công việc
Lý thuyết mà không thực hành thì vứt.
Ở công ty, tôi làm service sinh EMI traffic cao, có Kafka, REST API, transaction phức tạp.
Đây là lúc tôi thử áp dụng design:
-
Đề xuất tách monolith thành service
-
Dùng queue cho async
-
Thêm retry + dead-letter queue
-
Tranh luận Kafka vs gRPC (dựa trên latency & control)
Không hoàn hảo, nhưng đủ để tôi thấy: system design không chỉ là bài phỏng vấn, mà là kỹ năng thật sự hữu ích cho team.
7. Dạy lại cho người khác
Level cuối: đi truyền giáo.
Khi bạn phải giải thích cho intern hay viết blog, bạn mới thấy rõ mình còn hổng chỗ nào.
Tôi đã:
-
Mentor cho junior lúc onboarding
-
Dạy mini session về cache, DB design, queue
-
Viết blog kèm hình vẽ
-
Chuẩn bị junior cho phỏng vấn design
Mỗi lần giải thích, tôi nhận ra:
“Nếu mình nói được cho người khác hiểu đơn giản → tức là mình đã thật sự hiểu.”
Lời khuyên chân thành cho bạn
Nếu bạn mới bắt đầu hôm nay, hoặc từng fail một buổi phỏng vấn design, thì hãy nhớ:
-
System Design không phải ma thuật
-
Không cần 10 năm kinh nghiệm
-
Không cần thuộc làu làu diagram của Gaurav Sen
Bạn chỉ cần:
-
Bắt đầu từ basics
-
Nghĩ theo use case thật
-
Xây khung
-
Luyện đều đặn
-
Hỏi “tại sao” cho mọi quyết định
Thậm chí mỗi ngày chỉ dành 30 phút, sau 3 tháng bạn sẽ thấy mình khác bọt.
Quan trọng là cách tiếp cận, không phải đáp án
Trong system design, bạn sẽ luôn thấy mông lung. Bình thường thôi.
Cái cần là cách bạn xử lý:
-
Scale bao nhiêu?
-
Nút thắt ở đâu?
-
Trade-off giữa DB này với DB kia?
-
Service này die thì sao?
Đó mới là thứ biến bạn thành dev xịn, chứ không phải số diagram bạn học vẹt.
Thế nên, cứ tiếp tục đi.
Bắt đầu từ “URL hoạt động thế nào?” rồi kết thúc bằng việc tự tin design cả Instagram.
Bạn sẽ ngạc nhiên khi nhìn lại: mình đã đi được xa tới mức nào, chỉ bằng cách build từng hệ thống một. 🚀
Link bài gốc :
https://medium.com/@himanshusingour7/how-i-learned-system-design-d7444d454367