System DesignTìm điểm nghẽn bằng cách đi ngược theo đường dữ liệu và so con số ước lượng ở bước 2 với giới hạn của từng thành phần:
- Một instance PostgreSQL gánh được cỡ vài nghìn ghi/giây trên phần cứng thông thường. Ước lượng cho ra 20k ghi/giây thì database là điểm nghẽn → phân mảnh, hoặc chuyển phần ghi nặng sang store phù hợp hơn.
- Đọc gấp 100 lần ghi → điểm nghẽn nằm ở đường đọc → cache và read replica.
- Payload lớn (ảnh, video) → điểm nghẽn là băng thông → object storage cộng CDN, upload trực tiếp bằng pre-signed URL để không đi qua service.
- Fan-out lớn khi ghi (người có hàng triệu người theo dõi) → điểm nghẽn ở thời điểm ghi → chuyển sang mô hình lai: fan-out khi ghi cho tài khoản thường, fan-out khi đọc cho tài khoản có lượng theo dõi rất lớn.
Trình bày đánh đổi theo một khuôn cố định, mỗi lựa chọn 3 câu:
1. Tôi chọn X.
2. Vì yêu cầu là Y (dẫn lại con số hoặc yêu cầu phi chức năng đã chốt ở đầu buổi).
3. Cái giá là Z, và tôi chấp nhận vì lý do W. Nếu yêu cầu đổi thành Y2 thì tôi sẽ chọn khác.
Ví dụ: "Tôi chọn eventual consistency cho số lượt thích. Vì yêu cầu chỉ nói hiển thị gần đúng và ưu tiên độ trễ thấp. Cái giá là người dùng có thể thấy số cũ vài giây; chấp nhận được vì đây không phải dữ liệu tài chính. Nếu đây là số dư ví thì tôi sẽ đọc từ primary."
Hai lỗi thường gặp: nói "tùy trường hợp" mà không chốt lựa chọn nào, và bảo vệ thiết kế bằng sở thích công nghệ thay vì bằng con số. Chủ động nêu hạn chế của chính thiết kế mình vừa vẽ được đánh giá cao hơn là chờ người phỏng vấn chỉ ra.