Architecture Portal

Technology and operation

Release, restart and recovery.

Adrian Sutherland · Version 1.0 · · © 2005–2026

BP-V08 (Runtime and recovery) · Version 1.0 · September 2026

Runtime and recovery

Accepted work must survive the relevant failure.

Design state
SOFT-01 (Later software option)
Level
Logical
Design
Proposed; checks unrun
Scope
Release packaging, persistence and recovery responsibilities
ASAF aspects
Technology, Systems, Security, Management

On a small screen, scroll the diagram sideways or read the text description below.

The staff client calls the application. Its case handler uses a durable transactional store; the notification worker resumes committed work. Identity and booking have separate dependencies. Recovery copies can restore older records, so accepted business work may need reconciliation before writes resume. Runtime products, instance counts and service objectives remain open.
BP-V08 (Runtime and recovery). Fictional software option; implementation checks are unrun.

Key

  • The application group shows release packaging. The recovery group shows restoration and reconciliation.
  • A recovery copy is not proof that all accepted work can be restored; reconcile the missing interval.

Linked records

Text description

The staff client calls the application. Its case handler uses a durable transactional store; the notification worker resumes committed work. Identity and booking have separate dependencies. Recovery copies can restore older records, so accepted business work may need reconciliation before writes resume. Runtime products, instance counts and service objectives remain open.

Runtime arrangement

TD-D1 (Runtime arrangement) evaluates one application release and a durable transactional store for SOFT-01 (Later software option). The notification relay can run as a worker from that release. Scheduling, suppliers, products and instance count remain open. Only the case service accepts ownership changes; summary work receives narrower access.

Keep deployment permissions separate from normal service permissions. Identify support for the application, store, identity, network and supplier dependencies. Measure realistic concurrent acceptance, reconnecting clients and pending notifications before selecting capacity and cost limits.

Restart and restore

Event Required treatment
Application restart after acceptance Preserve case, receipt and pending notification together. An authorised identical repeat returns the result without another transfer.
Restore a copy from before acceptance Accepted work may be missing even if the restore succeeds. Pause affected actions and notifications, prevent old writers, establish the missing interval and reconcile with the people doing the work.
Resume after reconciliation The service owner accepts the reconciled position and the remaining risks before writes resume.

TD-R1 (Recovery procedure) and SO-I1 (Incident and restoration) connect the technical recovery procedure to the business incident. An older receipt is historical; the current owner must be checked separately. Recovery time, allowable loss, copy location, encryption, retention and restoration checks remain open.

Release and service acceptance

TD-C1 (Release and compatibility) records the package, configuration, schema and client compatibility. Reverting an application does not undo accepted transfers. Choose rollback, forward repair or paused reconciliation according to the actual failure.

SO-R1 (Readiness record) gathers migration, access, staffing, observation, supplier and recovery readiness. SO-A1 (Service acceptance) records the service owner’s acceptance decision, including funding and residual risks. Begin with agreed limited exposure and stop widening when checks fail. Thresholds and decision owners need agreement.

TD-V1 (Environment checks) checks restart, concurrent callers, repeated notification, identity failure, older restoration, incompatible schema and representative load. All results remain unrun.

Physical choices

Choice Information needed before implementation
People and procedures Named owners, cover, escalation contacts, training and effective working instructions
Runtime and location Selected hosting, language, runtime version, deployment units, instance counts and network paths
Persistence Store product and configuration demonstrating atomic acceptance and restart durability
Access Identities, policies, credentials, rotation and emergency-access arrangements
Release Tested package, configuration, data migration, client compatibility and recovery route
Recovery Measured restore procedure, protected copies, accepted loss and business reconciliation

These are open Physical decisions, rather than an as-built specification. The technology and operations records provide the source detail.

About this edition

Refreshed for the September 2026 website update. This edition develops earlier Architecture Portal and ASAF material; the fictional service example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

Proposed

Last reviewed

Intended users

  • Architects describing, comparing and adapting an architecture

Non-goals

  • A prescribed product stack or a claim of measured service outcomes

Limitations

  • The service is a fictional design. Its proposed implementation and operational checks remain unrun.

Next evidence sought

  • Apply the views and linked checks to an actual service.