Cú gọi gốc có thể THÀNH CÔNG mà phản hồi không về được. Từ phía bên gọi, "chưa làm" và "làm rồi mà tôi không biết" trông y hệt nhau — nên retry có an toàn hay không là câu hỏi về bên nhận, không phải về cấu hình của bên gọi.
Broker chỉ bảo đảm cho message đã vào được nó. Khoảng trống nằm trước đó — giữa lúc database commit và lúc broker nhận — và không có tính năng nào của broker che được, vì lúc đó nó chưa biết message tồn tại.
Bù trừ không đưa hệ thống về trạng thái cũ — nó làm một việc nghiệp vụ mới để trung hoà việc đã làm. Và khôi phục trạng thái ban đầu có thể ghi đè lên thay đổi của người khác, tức là sinh ra một lỗi thứ hai tệ hơn lỗi đầu.
HTTP là giao thức đồng bộ, dù client có dùng async I/O — tài liệu Microsoft nói thẳng câu đó. Mỗi cú gọi đồng bộ là một sợi dây ràng buộc độ sẵn sàng, và phần lớn người ta ký sợi dây đó mà không biết mình đang ký.
Hai service không nên dùng chung một kho dữ liệu. Nhưng chỗ nhiều đội hiểu sai và bị chặn oan: dùng chung database server thì an toàn — chung schema hoặc chung bộ bảng mới là chỗ hỏng, vì đó là lúc bạn dùng chung lịch trình triển khai.
Câu hỏi không phải microservices hay monolith, mà là đã hiểu domain đủ để đặt ranh giới chưa. Bài này đi qua đủ tám thách thức mà Azure Architecture Center bảo phải cân nhắc trước khi chia, trong đó hai cái là điều kiện về người chứ không phải về kỹ thuật.
Chia service theo tầng controller / service / repository là chia sai, và tài liệu kiến trúc của Microsoft bác bỏ thẳng cách đó trong một câu. Bài này đi từ phân tích miền tới sáu tiêu chí kiểm ranh giới, kèm câu chốt mà ít người chịu nghe: khi còn ngờ thì chia thô.
Có index hẳn hoi trên đúng cột đang lọc, mà execution plan vẫn hiện Scan. Ba lý do phổ biến nhất: thứ tự cột đặt sai, câu truy vấn bọc hàm quanh cột, và index thiếu cột để trả về. Không phải optimizer dở.
Tắt parameter sniffing bằng trace flag 4136 là cách chữa dân DBA làm mười mấy năm nay. Nhưng tài liệu Microsoft ghi rõ: parameter sniffing bị tắt thì PSPO của bản 2022 cũng tắt theo. Băng cũ chặn mất thuốc mới. Bài này cũng đính chính chỗ tôi nói chưa đủ về optimized locking.
Ba bài trước tôi đều chốt bằng câu "mở execution plan ra mà đọc" mà chưa hề chỉ cách đọc. Bài này trả nợ — bắt đầu từ chỗ nhiều người hiểu sai nhất: Query Optimizer chỉ sinh ra một kế hoạch duy nhất.
Hai bản lớn cùng ra cuối 2025. SQL Server 2025 nhét AI vào trong engine; PostgreSQL 18 viết lại tầng I/O. So sánh này không kết luận cái nào hơn — nó chỉ ra hai bên trả lời khác nhau cho câu hỏi "database nên tự làm bao nhiêu".
Ba bản SQL Server trong sáu năm, mỗi bản một hướng khác nhau — 2019 đi vào truy vấn thông minh và dữ liệu lớn, 2022 đi ra đám mây, 2025 đi vào AI. Bài này điểm lại từng bản đổi gì, cái gì đã bị gỡ, và mốc hết hỗ trợ của từng bản.
Phân tích chi tiết source code TypeScript được trích xuất từ npm bundle của Claude Code v2.1.89 --- hé lộ hệ thống thú cưng ảo Buddy với rarity RPG ra mắt ngày 1/4/2026, kiến trúc UltraPlan multi-agent, Bridge remote session system, anti-canary obfuscation và hàng chục tính năng ẩn chưa được document.