System DesignTrả lời theo thứ tự rẻ và nhanh trước, đừng nhảy thẳng vào phân tán:
1. Đo trước: xem CPU, RAM, disk I/O, số connection DB, latency p95. Chưa biết nghẽn ở đâu thì mọi thay đổi đều là đoán.
2. Sửa nút thắt hiển nhiên: query thiếu index, N+1, log đồng bộ, ảnh không nén. Một index đúng thường hạ tải nhiều hơn một con server mới.
3. Thêm cache: CDN cho tài nguyên tĩnh, cache kết quả đọc nóng. Rẻ nhất trên mỗi đơn vị tải giảm được.
4. Scale dọc: tăng CPU/RAM. Một lệnh đổi instance, không phải sửa kiến trúc — hợp lý cho tới khi chạm trần giá hoặc trần phần cứng.
5. Scale ngang: tách app thành nhiều instance sau load balancer. Điều kiện: app phải stateless (session đẩy ra Redis, file đẩy ra object storage).
6. Tách tầng dữ liệu: read replica cho đọc, rồi mới tính tới sharding.
Giới hạn từng hướng: scale dọc đơn giản nhưng vẫn còn một điểm hỏng duy nhất và trần phần cứng; scale ngang không có trần rõ ràng nhưng đẩy vấn đề sang nhất quán dữ liệu, session, connection pool và vận hành.