Retry Rita
“One retry count fits every business action.”
Can teams differ without operational anarchy?
Elevator answer
Yes. A price lookup may retry; a rejected payment should not; a regulatory filing may need a human. Let flows differ, but make every retry budget, terminal outcome, and owner visible.
3 coffee-machine misconceptions
Platform Priya
“Different means undocumented.”
Platform Priya
“Standardization means identical outcomes.”
The real explanation
Different actions have different consequences. A price lookup, a payment, and a regulatory submission should not have identical retry budgets or terminal behavior. A framework that forces one resilience policy everywhere turns business difference into technical debt.
TPF separates decisions about business outcomes from the runtime mechanics that execute them. Teams can declare appropriate behavior for supported flows while shared telemetry, stable identifiers, failure categories, and terminal ownership keep the result operable. Operators should see that policies differ and why, rather than reverse-engineering special cases from application code.
The risk is uncontrolled variation. If every team invents its own error names, retry semantics, and DLQ behavior, shared operations fragment. Guardrails should standardize the vocabulary and supported choices, not erase meaningful business differences.
Trade-offs
TPF gains bounded autonomy. It gives up one-size-fits-all policy.
When TPF is not a good fit
If an organization cannot agree on basic failure vocabulary or operational ownership, policy variation will become confusion rather than autonomy.