[System design interview] – Overview cùng Hằng Béo

— Anh Tèo, anh có biết về System Design không?
— Có. Mà mày hỏi làm gì?
— Em… đi phỏng vấn
— Cuối năm rồi, sao không ở lại nốt năm rồi chuyển? Đi phỏng vấn clgt???
— Haizz. Một câu chuyện dài, em kể sau nhé. Tập trung vào chủ đề chính đi. Em nên làm gì để chuẩn bị tốt cho phỏng vấn System Design?
— Ok, hướng dẫn xong thì đi beer nhé.
— Vào việc.

Tóm tắt kiến thức

• System design là một trong những mục quan trọng khi phỏng vấn Senior Developer, Tech Lead, Architect. Nói chung là những vị trí có liên quan đến design hệ thống.
• Mục đích của cuộc phỏng vấn:
• Đánh giá khả năng design hệ thống, kiến trúc của ứng viên.
• Đánh giá khả năng trao đổi trong quá trình design, giải thích, bảo vệ ý tưởng.
  • Cân nhắc ưu và nhược điểm để tìm được giải pháp khả thi
• Thường session này kéo dài khoảng 45 phút
• Một framework phổ biến bạn nên áp dụng để kiểm soát thời gian khi phỏng vấn System Design:
• Xác định vấn đề
  • Hiểu được vấn đề, phạm vi vấn đề
  • Nên hỏi thật nhiều, để thu hẹp phạm vi của vấn đề
  • Tìm ra các functional requirements, non-functional requirements
  • Hãy nêu ra các giả định của bạn, vì có thể người phỏng vấn chỉ quan tâm tới một khía cạnh cụ thể
  • Giả định số người dùng, tính toán số lượng request, traffic, storage, … cũng như chi phí cần thiết
  • Bước này mới chỉ là bước một, đừng bị sa lầy
• Design hệ thống ở mức high level
  • Lúc này đi sâu vào việc phân tích hệ thống nên dùng gì (VD: GraphQL/ RPC), giải thích lý do
  • Output của step này nên là một bản design cơ bản, có luồng dữ liệu trông như thế nào, có thể dùng một số công nghệ nào, …
• Đi sâu vào design
  • Lúc này phân tích mối quan hệ giữa các thành phần của hệ thống, cũng như các thành phần bên ngoài (DB, cache, …)
  • Có thể sử dụng các design pattern, thuật toán để giải quyết vấn đề
  • Tìm cách xử lý các vấn đề thường gặp như: query optimization, xử lý dữ liệu lớn, partitioning, …
  • Bạn cần trình bày được ưu và nhược điểm của các cách design khác nhau, cũng như lý do bạn chọn cách design này, ưu và nhược điểm trong một hoàn cảnh nhất định.
• Xác định bottle neck & scale
  • Giả định khi hệ thống tăng trưởng, bottle neck sẽ nằm ở đâu, và cách giải quyết
  • Khi số lượng người dùng tăng gấp nhiều lần, hệ thống có thể scale hay không?
  • Có dùng CDN không? Chuyển sang dùng DB NoSQL thay vì SQL không?…
• Tóm tắt lại
  • Liệt kê lại các vấn đề quan trọng trong design của bạn
  • Dù các bước trên bạn đã làm rồi, tuy nhiên vẫn nên kiểm tra lại, đảm bảo bạn không bỏ sót chi tiết nào.
• Timeline recommend:
  • 5 phút: xác định vấn đề
  • 10 phút: design hệ thống ở mức high level
  • 10 phút: đi sâu vào design
  • 10 phút: xác định bottle neck & scale
  • 5 phút: tóm tắt lại

Chém

— Đầu tiên, để làm được System Design tốt thì mày phải biết cấu trúc một buổi phỏng vấn System Design như thế nào đã.
— Thường thì sẽ gồm có năm phần: xác định vấn đề, design hệ thống ở mức high level, đi sâu vào design, xác định bottle neck & scale, tóm tắt lại. Và một điều rất quan trọng: kiểm soát thời gian của từng phần thật tốt, không để lún quá thời gian, ảnh hưởng đến kết quả bài phỏng vấn chung.
— Hm.. phức tạp thế à. Bình thường em hay xem có entity nào, phân tích xem có field gì, tạo bảng rồi múc thôi.
— Ừ, mà đấy là phỏng vấn cho sinh viên em ạ. Phỏng vấn Senior đ’ ai lại làm thế
— Hihi, thế ạ. Chắc anh nói chi tiết hơn từng phần, để cả em và bạn đọc cùng nắm được đi ạ.

Xác định vấn đề

— Phần này rất quan trọng nhé, nó giúp em hiểu được vấn đề là gì, và thu hẹp được vấn đề
— Anh lấy ví dụ đi ạ
— Ví dụ người ta yêu cầu thiết kế hệ thống đỗ xe đi, theo mày thì cần làm gì?
— Theo em thì cần có một bảng chứa thông tin xe, một bảng chứa thông tin người dùng, một bảng chứa thông tin bãi đỗ xe, một bảng chứa thông tin vé, một bảng chứa thông tin lịch sử đỗ xe, …
— Vkl, sai toét . Đấy không gọi là xác định vấn đề. Xác định vấn đề ở đây là mày phải hiểu được vấn đề là gì, và thu hẹp vấn đề lại, tìm các functional requirements, non-functional requirements, … vì có thể người phỏng vấn chỉ quan tâm tới một khái niệm cụ thể thôi
— Vẫn mơ hồ, em đíu hiểu. Chi tiết hơn cho bài toán anh đặt ra đi ạ
— Ví dụ với bài toán đỗ xe:

• Xác định vấn đề: hệ thống đỗ xe
• Xác định phạm vi: hệ thống đỗ xe ở mức thành phố hay cả nước, hay thậm chí là go global?
• Functional requirements: hệ thống phải có chức năng gì? Ví dụ: đỗ xe, thanh toán, …
• Non-functional requirements: hệ thống phải đảm bảo những yêu cầu gì? Ví dụ: độ trễ, độ tin cậy, tính tiện lợi, bảo mật,…

— Oh, em hiểu rồi. Nhưng mà làm sao để tìm ra được các functional requirements, non-functional requirements?
— Phần này phải… học và làm thực tế rồi, mới list out ra được. Cũng cần có chút kiến thức thực tế nữa. Ví dụ như hệ thống đỗ xe, nếu là hệ thống đỗ xe ở mức thành phố thì cần có chức năng tìm kiếm bãi đỗ xe gần nhất, còn nếu là hệ thống đỗ xe ở mức cả nước thì cần có chức năng tìm kiếm bãi đỗ xe gần nhất ở thành phố đó, …
— Okk, cũng lơ mơ goy. Phần này nên chiếm bao nhiêu thời gian thì hợp lí thế anh?
— Khoảng 5 phút thôi.
— Vl

Design high level

— Lúc này, mày bắt đầu đi sâu vào việc phân tích hệ thống nên dùng công nghệ gì, một luồng dữ liệu cơ bản sẽ trông ra sao,… Nhìn chung ở bước này, output ra cần có một luồng cơ bản dữ liệu đi từ đâu đến đâu, dùng công nghệ gì, lí do là gì,…
— Kiểu dùng GraphQL hay RPC; dùng SQL hay NoSQL phải không anh?
— Chuẩn, không cần chỉnh
— Xong bước này làm gì tiếp anh?

Đi sâu vào design

— Lúc này mày phân tích sâu hơn vào các thanh phần của hệ thống, cũng như các thành phần bên ngoài (DB, cache,…)
— Có phải chỗ này sẽ phân tích xem có dùng design pattern hoặc thuật toán gì nữa đúng ko anh zai?
— Đúng rồi. Ngoài ra còn phải assump các vấn đề có thể gặp về performance để thiết kế sao cho hệ thống hiệu quả nữa. Giải quyết các vấn đề như: query optimization, xử lý dữ liệu lớn (sharding, partitioning data,…)
— Haizz, phức tạp nhỉ!
— Chưa hết, em còn phải trình bày ưu, nhược điểm của các design khác nhau, cũng như lý do em chọn design này; nói ưu, nhược điểm trong một context cụ thể của bài phỏng vấn
— …

Xác định bottle neck & scale

— Ở bước này, em giả định rằng tình hình kinh doanh tốt, hệ thống cần scale lên để đáp ứng được nhu cầu của business.
— Hm… nghe có mùi cần phân tích xem có dùng CDN không, có chuyển sang các database chuyên biệt hay không, caching thế nào, đúng không anh?
— Yea. Đúng là như vậy. Một việc rất quan trọng: cần phân tích kĩ càng xem bottle neck có thể nằm ở đâu. Cần phân tích chính xác thì mới đưa ra được giải pháp chính xác!
— Yes, sir.

Wrap up

— Bước này thì em summary lại là em làm cái qq gì nãy giờ; cái nào đẹp khoe, xấu che (có thể đưa vài lý do bao biện: do thời gian ít quá, tao chọn cách A, maybe có thời gian, tao sẽ chọn cách tốt hơn, kiểu zay).

---

— Okk, em cũng hình dung sơ sơ rồi đấy. Cơ mà thời gian cho từng phần thì thế nào anh? Chắc cũng nên có timeline cho từng phần cho dễ kiểm soát nhỉ?
— Exactly! Cụ thể thì nên làm ntn:

• 5 phút: xác định vấn đề
• 10 phút: design hệ thống ở mức high level
• 10 phút: đi sâu vào design
• 10 phút: xác định bottle neck & scale
• 5 phút: tóm tắt lại

— Oh. Ngonnn. Maybe anh nên kéo dài series này lên. Đưa cụ thể vài case vào làm thì anh em mới hiểu được
— Uh. Anh sẽ cố gắng