Make the handoff explicit.
Connect systems with clear ownership, useful validation, and defined behavior when a request is delayed or repeated.
A useful place to start.
A short reading path
- 01Define the boundary before building an integration
Agree which system owns the record and its state.
- 02Design a CSV import people can trust
Validate and preview data before applying changes.
- 03Make form submissions safe to retry
Define what a repeated operation means.
Explore the topic.
Define the boundary before building an integrationConnecting two systems requires more than moving fields. The teams need to agree which system owns each fact, when changes become visible, and who resolves disagreements.Design a CSV import people can trustA CSV file can look simple while carrying ambiguous dates, missing identifiers, and inconsistent categories. A useful import workflow makes those issues visible before they become application data.Make data exports useful outside the applicationAn export is a product interface used by another person or system. Its value depends on whether the recipient can understand the fields, reproduce the selection, and safely interpret the result.Make form submissions safe to retryA browser can lose the response to a request that the server already processed. Retrying should help the person recover confidence without creating another order, inquiry, or job unintentionally.Decide how incoming webhooks become application workA webhook delivers information from another system, but delivery and business processing are separate concerns. Define that boundary before using incoming events to change important records.Reconcile systems instead of assuming synchronization workedA synchronization process can report successful requests while the two systems still disagree. Reconciliation asks a different question: do the records now satisfy the relationship the workflow requires?Design an API around a business operationAn API should give its callers a clear contract for accomplishing work. Exposing every internal table directly can make that contract difficult to evolve and easy to misuse.Plan for a supplier’s rate limitsAn external service sets a boundary on how much work your application can request. The design needs to account for that boundary during normal operation, spikes, and recovery from an outage.Separate uploading a file from processing itA successful upload means the bytes arrived, not necessarily that the file is usable. Model those stages separately so people understand what the system has accepted and what remains to happen.Rehearse a data migration before the cutoverA migration rehearsal tests the procedure as well as the transformation. It should help the team understand the time required, the exceptions to resolve, and the evidence needed before switching users over.
Put it to work
Software and integrations
Connect the guidance to the application or systems you need to build or improve.
Explore the service ↗Engineering context
PostgreSQL continuations
Read how compiler-hidden continuations support database waits in Gray, with the paper’s stated design and limitations.
Read the technical work ↗