Retry-as-Recovery

Derived Failure Pattern của Temporal Assumptions và Hidden Side Effects

Summary

Retry-as-Recovery là Failure Pattern trong đó
retry trở thành de facto chiến lược duy nhất như một phương tiện khôi phục từ các thất bại,
và các giả định liên quan đến time, state, và side effects sụp đổ.

Điều mà Pattern này đề cập không phải là tính thích hợp của retry technology bản thân.
Trong một môi trường mà partial failures được bình thường hóa,
nó đề cập đến cấu trúc trong đó các quyết định "re-execute for now" tích lũy một cách hợp lý,
dẫn đến các trạng thái không thể khôi phục.

Context

Trong distributed systems và external API integration,
temporary failures là không thể tránh khỏi.

Network errors, timeouts, conflicts, v.v.
thường giải quyết nếu thời gian trôi qua,
và retry thường được áp dụng như một countermeasure hiệu quả.

Forces

Các động lực chính tạo ra Pattern này như sau:

Generalization of temporary failures
Bởi vì nhiều thất bại là tạm thời,
kỳ vọng rằng retrying sẽ thành công dễ dàng được hình thành.
Deferral of recovery design
Thay vì thiết kế các recovery strategies rõ ràng,
giới thiệu retry trông rẻ hơn trong ngắn hạn.
Invisibility of side effects
Tác động từ re-execution không nổi lên ngay lập tức,
và các vấn đề xuất hiện sau.
Unclear boundaries
Phạm vi có thể safely re-executed không được chia sẻ.

Failure Mode

Bằng cách sử dụng retry như một thay thế cho recovery,
các giả định liên quan đến time và state không còn được duy trì.

Kết quả là, các dạng hỏng sau đây tiến hành đồng thời:

Cùng một processing được thực hiện nhiều lần
Processing không được đảm bảo là idempotent được re-executed,
và data duplication hoặc inconsistency xảy ra.
Delays mở rộng side effects
Processing bị trì hoãn bởi retry,
và các state changes khác can thiệp trong thời gian đó.
Failure causes trở nên không rõ ràng
Thất bại ban đầu và outcome sau retry trộn lẫn,
làm cho problem isolation khó khăn.

Consequences

Double execution và duplicate processing xảy ra thường xuyên
(Part I: What Breaks — Time / State)
Non-reproducible failures tăng
(Part I: What Breaks — Time / Operation)
Recovery time trở nên không thể dự đoán
(Part II: Why It Breaks — Measurement Gap)
States của "succeeded but not sure if it was correct" tăng
(Part II: Why It Breaks — Context Erosion)

Countermeasures

Sau đây không phải là danh sách các giải pháp,
mà là các counter-patterns để thay đổi động lực với can thiệp tối thiểu chống lại Failure Mode.

Làm rõ ràng phạm vi có thể re-executed và
các boundaries không được re-executed
Định vị retry như một phần của recovery strategy,
và phân tách success conditions và failure conditions
Coi sự thật rằng retry xảy ra
như một event có thể học được

Resulting Context

Retry tiếp tục được sử dụng,
nhưng nó trở thành một chiến lược trong các tình huống hạn chế.

Recovery không phụ thuộc chỉ vào re-execution,
và được coi như một design decision xem xét state và side effects.

Kết quả là, các thất bại trở nên có thể kiểm soát,
và sự hiểu biết về time và state được khôi phục.

Appendix: Conceptual References

Information Hiding & Boundaries
Background của các cấu trúc trong đó, bởi vì boundaries của re-executability không được làm rõ ràng,
side effects rò rỉ qua các time axes.
Systems Thinking & Constraints
Background của các động lực trong đó local success (re-execution) cản trở overall recovery.
Feedback, Measurement & Learning
Background của các cấu trúc trong đó retry không được học và failure causes không được tích lũy.

Appendix: References

David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, 1972.
Fred Brooks, No Silver Bullet—Essence and Accidents of Software Engineering, 1987.
Donella H. Meadows, Thinking in Systems: A Primer, 2008.
W. Edwards Deming, Out of the Crisis, 1982.

Summary​

Context​

Forces​

Failure Mode​

Consequences​

Countermeasures​

Resulting Context​

See also​

Appendix: Conceptual References​

Appendix: References​