Part 09 · Distributed Systems

15 tình huống failure xuyên nhiều service

Luôn phân loại outcome, xác định service owner và nói hệ thống hội tụ thế nào sau retry/crash/duplicate.

1. Order gọi Inventory và nhận connection refused?
Nếu request chắc chắn chưa gửi, bounded retry/circuit breaker hoặc giữ Order pending. Không retry business failure; bảo vệ pool bằng bulkhead.
2. Inventory timeout nhưng thực tế đã reserve?
Unknown outcome. Retry/query cùng reservation ID; unique key trả outcome cũ. Không tạo reservation mới.
3. Inventory reserve thành công, Order crash trước lưu result?
Inventory event redelivery hoặc orchestrator query/reconcile. Reservation TTL là safety net; Inbox/transition idempotency ngăn apply lặp.
4. Order lưu INVENTORY_RESERVED nhưng command Payment chưa publish?
State và next command phải ghi cùng Outbox transaction. Relay publish sau restart; monitor oldest unpublished age.
5. Payment declined sau khi stock reserved?
Saga chuyển CANCELLING và gửi ReleaseInventory. Chỉ terminal CANCELLED khi policy cleanup đạt yêu cầu.
6. Release Inventory thất bại ba lần?
Persist COMPENSATION_PENDING, retry backoff cùng ID, alert backlog và operator path. Compensation failure không được che.
7. Payment authorize timeout sau khi provider charge/hold?
Giữ PAYMENT_UNKNOWN, query provider theo operation ID, không authorize lại bằng key mới. Reconcile/manual review nếu provider không xác nhận.
8. Order confirmed nhưng Inventory confirm nhận reservation expired?
Đây là race/design deadline. Fencing/version transition; forward recovery nếu stock còn, nếu không cancel/void/refund và manual review.
9. Payment captured nhưng Fulfillment down 2 giờ?
Queue durable và retry theo fulfillment SLA; không nhất thiết refund ngay. Expose fulfillment pending, alert backlog age và có cancellation policy.
10. Event PaymentAuthorized đến sau OrderCancelled?
Aggregate version/state guard bỏ stale transition và audit. Có thể cần void authorization như cleanup, nhưng không confirm Order lại.
11. Broker giao InventoryReserved hai lần?
Inbox/unique event ID cùng transaction với state effect; duplicate trở thành no-op. Exactly-once claim không cần thiết.
12. Circuit breaker mở, fallback nên trả Order confirmed?
Không. Fallback phải trung thực: pending/unavailable/rejected tùy contract. Circuit chỉ bảo vệ capacity, không chứng minh downstream outcome.
13. Retry tại Gateway, Order và Inventory mỗi tầng ba lần?
Worst-case amplification nhân nhau. Chọn một retry owner, propagate deadline, jitter và retry budget.
14. Reservation TTL worker expire đúng lúc confirm?
Atomic state transition/version hoặc row lock quyết định một winner. Confirm/expire không được cùng thành công; event/result phản ánh transition thực.
15. Reconciliation thấy payment CAPTURED nhưng Order PAYMENT_PENDING?
Xác minh identity/version, idempotently apply missing transition hoặc đưa manual review. Không capture/refund lại trước khi hiểu source of truth.

Follow-up chung