Designing for scale: Transaction boundaries
Why this deserves attention
Cross-system work cannot rely on one database transaction to guarantee an all-or-nothing outcome. A sound design makes this explicit before implementation begins.
Designs that assume distributed rollback leave partial work and ambiguous customer status when one participant fails. On 10 September 2024, this archive entry records the principle as a practical design concern rather than a product announcement.
Scale is a design input
Look at transaction boundaries through how the decision behaves when volume, users and connected systems grow. The objective is not to introduce more process; it is to expose the few decisions that determine reliability, ownership and future change.
Define the local commit points, use explicit process state and design compensating actions for reversible steps. Record the decision close to the solution so that delivery, support and future architecture reviews work from the same intent.
What good looks like
The organisation can explain and recover every intermediate state in a long-running process. 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