Tổng quan pattern

Vì sao học theo pattern

Đề phỏng vấn rất đa dạng, nhưng phần khó của chúng lặp lại. Bài đặt vé và bài flash sale khác sản phẩm nhưng cùng một vấn đề: nhiều người tranh một tài nguyên có hạn. Bài chat và bài live comments cùng cần đẩy dữ liệu tới client ngay khi có thay đổi.

Nắm bảy pattern dưới đây, bạn sẽ nhận ra phần lớn vấn đề cần đào sâu ngay khi đọc đề. Bước 5 trong Khung trả lời 45 phút gần như luôn rơi vào một hoặc hai pattern này.

Bảng tổng hợp

Scale đọc

Khi đọc nhiều hơn ghi rất nhiều, database chính trở thành nút thắt. Lời giải đi từ đơn giản tới phức tạp: index đúng, cache-aside với Redis, read replica, CDN cho nội dung tĩnh, rồi tính trước kết quả (như feed dựng sẵn). Phần khó là giữ cache đúng khi dữ liệu thay đổi và xử lý hot key: Grokking mô tả vấn đề hotkey trong cache phân tán và gợi ý chia nhỏ tiếp các key nóng.¹ Cache có các chính sách ghi (write-through, write-back, write-around),² và replica giúp tăng khả năng sẵn sàng và chia tải đọc.³ Thứ tự các bước giải trên là cách sắp xếp của khoá học. Chi tiết ở Scale đọc.

Scale ghi

Khi một primary không chịu nổi lượng ghi, bạn cần gom ghi theo lô, đưa qua queue để hấp thụ đỉnh, chia shard theo khoá, hoặc chuyển sang kho ghi tốt như Cassandra. Với dữ liệu đếm, có thể cộng dồn trước rồi mới ghi. Queue tách bên gửi và bên nhận để hấp thụ đỉnh tải,⁴ còn sharding chia dữ liệu theo khoá trên nhiều node.⁵ Chi tiết ở Scale ghi.

Tranh chấp tài nguyên

Hai người cùng bấm mua chiếc vé cuối cùng. Lời giải gồm khoá dòng trong database, optimistic locking bằng version, giữ chỗ có thời hạn trong Redis, và hàng đợi hoặc phòng chờ ảo khi lượng người tranh quá lớn. Chọn cách nào phụ thuộc mức độ tranh chấp và thời gian giữ. Optimistic locking bằng version được Microservices Patterns nhắc khi xử lý cập nhật đồng thời.⁶ Khoá dòng, giữ chỗ bằng Redis TTL và phòng chờ ảo là cách giải của khoá học, các bài chi tiết ghi nguồn cụ thể.⁷ Chi tiết ở Tranh chấp tài nguyên.

Cập nhật realtime

Client cần thấy thay đổi gần như ngay. Lựa chọn đi từ polling, long polling, Server-Sent Events tới WebSocket. Phía server cần pub/sub để chuyển tin giữa các gateway,⁸ và phải tính số kết nối mỗi máy. Grokking dùng WebSocket giữa client và server chat trong bài WhatsApp.⁹ Một gateway 2 vCPU · 4 GB giữ khoảng 20.000–50.000 kết nối ít hoạt động (ước lượng của khoá học, cần load test).⁷ Chi tiết ở Cập nhật realtime.

Tác vụ dài

Không bắt người dùng chờ request HTTP trong lúc encode video. Trả về ngay một job id, đưa việc vào queue, worker xử lý, client theo dõi trạng thái qua polling hoặc thông báo. Phần đáng nói: retry, idempotency, dead letter queue và scale worker theo độ dài hàng đợi. Grokking nêu task scheduler thử lại số lần cho phép khi task lỗi và yêu cầu task idempotent;¹⁰ hàng đợi cần xử lý tin trùng.¹¹ Chi tiết ở Tác vụ dài.

File lớn

File không đi qua API server. Client xin presigned URL rồi upload thẳng lên object storage, file lớn chia thành nhiều phần để upload lại từng phần khi lỗi. Phát lại qua CDN. Database chỉ lưu metadata. Blob store lưu file dạng đối tượng và chia thành các chunk phân bổ trên nhiều data node;¹² CDN đưa nội dung tới gần người dùng.¹³ Presigned URL là kỹ thuật của khoá học, chưa có sách trong thư viện mô tả.¹⁴ Chi tiết ở File lớn.

Quy trình nhiều bước

Khi một nghiệp vụ chạm nhiều service hoặc đối tác bên ngoài, không có transaction chung. Lời giải gồm outbox pattern, saga với bước bù trừ, và workflow engine như Temporal để giữ trạng thái và retry.¹⁵ Transactional outbox và saga đều có trong Microservices Patterns; riêng Temporal chưa có sách trong thư viện.¹⁶ Chi tiết ở Quy trình nhiều bước.