Bài viết này sẽ giúp anh em trả lời 3 câu hỏi:

• System Design là gì?
• Cần thu thập những thông tin gì để có thể bắt tay vào thiết kế?
• Một thiết kế như nào được cho là hiệu quả?

System Design là gì?

System Design (thiết kế hệ thống) là quá trình xác định được kiểu kiến trúc (architecture), thành phần (module), giao diện (interfaces) và dữ liệu (data) cho một hệ thống để đáp ứng được một tập yêu cầu cụ thể (specified requirements). Hồi trước mình bị bối rối khi không biết dùng từ Design hay Architect và đánh đồng nó là một. Trên lý thuyết, có sự khác biệt giữa 2 concepts này. Architect thường dùng để mô tả tổng quát (high-level) còn Design thưởng dùng để mô tả chi tiết (low-level). Ví dụ trong kiến trúc của một ngôi nhà, architect ám chỉ hình dạng, hướng nhà, kiểu thiết kế nhà cấp 4 hay nhà ống mái thái, … còn design chỉ ra vị trí đặt của cửa ra vào, cửa sổ, thậm chí là công tắc điện nằm ở đâu. Trên thực tế, những yếu tố nhỏ, chi tiết ảnh hưởng tới cái tổng thể. Ví dụ, thời tiết ở địa phương đó có thể ảnh hưởng đến quyết định chọn hướng nhà; địa chất, kiểu thiết kế nhà hàng xóm có thể ảnh hưởng tới kiểu thiết kế của ngôi nhà. Ngược lại, cái tổng thể sẽ quyết định tiểu tiết. Ví dụ, số lượng phòng ngủ của nhà cấp 4 và nhà ống là khác nhau, nội thất cũng sẽ được bố trí khác nhau do phụ thuộc vào diện tích phòng. Chốt lại, tổng quát high-level và chi tiết low-level đều là một phần của một thế kế hoàn thiện nên dùng từ Architect hay Design đều được 😂

Design bao gồm cả high-level và low-level nhưng nó tập trung vào chi tiết low-level như vậy anh em sẽ dễ dàng tiếp cận hơn là những cái trừu tượng high-level. Ví dụ anh em đều hiểu một bài nói về SQL antipatterns vì anh em đều đã học và làm việc với Relational DBMS rồi. Đó cũng là mong muốn của mình, nhóm có thể tiếp cận được với nhiều anh em ở nhiều level khác nhau.

Albert Einstein từng nói “Nếu tôi có 1 tiếng để giải quyết 1 vấn đề, tôi sẽ dành 55 phút để nghĩ về vấn đề và 5 phút để nghĩ về những giải pháp". Trước khi thiết kế, giải quyết vấn đề, anh em cần thu thập đủ thông tin đầu vào nhé. Vì nó sẽ giúp anh em không đi sai hướng, tìm giải pháp nhanh chóng và hiệu quả nhất.

Cần thu thập những thông tin gì để có thể bắt tay vào thiết kế?

• Functional Requirements (yêu cầu tính năng): anh em có thể hiểu nôm na, functional requirements xác định hành vi của hệ thống khi người dùng nhập đầu vào. Ví dụ, một yêu cầu tính năng là upload video trên Instagram, và followers có thể xem video đó. Với tình năng này có thể chia ra thành các loại yêu cầu như:
  • Input: chỉ chấp nhận định dạng video MOV (của iOS), MP4 (của Android)
  • Processing: xử lý ném video và lưu metadata độc lập, encoding video bất đồng bộ
  • Output: định dạng nén H.264
  • Interfaces: upload video bằng Multipart HTTP
  • Data: encoded Video được lưu ở đâu? Metadata thì lưu ở đâu?
• Constraints: về mặt authorization, chỉ followers mới quyền xem video của người đăng đó
• Stakeholder (các bên liên quan): Đầu tiên và quan trọng nhất anh em phải xác định được người dùng (user) và khách hàng (client) của hệ thống là ai? vì business lấy user và client làm trung tâm. Ngoài ra, khi anh em thay đổi 1 hệ thống đang chạy cần đánh giá ảnh hưởng và thông báo cho các bên liên quan.
• Scope, Timeline: Giới hạn vi phạm công việc. Anh em không thể design cho tất cả tính năng trong 45-60 phút khi phỏng vấn (format chung), mà chọn lấy những feature ăn điểm để trình bày. Hay làm startup không thể 1 năm trời không cho ra một sản phẩm gì.
• Existing System (hệ thống đang chạy): khi phải sửa một hệ thống cũ đang chạy, anh em cần nắm được SAD (System Architecture Diagram), interfaces, giao thức giữa các component và hệ thống bên ngoài. Đôi khi có những thành phần không thể thay thế, đó là ràng buộc (constraints) dẫn đến xảy ra đánh đổi (trade-off) khi chuyển giao (migrate) sang thiết kế mới. Anh em nhớ đánh giá kỹ ảnh hưởng (impact) nhé.
  Constraints (ràng buộc): Ngoài những ràng buộc của hệ thống cũ, chúng ta có thể có ràng buộc về tài nguyên như:
  • Tiền bạc (cost)
  • Thời gian (timeline)
  • Nhân lực (humans)
• Architecture Characteristics (non-functional requirements): dùng để mô tả tính chất hoặc chất lượng của một hệ thống.
  • Ví dụ: Khả năng hồi phục (recoverability) được thể hiện khi hệ thống gặp sự cố thì mất bao lâu để hệ thống quay trở lại phục vụ bình thường.
  • Anh em có thể đọc thêm chương 4, quyển Fundamentals of Software Architecture nhé
  • Nhiều trường hợp stakeholder (client) không hiểu khái niệm này hoặc cung cấp ko đầy đủ. Lúc đó anh em cần suy ra từ functional requirements và mong muốn của client.
  • Fun Fact: 2 ông Mark Richards và Neal Ford không thích dùng từ nonfunctional requirements. 2 ổng cho rằng nonfunctional requirements có ý nghĩa tiêu cực: team sẽ không tập trung và ko có thiện ý làm một cái gì đó trừu tượng, phi tính năng 😂
  • Chú ý:
    • Khi thêm hoặc thay đổi thứ tự các tính chất của hệ thống sẽ làm tăng độ phức tạp (complexity) hoặc thay đổi cường độ của các tính chất khác của hệ thống
    • Thứ tự và số lượng characteristics có thể thay đổi theo thời gian. Ví dụ, anh em có công ty startup thì cần đưa sản phẩm nhanh ra thị trường và cần tối ưu nguồn lực nên tính linh hoạt (agility) và tài nguyên (cost) được ưu tiêu. Khi công ty anh em lớn thành enterprise thì 2 yếu tố này không còn được đặt lên hàng đầu mà thay vào đó là khả năng mở rộng (scalability), tính bảo mật (security) và tính tin cậy (reliability)
• Metrics: tính chất hệ thống là một cái gì đó trừu tượng. Những chỉ số, thông số (metrics) dùng để lượng hóa và đánh giá tính chất của hệ thống. Anh em lưu ý số metrics sau:
  • Traffic
    • Queries Per Second (QPS)?
    • Lượng query ghi vào DB cao (high-write) hay lượng query đọc cao (high-read)?
  • Storage:
    • Lưu ở định dạng nào?
    • Lưu ở đâu?
    • Thời gian sống (retention) của dữ liệu là bao lâu?
  • CPU
  • Mem Usage
  • Metrics ảnh hướng tới quyết định chọn công nghệ

Thứ tự ưu tiên của functional requirements và non-functional requirements phụ thuộc vào scope, constraints. Thứ tự này thể hiện anh em hiểu rõ về business. Biết business cần gì sẽ giúp anh em dễ dàng đưa ra quyết định chọn 1 giải pháp (solution) thích hợp khi xảy ra trade-off (có nhiều giải pháp cùng lúc).

Thông tin đầu vào thì có rất nhiều nhưng thời gian cho việc thiết kế thì có hạn. Anh em cần chọn thu thập những thông tin quan trọng. Thông tin nào là quan trọng thì nó phụ thuộc vào từng hệ thống và phụ thuộc vào kinh nghiệm. Nhiều trường hợp gặp vấn đề khi thiết kế do thu thập sai hoặc thiếu thông tin đầu vào, anh em phải quay lại thu thập và đính chính lại thông tin đầu vào. Anh em lưu ý điều này nhé.

Để có thể bắt tay vào thiết kế, ngoài những thông tin trên, còn trước đó anh em cần trang bị kiến thức nền tảng tốt để phục vụ quá trình thiết kế và giải quyết những vấn đề khó về mặt kỹ thuật. Những kiến thức nền tảng mình sẽ chia sẻ ở 1 bài viết khác 📒

Một thiết kế như nào được cho là hiệu quả?

Một thiết kế được cho là hiệu quả khi đáp ứng các điều kiện sau:

Điều kiện cần:

• Đáp ứng đúng và đủ chức năng nghiệp vụ (functional requirements)
• Giảm thiểu nguồn lực dùng để xây dựng và bảo trì hệ thống. Đó là mục đích của một kiến trúc sạch (Clean Architect)

Điều kiện đủ:

• Đáp ứng đủ các tính chất của hệ thống (architecture characteristics) phù hợp với những ràng buộc hiện tại. Để làm được việc này anh em phải suy nghĩ thấu đáo để giải quyết triệt để các vấn đề từ phần cứng (hardware) cho đến phần mềm (software), dữ liệu được lưu trữ và di chuyển một cách tối ưu.

📚️ Ronin Engineer: https://ronin-engineer.github.io/register-post

🏢 System Design VN: https://fb.com/groups/systemdesign.vn

References:

• https://www.educative.io/blog/complete-guide-to-system-design
• Sách Fundamentals of Software Architecture - Mark Richards and Neal Ford
• Sách Clean Architecture - Robert C. Martin