System Design — Bài 2: Làm rõ yêu cầu: từ chức năng đến mục tiêu đo được
Câu “thiết kế một ứng dụng đặt phòng” chưa cho biết cần giải bài toán tìm kiếm, giữ phòng hay thanh toán. Nếu vẽ ngay, bạn có thể tối ưu phần không quan trọng và bỏ sót lỗi hai khách cùng đặt một phòng. Bài này xây một hợp đồng yêu cầu đủ rõ để dẫn dắt phần thiết kế.
Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 2.
Problem là gì?
Vấn đề là khoảng cách giữa điều đang xảy ra và điều stakeholder mong muốn. Cần chú ý chữ “được nhận thức”: đôi khi chúng ta chỉ nghĩ hệ thống chậm nhưng chưa đo, hoặc nghĩ khách cần thêm tính năng trong khi họ muốn thao tác cũ đơn giản hơn.
Ví dụ, đội kinh doanh nói khách bỏ giỏ vì thanh toán chậm. Ta cần biết bước nào chậm, bao nhiêu khách bị ảnh hưởng và tốc độ mong muốn. Đồng thời khảo sát thực tại: hệ thống hiện có, đội vận hành, ngân sách và thời hạn. Nếu chỉ có hai tuần, phương án thay toàn bộ nền tảng có thể không phù hợp dù đẹp về kỹ thuật.
Hãy ghi rõ điều nào đã có số liệu, điều nào là nhận định và điều nào đang giả định. Như vậy khi thông tin thay đổi, ta biết quyết định nào cần xem lại.
Functional requirements — hỏi cho đủ ba mảnh
Một yêu cầu chức năng nên trả lời ba câu: ai làm, làm gì và làm với đối tượng nào. “Có đặt lịch” còn mơ hồ. “Bệnh nhân chọn khung giờ trống để đặt một cuộc hẹn với bác sĩ” đã rõ hơn nhiều và gợi ra dữ liệu cần lưu.
Trong phỏng vấn ngắn, thường nên thống nhất khoảng ba chức năng lõi để còn thời gian đào sâu. Đây là cách quản lý phạm vi, không phải quy tắc rằng hệ thống chỉ được có ba yêu cầu. Với đặt phòng, có thể ưu tiên tìm nơi ở, xem tình trạng phòng và đặt phòng; tính năng đánh giá để ngoài phạm vi trước.
Sau đó hỏi cách sử dụng: tìm theo thành phố hay bản đồ, xem một ngày hay khoảng ngày, một người có được giữ nhiều phòng không? Những câu trả lời này sẽ trở thành access pattern cho database.
Non-functional requirements — ba nhóm câu hỏi
Yêu cầu phi chức năng mô tả chất lượng và ràng buộc. Ta bắt đầu bằng tải: tổng số người dùng, số hoạt động hằng ngày và tần suất thao tác. Tiếp theo là throughput: bao nhiêu request hoặc giao dịch trong một giây, đặc biệt vào giờ cao điểm. Cuối cùng là lưu trữ: mỗi bản ghi lớn cỡ nào, giữ bao lâu và tăng trưởng ra sao.
Ví dụ, 1 triệu tài khoản không có nghĩa 1 triệu người truy cập đồng thời. Mười nghìn người hoạt động, mỗi người đọc mười lần một ngày, tạo ra bài toán khác hoàn toàn với 10.000 kết nối liên tục gửi dữ liệu.
Ngoài tải, cần hỏi mức chấp nhận lỗi, độ trễ, bảo mật, khả năng bảo trì và mất dữ liệu. Thay “phải ổn định” bằng tình huống cụ thể: nếu một máy chết, giao dịch đã báo thành công có được phép mất không?
NFR nào quan trọng nhất?
Để chọn ưu tiên, hãy hỏi hai câu: điều gì làm hỏng trải nghiệm và điều gì gây thiệt hại lớn nhất cho nghiệp vụ? Bảng tin có thể chấp nhận một lượt thích hiện trễ. Ví điện tử không được biến một lần gửi lại request thành hai lần trừ tiền.
Thứ tự ưu tiên phải xuất phát từ hậu quả của từng loại lỗi, không có bảng xếp hạng phổ quát. Với hệ tài chính, tính đúng đắn và bảo mật là ràng buộc cốt lõi. Với một trang nội dung trong chiến dịch lớn, khả năng phục vụ khi tăng tải có thể là điểm cần tập trung nhất. Ngay trong một sản phẩm, đăng nhập, tìm kiếm và thanh toán cũng có thể cần mức bảo đảm khác nhau.
Khi các mục tiêu xung đột, phải nói rõ ưu tiên theo từng luồng. Đó là căn cứ để quyết định lúc nào trả dữ liệu cũ, lúc nào chờ, và lúc nào từ chối yêu cầu.
Thực hành đặt yêu cầu cho ba sản phẩm
Hãy tạm dừng và viết yêu cầu cho ba bài. Với ứng dụng hẹn hò, mô tả chức năng theo actor, activity và object. Một đáp án có thể là người dùng tạo hồ sơ, duyệt hồ sơ phù hợp và nhắn tin sau khi hai bên kết nối. Cần chốt điều kiện được nhắn tin, vì nó ảnh hưởng kiểm tra quyền.
Với giao đồ ăn, thử nêu chất lượng dưới tình huống giờ trưa đông khách: tìm tài xế đủ nhanh, vị trí tương đối mới và đơn hàng không bị giao cho hai người. Với sàn giao dịch giả định, phân biệt dữ liệu giá hiển thị với lệnh giao dịch đã được nhận; hai luồng có yêu cầu khác nhau về độ trễ và tính đúng đắn.
Không chấm bằng số thuật ngữ bạn viết. Hãy gắn mỗi yêu cầu với một hậu quả nếu vi phạm và một cách kiểm chứng. “Nhanh” phải đi cùng thao tác nào và đo tại đâu.
Một bản yêu cầu có thể kiểm chứng
FR: Khách tìm phòng theo thành phố và khoảng ngày.
FR: Khách giữ một phòng trong thời hạn xác định.
FR: Khách xác nhận đặt phòng bằng mã giữ chỗ.
NFR minh họa:
- Tìm kiếm: p95 <= 300 ms tại 2.000 request/s.
- Xác nhận: không có hai booking hợp lệ cho cùng phòng/đêm.
- Chỉ báo thành công sau khi dữ liệu đã lưu bền.
Cần chốt: thời hạn giữ chỗ, hủy đơn, mất mạng, vùng phục vụ.Các mức tải và độ trễ là giả định để luyện. Hãy thêm cách đo và cửa sổ quan sát; riêng bất biến chống đặt trùng cần được giữ tại nơi xác nhận giao dịch, kể cả khi hai request tới đồng thờ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.
DAU — Daily Active Users: Số người dùng hoạt động trong một ngày theo định nghĩa của sản phẩm; nhân với số hành động mỗi người để ước lượng tổng request/ngày.
SLO — Service Level Objective: Mục tiêu mức dịch vụ, ví dụ 99,9% request thành công hoặc 99% request dưới 250 ms trong cửa sổ đo xác định.
Bài tập tự thực hành
Viết ba FR và ba NFR cho đặt phòng.
Gợi ý kiểm tra lời giải
FR có actor–activity–object; NFR có thao tác, mục tiêu đo và giả định tải; phát hiện chống đặt trùng.
Tự kiểm tra sau bài học
FR chỉ rõ ai làm gì với đối tượng nào.
NFR có thao tác, mức tải và tiêu chí kiểm chứng.
Ưu tiên chất lượng được xác định riêng cho đọc, ghi và thanh toán.
Tiếp tục lộ trình
Bài trước — System Design là gì? Cách đánh giá một thiết kế
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.