Reliability & Scalability — Hai trụ cột đầu tiên của Data System (DDIA)
Mở đầu
Ảnh: ThisIsEngineering — Pexels
Cuốn Designing Data-Intensive Applications (DDIA) của Martin Kleppmann từ lâu đã được xem là "kinh thánh" cho dân backend engineer. Đây là cuốn sách gối đầu giường nếu bạn muốn hiểu sâu về cách xây dựng các hệ thống dữ liệu đáng tin cậy, có khả năng mở rộng và dễ bảo trì.
Mình mở series này để tóm lược từng chương của DDIA bằng tiếng Việt, giúp các bạn dev có thể nắm được những ý chính cốt lõi nhất. Bài đầu tiên hôm nay là về Chương 1 — nền tảng của mọi data system.
Cuốn sách này không phải kiểu dry technical lắm, mà nó kể chuyện về cách xây dựng những hệ thống dữ liệu lớn, đáng tin cậy và dễ bảo trì. Bài viết sẽ đi từng chương một, tóm gọn ý chính và luôn có glossary cùng key takeaways để dễ ôn tập.
Reliability & Scalability — Hai trụ cột đầu tiên
Ảnh: Pixabay — Pexels
Phần mở đầu của chương 1 nói về ba thứ quan trọng nhất khi xây dựng data-intensive application: Reliability (đáng tin cậy), Scalability (khả năng mở rộng), và Maintainability (dễ bảo trì). Bài này mình tập trung vào hai phần đầu: Reliability và Scalability.
Tác giả so sánh data system với Internet — cái mà mọi người nghĩ là tự nhiên như Thái Bình Dương, nhưng thực ra là do con người làm ra và nó chạy rất ổn. Ngày nay data-intensive app chủ yếu gặp vấn đề về data volume, complexity, và tốc độ thay đổi, chứ không phải CPU yếu.
Thay vì viết database hay cache từ đầu, chúng ta dùng những building block sẵn có (database, cache, search index, message queue, batch processing). Nhưng thực tế thì không đơn giản, vì mỗi tool có đặc điểm khác nhau, và khi ghép chúng lại thì phải tự code phần glue để chúng sync với nhau.
Kết quả là ta trở thành cả application developer lẫn data system designer. Và ba chữ Reliability, Scalability, Maintainability chính là kim chỉ nam.
Reliability
Hệ thống đáng tin cậy = tiếp tục hoạt động đúng ngay cả khi có fault. Fault có thể đến từ hardware (ổ cứng chết, mất điện), software (bug, leak memory), hoặc con người (config sai, operation nhầm).
Không thể tránh hoàn toàn fault, nhưng có thể thiết kế để giảm thiểu ảnh hưởng. Các kỹ thuật phổ biến: dùng replica (dự phòng), backup, và xây dựng hệ thống có khả năng recovery tự động.
Scalability
Khả năng xử lý load tăng mà không giảm performance. Tác giả nhấn mạnh rằng scaling không chỉ là thêm máy, mà còn là hiểu rõ load pattern của hệ thống.
Ví dụ điển hình: Twitter fan-out — khi một người nổi tiếng tweet, hàng trăm ngàn follower phải nhận được. Cách truyền thống (fan-out từng người) không scalable khi tài khoản lớn tweet quá nhiều. Giải pháp kết hợp giữa push (cho follower ít) và pull (cho follower nhiều).
Describing Performance
Phần này giới thiệu các đo lạc performance: throughput (số request/giây) và response time (thời gian trả lời). Điểm đáng chú ý là tầm quan trọng của percentiles — đặc biệt là p99 (tail latency). Một request chậm trong số hàng ngàn request có thể ảnh hưởng đến trải nghiệm người dùng nếu họ phải chờ response từ nhiều dịch vụ đồng thời (head-of-line blocking).
Một kỹ thuật phổ biến là shared-nothing architecture — mỗi node hoạt động độc lập, không chia sẻ tài nguyên. Điều này cho phép scale ngang (horizontal scaling) bằng cách thêm node khi cần.
Key Takeaways
Ảnh: Andrea Piacquadio — Pexels
- Reliability là phải chịu được fault mà không sụp — fault ở mọi tầng hardware, software, con người
- Scalability không chỉ là thêm máy mà là hiểu đúng load pattern
- Percentiles (p50, p95, p99) quan trọng hơn average khi đo performance
- Shared-nothing architecture = horizontal scaling qua independent nodes
- Twitter fan-out là ví dụ điển hình cho thiết kế scalable
Glossary
| Thuật ngữ | Ý nghĩa |
|---|---|
| Reliability | Khả năng hệ thống tiếp tục hoạt động đúng dù có fault xảy ra |
| Scalability | Khả năng hệ thống xử lý load tăng mà vẫn giữ performance tốt |
| Tail latency / p99 | 99th percentile response time — ảnh hưởng lớn đến UX |
| Fan-out | Khi 1 tweet phải deliver đến hàng triệu follower |
| Shared-nothing | Kiến trúc mỗi node độc lập, scale ngang bằng cách thêm node |
| Throughput | Số request / dữ liệu xử lý được trong một đơn vị thời gian |
| Head-of-line blocking | Một request chậm blocking các request khác trong hàng đợi |
Kết
Chương 1 này như là kim chỉ nam cho cả cuốn sách. Nó đặt nền tảng về ba mục tiêu lớn khi thiết kế data system — thứ mà các bạn backend engineer hay được hỏi trong system design interview. Analogy về Internet và Twitter fan-out rất dễ hình dung.
Phần sau sẽ đi sâu hơn vào Maintainability cũng như các khái niệm trong data models và query languages. Hẹn các bạn ở bài tiếp theo!
🔗 Đọc sách gốc: Designing Data-Intensive Applications