Bài viết về: Backend
OFFSET 100000 trông vô hại, nhưng database vẫn phải tìm và bỏ qua một lượng lớn record trước khi trả vài chục dòng. Trong lúc người dùng chuyển trang, dữ liệu mới còn có thể được chèn vào đầu danh sách, khiến một item xuất hiện hai lần hoặc biến mất khỏi hành trình đọc.
Đọc tiếp →
API vẫn trả HTTP 200, nhưng frontend đột nhiên lỗi vì một field biến mất, đổi kiểu hoặc trở thành null. Unit test của backend có thể vẫn xanh, tài liệu Swagger vẫn mở được, nhưng hợp đồng mà consumer đang dựa vào đã bị phá vỡ.
Đọc tiếp →
Feature flag tách thời điểm deploy code khỏi thời điểm phát hành tính năng. Nhóm phát triển có thể đưa code lên production ở trạng thái tắt, mở cho nhân viên, tăng dần tỷ lệ người dùng và tắt nhanh khi có sự cố mà không cần build lại. Nhưng nếu thiếu vòng đời, flag sẽ trở thành cấu hình sống vĩnh viễn và làm mọi nhánh code khó hiểu hơn.
Đọc tiếp →
Access token ngắn hạn giảm thời gian kẻ tấn công có thể sử dụng token bị lộ, nhưng refresh token lại là thông tin đăng nhập dài hạn có khả năng tạo access token mới. Nếu backend chấp nhận một refresh token nhiều lần, bản sao bị đánh cắp có thể duy trì phiên gần như âm thầm. Refresh token rotation giải quyết vấn đề bằng cách thay token sau mỗi lần sử dụng và phát hiện token cũ bị phát lại.
Đọc tiếp →
Client gửi yêu cầu tạo đơn hàng, server xử lý thành công nhưng response bị mất trên đường truyền. Client chỉ thấy timeout và gửi lại. Nếu API tạo thêm một order hoặc charge thẻ lần hai, lỗi nằm ở thiết kế server chứ không phải ở hành vi retry hợp lý của client.
Đọc tiếp →
Rate limiting không chỉ để chặn bot. Nó bảo vệ database và dịch vụ phụ thuộc khỏi traffic burst, phân chia tài nguyên công bằng giữa tenant, kiểm soát chi phí API và giúp hệ thống suy giảm có kiểm soát khi quá tải. Một limiter thiết kế sai lại có thể khóa nhầm hàng nghìn người dùng sau NAT hoặc trở thành điểm lỗi mới.
Đọc tiếp →
Một request tạo đơn hàng thường phải làm hai việc: lưu đơn vào database và phát sự kiện OrderCreated sang message broker. Nếu commit database trước rồi publish thất bại, hệ thống có đơn hàng nhưng kho hoặc email không biết. Nếu publish trước rồi transaction rollback, consumer lại xử lý một đơn không tồn tại. Đây là bài toán dual write.
Đọc tiếp →
Một câu ALTER TABLE chạy thành công chưa có nghĩa là deployment an toàn. Trong production, phiên bản ứng dụng cũ và mới thường cùng tồn tại trong vài phút hoặc lâu hơn. Một migration khóa bảng, đổi tên cột ngay lập tức hoặc backfill hàng triệu bản ghi trong một transaction có thể làm request chậm, cạn connection pool và khiến rollback trở nên bất khả thi.
Đọc tiếp →
Transaction không chỉ là bọc nhiều câu SQL trong BEGIN và COMMIT. Khi nhiều request cùng đọc và sửa dữ liệu, ứng dụng phải chọn isolation level phù hợp, khóa đúng hàng, giữ transaction ngắn và chuẩn bị retry các lỗi concurrency có chủ đích.
Đọc tiếp →
Cache có thể giảm latency và tải database rất mạnh, nhưng cũng có thể trả dữ liệu cũ, che lỗi và tạo một đợt truy vấn đồng thời khi key hết hạn. Thiết kế cache production cần xác định nguồn dữ liệu chuẩn, mức độ stale chấp nhận được, cách invalidation và hành vi của ứng dụng khi Redis không khả dụng.
Đọc tiếp →