System Design — Bài 1: System Design là gì? Cách đánh giá một thiết kế
Một ứng dụng bán hàng cho 100 khách mỗi ngày và một hệ thống cho hàng triệu người có thể có cùng nút đặt hàng. Khác biệt nằm ở tải, mức chấp nhận lỗi, ngân sách và cách tổ chức dữ liệu. System Design giúp bạn biến những ràng buộc đó thành các quyết định có thể giải thích và kiểm chứng.
Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 1.
System Design là gì?
System Design kết hợp hai việc: hiểu vấn đề cần giải và sử dụng kiến thức máy tính để tổ chức một lời giải. Nếu chỉ biết công nghệ, chúng ta có thể dựng một hệ thống rất cầu kỳ cho nhu cầu nhỏ. Nếu chỉ hiểu nghiệp vụ nhưng thiếu nền tảng, chúng ta khó biết giải pháp có chịu được tải hay không.
Ví dụ, cửa hàng nhỏ có thể dùng một ứng dụng và một database. Khi lưu lượng tăng, ta đo xem chậm ở truy vấn, xử lý hay mạng rồi mới chọn cache, replica hoặc hàng đợi. Cùng một đề có thể có nhiều phương án hợp lý vì ngân sách, đội ngũ và mức chấp nhận lỗi khác nhau.
Một cách bảo vệ lựa chọn rõ ràng là: “Em chọn cách này vì yêu cầu này, và chấp nhận chi phí này.” Kỹ năng lập trình vẫn rất quan trọng; thiết kế bổ sung góc nhìn toàn hệ thống để code chạy đúng trong môi trường thật.
Architecture vs Design — chiến lược và chiến thuật
Architecture là những quyết định có phạm vi rộng: chia hệ thống thành phần nào, ai sở hữu dữ liệu, giao tiếp đồng bộ hay bất đồng bộ, và hệ thống đạt chất lượng mong muốn bằng cách nào. Design đi sâu hơn vào cách hiện thực một chức năng trong bức tranh đó.
Ví dụ, quyết định tách phần thanh toán khỏi phần gửi email thuộc mức kiến trúc. Còn chọn trạng thái cho một payment, cách kiểm tra request trùng và câu lệnh cập nhật số dư thuộc mức chi tiết hơn. Ranh giới không tuyệt đối: nếu cách khóa dữ liệu khiến mọi giao dịch bị tuần tự hóa, chi tiết đó có thể buộc chúng ta đổi kiến trúc.
Vì vậy, đừng xem hai khái niệm là hai giai đoạn tách rời. Chúng là các mức phóng to khác nhau của cùng một quá trình ra quyết định.
Bản đồ kiến thức — học gì trước, học gì sau
Trong bản đồ kiến thức, tầng System Design nói về cách tổ chức hệ thống và giải quyết vấn đề. Tầng advanced backend cung cấp công cụ như database, cache, cloud và pipeline triển khai. Tầng nền tảng giải thích vì sao các công cụ đó hoạt động: mạng, hệ điều hành, thuật toán và kiến trúc máy tính.
Bạn không cần học xong mọi kiến thức nền rồi mới được thiết kế. Chúng ta bắt đầu bằng những thành phần hay gặp, sau đó đào xuống khi cần giải thích. Chẳng hạn, thấy cache nhanh thì hỏi tiếp: vì sao truy cập bộ nhớ thường rẻ hơn truy cập ổ đĩa, và vì sao thêm một vòng mạng có thể làm remote cache chậm hơn mong đợi?
Học theo cách này giúp kiến thức có điểm bám. Mỗi lần gặp một giới hạn, bạn biết mình đang thiếu hiểu biết ở tầng nào.
Bốn bước thiết kế — khung của cả khóa
Bước một là hiểu bài toán: người dùng nào, chức năng nào, điều gì nằm ngoài phạm vi. Bước hai là ước lượng để biết quy mô. Bước ba dựng thiết kế tổng thể, bắt đầu từ giao diện chức năng, mô hình dữ liệu rồi mới nối các thành phần. Bước bốn chọn những điểm khó nhất để đào sâu.
Ví dụ với dịch vụ rút gọn đường dẫn, ta chốt hai thao tác tạo mã và chuyển hướng. Sau khi biết đọc nhiều hơn ghi, ta thiết kế đường đọc ngắn và cân nhắc cache. Đến phần đào sâu mới xử lý sinh mã không trùng và request tạo đồng thời.
Các bước có thứ tự nhưng cho phép quay lại. Nếu phát hiện yêu cầu mã khó đoán không phù hợp với cách cấp số tuần tự, ta sửa lựa chọn trước đó và giải thích lý do. Đây là quá trình kiểm chứng thiết kế, không phải điền một mẫu cố định.
Đánh giá một thiết kế khi chưa viết dòng code nào
Trước hết, thiết kế phải giải đúng chức năng và mức chất lượng đã chốt, nằm trong khả năng chi trả và vận hành của đội. Sơ đồ đẹp nhưng không biết phục hồi sau lỗi hoặc vượt ngân sách thì chưa đáp ứng bài toán.
Tiếp theo là bằng chứng. Nếu chọn B+Tree cho truy vấn khoảng, hãy giải thích rằng ta tìm điểm bắt đầu qua cây rồi đọc tiếp các phần tử có thứ tự. Với mô hình đơn giản, chi phí là tìm kiếm cộng số kết quả cần trả, thường biểu diễn thành O(log N + M). Nhưng thời gian thực tế còn phụ thuộc dữ liệu nằm trên bao nhiêu trang và có trong bộ nhớ hay chưa.
Lập luận này mạnh hơn câu “nhiều công ty dùng”. Tuy vậy, phân tích trên giấy chưa chứng minh mọi đặc tính production; những giả định quan trọng vẫn cần prototype, đo tải và kiểm thử lỗi. Điều cần giữ là hiểu vấn đề trước khi chọn giải pháp.
Bắt đầu từ một đường đặt hàng đơn giản
Khách -> API đặt hàng -> Transaction trong DB
|
+-> Order + thay đổi tồn + Outbox
|
Worker gửi email
Báo thành công khi giao dịch đã commit.
Email có thể gửi sau; lỗi email không làm mất đơn đã ghi.Với cửa hàng nhỏ, các vai trò trên có thể cùng một ứng dụng. Outbox chỉ cần khi yêu cầu gửi thông báo đáng tin cậy đòi hỏi xử lý cả crash sau commit. Mỗi thành phần phải gắn với một yêu cầu cụ thể và một tình huống lỗi.
Thuật ngữ cần nhớ
FR — Functional Requirements: Yêu cầu chức năng: hệ thống phải làm được gì cho ai, ví dụ tạo liên kết ngắn hoặc chuyển tiền.
NFR — Non-functional Requirements: Yêu cầu phi chức năng: mức chất lượng và ràng buộc, ví dụ độ trễ, khả dụng, bảo mật và quy mô tải; cần diễn đạt bằng tiêu chí đo được.
API — Application Programming Interface: Giao diện lập trình ứng dụng: hợp đồng để thành phần khác gọi chức năng, gồm đầu vào, đầu ra và quy tắc lỗi.
Bài tập tự thực hành
Vẽ cửa hàng một trăm khách/ngày và giải thích từng thành phần.
Gợi ý kiểm tra lời giải
Có chức năng, ràng buộc và lý do; không thêm hệ phân tán khi chưa có nhu cầu.
Tự kiểm tra sau bài học
Giải thích được lý do tồn tại của từng thành phần.
Nêu ít nhất một phương án đơn giản hơn và điều kiện nó đáp ứng được.
Chỉ ra giả định nào cần đo tải hoặc thử lỗi để xác nhận.
Tiếp tục lộ trình
Bài tiếp — Làm rõ yêu cầu: từ chức năng đến mục tiêu đo được
Site Admin
Engineer and writer. Building things with TypeScript and distributed systems.
Bình luận (0)
Bạn cần đăng nhập bằng Google để bình luận.
Hãy là người bình luận đầu tiên.