Mục lục
System Design: Thiết kế hệ thống lớn
Năm 2023, một startup Việt mở rộng từ 100K users lên 5M users trong 6 tháng, và database của họ bắt đầu phản ứng như một người say rượu — chậm, không đoán được. Đó là lúc họ nhận ra rằng "viết code chạy được" với "thiết kế hệ thống chạy tốt ở quy mô lớn" là hai thứ hoàn toàn khác nhau.
System design không phải là lý thuyết trừu tượng. Nó là nghệ thuật đưa ra quyết định khó khi bạn biết rằng mỗi lựa chọn sẽ có cái giá, và không có câu trả lời "tuyệt đối đúng".
Tradeoff là bản chất của nó
Hầu hết mọi người khi bắt đầu học system design sẽ học về CAP theorem, khái niệm consistency-availability-partition tolerance. Nhưng cái chúng ta thực sự cần hiểu là: bạn không thể có cả ba, và lựa chọn của bạn phải tùy thuộc vào business problem cụ thể.
Lấy ví dụ: nếu bạn làm hệ thống thanh toán (như GrabPay hay Momo), bạn cần consistency cao — không thể để tiền biến mất hoặc bị tính hai lần. Nhưng nếu bạn làm system cho social media feed (như TikTok), người dùng có thể chấp nhận thấy feed lag 5 phút, miễn sao hệ thống luôn khả dụng.
Đó là lý do tại sao không có "best practice" chung. Có chỉ là "best practice cho use case này".
Cái cái được mọi người quên
Mọi bài viết về system design đều nói về load balancing, caching, database sharding. Nhưng chúng ta hiếm khi bàn về operational complexity — cách mà hệ thống phức tạp đến mức team của bạn không thể operate nó.
Tôi đã thấy một công ty bao gồm 15 microservices được orchestrate bởi Kubernetes, setup trên AWS, monitoring bằng DataDog, logs qua ELK stack. Một engineer viết một câu lệnh sai khi deploy, traffic routing đột ngột đổi hướng, và hơn 2 giờ sau, không ai hiểu chuyện gì đã xảy ra. Họ tốn hơn $200K để fix sự cố này. Nếu hệ thống còn đơn giản hơn một chút, họ có thể debug trong 15 phút.
Complexity là debt. Và nó phải được repay với operational cost.
Caching: món quà của quỷ
Chia sẻ bài viết


