System Design: Phỏng vấn về thiết kế hệ thống

Câu hỏi thiết kế hệ thống là gì?

Trong phần này, chúng ta sẽ nói về những câu hỏi yêu cầu người được phỏng vấn thiết kế kiến ​​trúc cấp cao cho một số loại hệ thống phần mềm. Đây có thể là một dịch vụ web, một RESTful API, một ứng dụng ngang hàng, v.v. Loại câu hỏi chính xác rất có thể sẽ khác nhau tùy thuộc vào chi tiết cụ thể của công ty bạn phỏng vấn.

Một vài câu hỏi về thiết kế hệ thống

Chúng tôi có thể đưa ra một vài ví dụ về những câu hỏi như vậy:

  • Thiết kế một dịch vụ rút ngắn URL như bit.ly.
  • Bạn sẽ triển khai công cụ tìm kiếm của Google như thế nào?
  • Thiết kế một ứng dụng client-server cho phép mọi người chơi cờ với nhau.
  • Bạn sẽ lưu trữ các mối quan hệ như thế nào trong một mạng xã hội như Facebook và triển khai một tính năng trong đó một người dùng nhận được thông báo khi bạn bè của họ thích những điều tương tự như họ?

Hy vọng rằng những câu hỏi ví dụ này cung cấp cho bạn một số ý tưởng về những gì chúng ta sẽ nói đến. Trên web có rất nhiều ví dụ khác. Ngoài ra, cuốn sách “Cracking the Coding Interview” có một phần nhỏ cung cấp thêm một số câu hỏi như vậy.

Đừng hoảng sợ những câu hỏi về thiết kế hệ thống như vậy

Những câu hỏi này thoạt nghe có vẻ đáng sợ. Rốt cuộc, làm thế nào để thiết kếcông cụ tìm kiếm Google trong 20-30 phút? Rất nhiều người thông minh đã phải mất vài năm để làm điều đó đúng cách. Đừng lo lắng, không ai thực sự mong đợi điều đó từ bạn.

Ý tưởng của những câu hỏi này là có một cuộc thảo luận về vấn đề đang bàn. Điều quan trọng đối với người phỏng vấn là quy trình mà bạn sử dụng để giải quyết vấn đề. Kết quả điển hình của một cuộc thảo luận như vậy là một kiến ​​trúc cấp cao giải quyết các mục tiêu và hạn chế trong câu hỏi. Có lẽ người phỏng vấn sẽ chọn một hoặc nhiều lĩnh vực mà họ sẽ muốn thảo luận về các điểm nghẽn và các vấn đề chung khác.

Hãy nhớ rằng không có câu trả lời đúng. Một hệ thống có thể được xây dựng theo nhiều cách khác nhau. Điều quan trọng là có thể biện minh cho ý tưởng của bạn.

Cuối cùng, hãy nhớ rằng cuộc thảo luận về cùng một vấn đề thiết kế hệ thống có thể đi theo các hướng khác nhau tùy thuộc vào mục tiêu của người phỏng vấn. Họ có thể sẵn sàng xem cách bạn tạo ra một kiến ​​trúc cấp cao bao gồm tất cả các khía cạnh của hệ thống. Hoặc đúng hơn, họ có thể quan tâm hơn đến việc xem xét một vài khu vực cụ thể và tìm hiểu sâu hơn về chúng. Trong mọi trường hợp, bạn nên có một chiến lược về cách tiếp cận các tình huống khác nhau. Chúng ta sẽ xem xét các chiến lược như vậy trong các phần tiếp theo.

Cách tiếp cận của chúng ta

Chúng tôi tin rằng các câu hỏi thiết kế hệ thống đòi hỏi sự kết hợp của chiến lược và kiến ​​thức phù hợp. Theo chúng tôi, chiến lược có nghĩa là một cách để tiếp cận vấn đề tại một cuộc phỏng vấn. Chúng tôi đã thấy những ứng viên giỏi thất bại không phải vì họ thiếu kiến ​​thức mà vì họ không thể tập trung vào những điều đúng đắn khi thảo luận một vấn đề.

Do đó, trong những phần tiếp theo, chúng tôi sẽ trình bày chiến lược tiếp cận các câu hỏi thiết kế hệ thống tại các cuộc phỏng vấn công nghệ. Ngoài ra, chúng tôi đã thu thập các tài nguyên trực tuyến hữu ích, giúp bạn cập nhật kiến ​​thức về thiết kế hệ thống phần mềm.

Tiếp theo là gì?

Bây giờ bạn đã có ý tưởng về những câu hỏi thiết kế hệ thống trông như thế nào, hãy nói về một số chiến lược để giải quyết chúng tại một cuộc phỏng vấn. Chúng ta cũng sẽ xem xét một ví dụ, sẽ giúp chúng ta áp dụng các chiến lược trong chương này.

Quy trình thiết kế hệ thống

  1. Xác định phạm vi.
  2. Thiết kế trừu tượng (abstract design).
  3. Tìm hiểu các nút thắt cổ chai (bottle neck)
  4. Mở rộng thiết kế trườu tượng.

Xác định phạm vi vấn đề

Hãy xem xét câu hỏi về dịch vụ rút ngắn URL ("Thiết kế dịch vụ rút ngắn URL như bit.ly"). Có quá nhiều điều chưa rõ ràng về nó! Nếu không biết nhiều hơn, sẽ không thể thiết kế một giải pháp thích hợp. Trên thực tế, nhiều ứng viên quên điều này và bắt đầu thiết kế một giải pháp ngay lập tức.

Đừng mắc phải sai lầm này!

Điều đầu tiên bạn nên làm với bất kỳ câu hỏi thiết kế hệ thống nào là làm rõ các ràng buộc của hệ thống và xác định các trường hợp sử dụng mà hệ thống cần đáp ứng. Dành một vài phút để hỏi người phỏng vấn của bạn và đồng ý về phạm vi của hệ thống. Nhiều quy tắc tương tự mà chúng ta đã thảo luận khi nói về thiết kế thuật toán cũng được áp dụng ở đây.

Thông thường, một phần của những gì người phỏng vấn muốn thấy là liệu bạn có thể thu thập các yêu cầu về vấn đề đang gặp phải và thiết kế một giải pháp phù hợp với chúng hay không. Đừng bao giờ cho rằng những điều không được nêu rõ ràng.

Ví dụ: dịch vụ rút ngắn URL có thể chỉ phục vụ vài nghìn người dùng, nhưng mỗi người có thể chia sẻ hàng triệu URL. Nó có thể được dùng để xử lý hàng triệu nhấp chuột vào các URL được rút gọn. Dịch vụ có thể phải cung cấp số liệu thống kê mở rộng về từng URL được rút gọn (điều này sẽ làm tăng kích thước dữ liệu của bạn) hoặc thống kê có thể không phải là một yêu cầu.

Bạn cũng sẽ phải suy nghĩ về các trường hợp sử dụng dự kiến ​​sẽ xảy ra. Hệ thống của bạn sẽ được thiết kế dựa trên những gì nó dự kiến ​​sẽ làm. Đừng quên đảm bảo rằng bạn biết tất cả các yêu cầu mà người phỏng vấn không nói với bạn ngay từ đầu.

Ví dụ

Đây là một ví dụ về cách chúng tôi tiếp cận việc xác định các trường hợp sử dụng và các ràng buộc cho vấn đề rút ngắn URL.

Xác định trường hợp sử dụng (use case)

  • Rút gọn URL: Nhận một URL và trả về một URL rút gọn.
  • Chuyển hướng truy cập: Nhận một URL rút gọn và chuyển hướng truy cập tới URL ban đầu.
  • URL tùy chỉnh: Tạo URL tùy chỉnh cho URL gốc.

Xác định ràng buộc (contraint)

  • 15 tỷ tweet / tháng (tweet link lên mạng xã hội Twitter)
  • 10% các tweet này là các URL đã được rút gọn (1,5 tỷ tweet)
  • 80% URL rút gọn này đến từ top 3 trang rút gọn URL (1,2 tỷ URL)
  • 20% URL rút gọn đến từ các trang rút gọn URL khác (300 triệu URL)
  • 1/3 của 20% URL rút gọn được tạo bởi NSE (100 triệu URL)
  • 10% tổng lưu lượng truy cập tới NSE là để tạo URL rút gọn
  • 90% tổng lưu lượng truy cập tới NSE là để chuyển hướng đến URL ban đầu

Thực hiện các tính toán

  • 1 tỷ lượt truy cập / tháng.
  • 100 triệu truy cập là để tạo URL rút gọn (10%)
  • 900 triệu truy cập là để chuyển hướng đến URL ban đầu (90%)
  • Tổng lượng truy cập 1 giây là: 400+ (40 tạo URL rút gọn, 360 chuyển hướng đến URL ban đầu).
  • 6 tỷ URL rút gọn sẽ được tạo trong 5 năm.
  • Dung lượng bộ nhớ: 500 byte cho mỗi URL, 6 byte cho mỗi mã băm
  • 3TB dung lượng bộ nhớ cho tất cả URL, 36GB dung lượng bộ nhớ cho tất cả mã băm trong 5 năm.
  • Lượng bộ nhớ cho ghi dữ liệu mới mỗi giây: 40 * (500 + 6) = 20KB
  • Lượng bộ nhớ cho đọc dữ liêu mỗi giây: 360 * (500 + 6) = 180KB
Xác định trường hợp sử dụng và ràng buộc

Thiết kế trừu tượng cấp cao

Khi bạn đã xác định phạm vi hệ thống mà bạn sắp thiết kế, bạn nên tiếp tục bằng cách phác thảo một thiết kế trừu tượng cấp cao. Mục tiêu của việc này là phác thảo tất cả các thành phần quan trọng mà kiến ​​trúc của bạn sẽ cần.

Bạn có thể nói với người phỏng vấn rằng bạn muốn làm điều đó và vẽ một sơ đồ đơn giản về ý tưởng của bạn. Phác thảo các thành phần chính của bạn và các kết nối giữa chúng. Nếu bạn làm điều này, rất nhanh chóng bạn sẽ có thể nhận được phản hồi nếu bạn đang đi đúng hướng. Tất nhiên, bạn phải có khả năng biện minh cho thiết kế cấp cao mà bạn vừa vẽ.

Đừng bị thu hút khi đi sâu vào một số khía cạnh cụ thể của thiết kế trừu tượng. Thay vào đó, hãy đảm bảo rằng bạn phác thảo các thành phần quan trọng và mối liên hệ giữa chúng. Điều chỉnh ý tưởng của bạn trước người phỏng vấn và cố gắng giải quyết mọi ràng buộc và trường hợp sử dụng.

Thông thường, kiểu thiết kế cấp cao này là sự kết hợp của các kỹ thuật nổi tiếng mà nhiều người đã phát triển. Bạn phải chắc chắn rằng bạn đã quen thuộc với những gì bên ngoài và cảm thấy thoải mái khi sử dụng kiến ​​thức này. Trong phần này, chúng tôi sẽ giả định rằng bạn có đủ kinh nghiệm để thiết kế một hệ thống cấp cao như vậy. Mục tiêu của chúng tôi là tập trung nhiều hơn vào các bước tiếp theo, nơi chúng tôi sẽ nói chủ yếu về khả năng mở rộng và về việc loại bỏ các nút thắt cổ chai.

Nếu bạn cảm thấy mình là một người mới bắt đầu hoàn chỉnh về thiết kế hệ thống, có lẽ sẽ rất hữu ích cho bạn khi đọc một số cuốn sách về chủ đề này hoặc tận dụng một số tài nguyên mà chúng tôi đã chia sẻ trên comdy.vn.

Ví dụ

Đây là một ví dụ về thiết kế trừu tượng đơn giản cho dịch vụ rút ngắn URL:

  1. Application service layer: shortening service, redirection service
  2. Data storage layer (lưu trữ thông tin ánh xạ hash => url)

Tìm hiểu các nút thắt cổ chai

Nhiều khả năng thiết kế cấp cao của bạn sẽ có một hoặc nhiều nút thắt do các hạn chế của vấn đề. Điều này là hoàn toàn ổn. Bạn không nên thiết kế một hệ thống hoàn thiện ngay từ đầu. Hệ thống chỉ cần có khả năng mở rộng, để bạn có thể cải thiện nó bằng cách sử dụng một số công cụ và kỹ thuật tiêu chuẩn.

Bây giờ bạn đã có thiết kế cấp cao của mình, hãy bắt đầu suy nghĩ xem nó có những điểm nghẽn nào. Có lẽ hệ thống của bạn cần một bộ cân bằng tải (load balancer) và nhiều server phía sau nó để xử lý các yêu cầu của người dùng. Hoặc có thể dữ liệu quá lớn nên bạn cần phân phối cơ sở dữ liệu của mình trên nhiều server. Một số nhược điểm sẽ xảy ra khi làm những điều đó là gì? Cơ sở dữ liệu có quá chậm và nó có cần một số bộ nhớ đệm trong bộ nhớ không?

Đây chỉ là những ví dụ về các câu hỏi mà bạn có thể phải trả lời để làm cho giải pháp của bạn hoàn thiện. Có thể là trường hợp người phỏng vấn muốn hướng cuộc thảo luận theo một hướng cụ thể. Sau đó, có thể bạn sẽ không cần giải quyết tất cả các nút thắt mà thay vào đó là nói chuyện chuyên sâu hơn về một lĩnh vực cụ thể. Trong mọi trường hợp, bạn cần có khả năng xác định các điểm yếu trong hệ thống và có thể giải quyết chúng.

Hãy nhớ rằng, thông thường mỗi giải pháp là sự đánh đổi của một số thứ. Thay đổi thứ gì đó sẽ làm thứ khác xấu đi. Tuy nhiên, điều quan trọng là có thể nói về những sự đánh đổi này và đo lường tác động của chúng đối với hệ thống dựa trên các ràng buộc và trường hợp sử dụng được xác định.

Khi bạn đã vạch ra những điểm nghẽn cốt lõi mà bạn thấy, bạn có thể bắt đầu giải quyết chúng trong bước tiếp theo.

Mở rộng thiết kế trườu tượng

Khi bạn đã sẵn sàng với thiết kế cấp cao của mình và đảm bảo rằng người phỏng vấn đồng ý với nó, bạn có thể đi sâu vào việc làm cho nó chi tiết hơn. Thông thường, điều này có nghĩa là mở rộng hệ thống của bạn.

Phần tiếp theo sẽ trình bày chi tiết về khả năng mở rộng. Đầu tiên chúng ta sẽ đề cập đến một số nguyên tắc cơ bản về lý thuyết, và sau đó xem xét nhiều ví dụ thực tế về các kiến ​​trúc có thể mở rộng. Cuối cùng, chúng tôi sẽ tóm tắt mọi thứ bằng một số nguyên tắc cốt lõi để thảo luận về khả năng mở rộng khi phỏng vấn.

Tóm lược

Một quy trình mạnh mẽ là rất quan trọng để giải quyết thành công các câu hỏi thiết kế hệ thống. Chúng tôi đã chia nó thành bốn bước:

  • Xác định phạm vi vấn đề: Đừng đưa ra giả định; Hãy đặt các câu hỏi; Hiểu các ràng buộc (contraint) và các trường hợp sử dụng (use case).
  • Phác thảo một thiết kế trừu tượng cấp cao minh họa các thành phần cơ bản của hệ thống và mối quan hệ giữa chúng.
  • Hãy nghĩ về những nút thắt cổ chai mà các thành phần này gặp phải khi hệ thống mở rộng quy mô.
  • Giải quyết những tắc nghẽn này bằng cách sử dụng các nguyên tắc cơ bản của thiết kế hệ thống có thể mở rộng .

Tiếp theo là gì?

Sau khi đã nắm được quy trình mạnh mẽ ở trên, bây giờ bạn cần phải chuyển sang làm cho nó hoạt động trên quy mô lớn. Bạn sẽ cần phải hiểu các thành phần cơ bản của hệ thống có thể mở rộng, cách giải quyết các nút thắt phổ biến và cách làm cho thiết kế cấp cao của bạn bớt trừu tượng hơn. Đây sẽ là trọng tâm của phần tiếp theo!

System DesignCareer Path
Bài Viết Liên Quan:
System Design: Bắt đầu từ đâu
Trung Nguyen 09/01/2021
System Design: Bắt đầu từ đâu

Trong bài viết này, chúng ta sẽ đi qua các bước để giải quyết từng vấn đề thiết kế. Hướng dẫn này có thể giúp bạn thiết kế một hệ thống.

System Design: Quy trình 4 bước thiết kế hệ thống
Trung Nguyen 09/01/2021
System Design: Quy trình 4 bước thiết kế hệ thống

Chúng tôi sẽ hướng dẫn bạn quy trình 4 bước để thiết kế hệ thống (System Design) và cung cấp một số thông tin để bạn thực hiện các ước tính cho hệ thống