Lộ trình System Design: Từ yêu cầu đến kiến trúc tin cậy

System design là việc quyết định các phần của sản phẩm phối hợp thế nào dưới những ràng buộc thực tế. Mục tiêu không phải kiến trúc phức tạp nhất, mà là một thiết kế đáp ứng nhu cầu hôm nay và có đường phát triển hợp lý cho ngày mai.

Quy trình thiết kế có thể lặp lại

flowchart TD
  R[Làm rõ người dùng và yêu cầu chức năng] --> Q[Định nghĩa mục tiêu chất lượng]
  Q --> E[Ước lượng traffic, storage và ảnh hưởng khi lỗi]
  E --> H[Vẽ high-level design nhỏ nhất]
  H --> D[Chọn mô hình dữ liệu và giao tiếp]
  D --> F[Tìm bottleneck và failure mode]
  F --> T[Nêu trade-off và kiểm tra giả định]
  T --> H

1. Yêu cầu trước component

Với nền tảng học tập, yêu cầu chức năng có thể là đọc bài, tìm theo topic, đăng nhập và lưu tiến độ. Yêu cầu phi chức năng mô tả chất lượng như thời gian phản hồi, availability, privacy, accessibility, chi phí và thời gian recovery.

“Hệ thống phải scale” không đo được. “Hỗ trợ 10.000 người đọc mỗi ngày và 95% request bài viết hoàn thành dưới 300 ms” sẽ dẫn đường cho thiết kế và kiểm thử.

2. High-level design

High-level design mô tả các component lớn và luồng dữ liệu. Low-level design đi sâu vào module, interface, class và algorithm.

flowchart LR
  User[Người học] --> CDN[CDN / edge cache]
  CDN --> Web[Ứng dụng web]
  Web --> API[Progress API]
  API --> DB[(Relational database)]
  API --> Queue[Event queue]
  Queue --> Analytics[Analytics worker]

Hãy bắt đầu với modular monolith trừ khi nhu cầu deploy hoặc scale độc lập đã được chứng minh. Microservices có thể tách ownership và scaling nhưng thêm lỗi network, dữ liệu phân tán, gánh nặng vận hành và debugging khó hơn.

3. Scale, performance và reliability

Vertical scaling tăng tài nguyên cho một máy. Horizontal scaling thêm instance và cần phân phối traffic, thường qua load balancer. Request handler stateless dễ scale hơn vì instance khác có thể xử lý request tiếp theo.

Cache giảm công việc lặp nhưng tạo dữ liệu cũ và quy tắc invalidation. CDN cache nội dung gần người đọc. Database index tăng tốc query được chọn. Hãy đo thời gian đang nằm ở đâu trước khi thêm chúng.

Reliability hỏi hệ thống có tiếp tục làm đúng không. Availability hỏi hệ thống có truy cập được không. Fault tolerance mô tả cách hệ thống tiếp tục hoặc giảm chức năng khi component lỗi. Chúng liên quan nhưng không giống nhau.

4. Quyết định dữ liệu và giao tiếp

Dùng transaction khi các thay đổi phải cùng thành công hoặc cùng thất bại. Replication có thể tăng read capacity và availability. Partitioning và sharding chia dữ liệu nhưng làm query và vận hành phức tạp hơn.

Synchronous call trả kết quả ngay và dễ theo dấu. Queue và event tách các phần việc và hấp thụ tải tăng đột biến, nhưng cần idempotency, retry, quyết định về ordering và observability. Rate limiting bảo vệ tài nguyên hữu hạn và cần trả phản hồi rõ cho client.

5. Security và vận hành là một phần thiết kế

Thể hiện trust boundary và dữ liệu nhạy cảm trên sơ đồ. Quyết định authentication, authorization, mã hóa khi truyền, lưu secret, backup và recovery. Thêm log, metric và trace để trả lời lỗi gì, ảnh hưởng ai, ở đâu và từ khi nào.

Kiểm thử ở nhiều tầng: hành vi component, contract tích hợp, tải thực tế, phục hồi sau lỗi và chính deployment pipeline.

Một tài liệu thiết kế thực dụng

Giữ phiên bản đầu trong một trang:

1. Người dùng và ba use case chính.
2. Mục tiêu chất lượng đo được và giả định.
3. Sơ đồ component và data flow.
4. Data model chính và ví dụ API.
5. Hai bottleneck và failure mode có khả năng nhất.
6. Trade-off, câu hỏi mở và thử nghiệm tiếp theo.

Thiết kế tốt làm phần chưa chắc chắn trở nên rõ ràng; nó không giả vờ rằng mọi vấn đề tương lai đều đã được giải quyết.