Containing technical debt: Error recovery
Why this deserves attention
Failure handling is part of the business process, not a technical appendix added after the happy path. This becomes more valuable as the platform, team and integration estate grow.
Without durable error state, teams rely on log searches and manual reconstruction to discover what the customer experienced. On 25 July 2025, this archive entry records the principle as a practical design concern rather than a product announcement.
Make the compromise visible
Look at error recovery through how to prevent a short-term compromise from becoming permanent architecture. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.
Classify retryable and terminal failures, preserve context, and provide a controlled replay or compensation path. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.
What good looks like
Operations can restore service confidently without creating duplicates or hiding unresolved work. The team can describe the expected behaviour, the owner, the evidence of success and the response when reality differs from the design.
A useful next step is to review one live implementation against this principle, identify the largest unowned assumption and turn it into a bounded improvement with a measurable outcome.
Official reference
Salesforce Architecture: Integration Patterns