The proposed arrangement
This fictional proposal, TD-D1 (Runtime arrangement), follows the later software design. The initial business trial remains process-only. Nothing described here has been deployed and the checks are unrun.
For evaluation, group the case-service components into one application release, with a durable transactional store. The notification relay may run as a worker from that release. Packaging it this way keeps the transfer rule and application change together; worker scheduling and instance count remain open.
| Element | Required behaviour | Choice still open |
|---|---|---|
| Browser or mobile client | Show pending work separately from service acceptance; retain the operation identifier (X7 (Acceptance operation)) after a lost response. |
Supported clients, protected local storage and update policy. |
| Case-service execution | Check authority and the expected case version; preserve the accepted transfer and its receipt as required by SI-C01 (Transfer acceptance contract) and SW-R1 (Transfer rule). | Language/runtime, hosting, instance count and failure isolation. |
| Transaction store | Commit assignment, history, accepted offer, X7 result and pending notification together under the expected version. | Storage product, durability configuration and supported restore procedure. |
| Notification worker | Resume committed pending work; handle repeated delivery. | Scheduling, retry limits and delivery-progress retention. |
| Service dependencies | Booking remains separately authoritative; identity and optional summary generation have explicit contracts. | Suppliers, summary placement, limits, permitted data, access and support arrangements. |
| Recovery copies | Restore a mutually consistent set of case and operation records. | Copy protection, location, retention, recovery time and acceptable loss. |
The diagram shows these responsibilities and selected connections. A physical view would add actual products, environments, network paths and configuration.
Access and capacity
Only the case service writes accepted case records. Give the worker the access needed for notification work; a summary step has no ownership-changing tool. Separate deployment permissions from normal service permissions, and test credential rotation and emergency access. Record which team supports the application, data store, network and identity service.
Measure a representative acceptance path with concurrent callers, pending notifications and ordinary case reads. Include supplier delay and a reconnecting client resubmitting work. Agree demand, latency and queue-age targets with the service owner; no numbers are assumed here. Keep optional summary work separate from acceptance capacity so staff can still review and transfer the case when the summary provider is slow and the other dependencies are healthy.
Restart and lost response
In the systems example, operation X7
accepts offer H7 (Example transfer offer) for case C42 (Example cancellation case), advancing version 12 to 13. The response
may be lost after the commit. Restarting the application must preserve the
case update, operation result and pending notification in the durable store.
An authorised identical repeat returns the retained result without another
transfer. A later owner change does not rewrite that historical receipt.
A storage candidate qualifies only if the required commit and restart behaviour are demonstrated in its actual configuration. The result-retention period must cover the agreed client retry and reconciliation process. Until an unknown outcome is resolved, the client keeps the operation identity and shows uncertainty.
Restoring older data
Proposal TD-R1 (Recovery procedure) treats a disaster restore separately from a process restart.
A backup made before X7 may restore version 12, although X7 had already
committed version 13 and a notification may have been delivered. A consistent
old copy can therefore still disagree with real events.
Pause acceptance writes and notification delivery, and prevent an old service
instance from continuing to write. Restore into a controlled environment and
identify the recovery point. Check case state, assignment history, operation
results and pending work as a set. Reconcile any interval of missing records
against available durable records and authorised business review before resuming.
Do not turn an absent X7 in the restored copy into permission to repeat it.
If accepted transfers must survive a wider failure than the proposed store can tolerate, strengthen the storage/recovery arrangement before adoption. If some recent loss is accepted, define how affected ownership is established and who authorises resumption. Recovery objectives, the source of reconciliation records and the exact procedure remain open decisions.
The service owner accepts the reconciled operating position; the technical operator restores and checks the platform. Include credential/key recovery, version compatibility, client resynchronisation and duplicate notification handling in the exercise. An old copy does not prove that an earlier message was never delivered. Booking confirmation remains a separate external fact.
Releasing a change
Proposal TD-C1 (Release and compatibility) identifies an application package, runtime, schema and configuration as one reviewed release record. Test the release against pending offers and retained operation results, and preserve compatibility with supported clients. Prompt/model changes also trigger the SW-C1 (Summary workflow contract) checks.
Where a schema must change, first establish whether old and new versions can coexist. Additive changes may allow a staged transition; removing or reinterpreting a field needs a specific migration and recovery plan. Reverting the application does not reverse accepted transfers or restore deleted data. Record whether the response to failure is rollback, forward repair or paused operation with reconciliation.
Start with an agreed limited exposure and observe acceptance failures, unknown results and pending-notification age. Stop widening the release when its checks fail. Thresholds, observation period and the person who decides are still to be agreed. Restore exercises and representative load checks inform readiness.
Proposed checks
TD-V1 (Environment checks) tests the environment’s contribution to the existing contracts. Every result below remains unrun.
| Scenario | Required result |
|---|---|
| Restart after X7 commits but before response | Retained result is available; no second transfer. |
| Two callers compete at version 12 | At most one complete change commits in the selected storage configuration. |
| Notification worker restarts | Pending work remains; duplicate delivery is handled. |
| Identity service unavailable | No invented authority; caller receives a clear unavailable or pending outcome as appropriate. |
| Restore a copy from before X7 | Writes remain paused until the missing interval and ownership are reconciled. |
| Recover with an incompatible schema or missing key | Problem is detected before declaring the service restored. |
| Old client submits during a release | Compatible request or explicit version response; no silent change of meaning. |
| Summary provider slows or fails | Manual review/transfer remains available if its other dependencies are healthy. |
| Burst of reconnection and background work | Agreed service limits, queue behaviour and costs are measured. |
| Export and restore into a replacement environment | Definitions, history, receipts and pending work remain usable and are checked. |
Methodology configuration
Map TD-D1, TD-R1, TD-C1 and TD-V1 into your deployment model, recovery plan, release record and readiness checks. The templates keep open choices visible. See Methodology configuration.