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ô.