DR / Availability Diagram

Service availability, protected access path, separate frontend and backend recovery model, persistent dependency restoration order, and resilience posture for the CMS platform

🛡️

Users / Service Availability Expectations

HIGH-AVAILABILITY ENTRY PATH

USER

End Users

Access CMS through resilient edge and protected application entry points

Akamai

Highly available edge protection and internet-facing routing layer

Application Gateway

Controlled ingress to protected backend endpoints and AKS ingress routing

ING

Ingress Availability

Requests keep entering through the protected path while downstream services are restarted, re-routed, or recovered

The public entry path remains protected and resilient while internal application components can be restored in a controlled dependency order.

PRIMARY APPLICATION RUNTIME

Frontend and backend are separate deployables; private backend services are recoverable through restart, redeployment, and scale restoration

React SPA

Presentation-layer artifact delivered separately from backend runtime and recoverable through independent frontend redeployment

API

CMS Backend API Services

Frontend-facing secured backend services running on private AKS with no dedicated BFF layer

DOM

Domain Services

Business services recover mainly through redeployment and restored connectivity to required platform dependencies

SHR

Shared Platform Services

Workflow, notification, and document services depend on operational stores but remain runtime-recoverable backend services

Persistent data and storage services define the real recovery order because meaningful backend restoration depends on them.

PERSISTENT PLATFORM DEPENDENCIES

Microsoft Fabric

Read-only enterprise analytical dependency required for data-driven views, summaries, dashboards, and insight-based screens

Azure DocumentDB

Operational application store required for workflow state, notifications, preferences, audit records, and metadata recovery

Azure Storage Account (Blob Storage)

Persistent object storage for files, attachments, exports, and generated artifacts that must remain recoverable

RECOVERY PRIORITY GROUPS

Priority 1

Edge entry, ingress, and identity path required to re-establish secure access to the platform

Priority 2

Operational data stores and file stores required for stateful CMS function recovery

Priority 3

Backend API services, domain services, and shared platform services restored once core dependencies are available

Priority 4

Frontend redeployment, non-blocking supporting integrations, and observability enrichment completed after core recovery

Monitoring, alerting, and support services detect degradation early and guide restoration sequencing during incidents.

RESILIENCE, MONITORING & SUPPORTING SERVICES

Azure AD

Identity dependency required for authenticated user recovery and secure access restoration

RBAC

Backend Authorization

RBAC and ABAC are enforced directly in backend services during normal operations and after recovery

Datadog

Health monitoring, alerting, telemetry, and incident visibility across application and platform paths

Infobip

Outbound delivery integration that is useful but typically not first in the recovery order

DR / AVAILABILITY DESIGN PRINCIPLES

Separate Deployables

Frontend and backend recover independently, improving release isolation and restoration flexibility

Stateless Services First

Backend runtime services should be restartable and redeployable without carrying critical business state in memory

Protect Stateful Dependencies

DocumentDB, ADLS, and Fabric connectivity determine true functional recovery readiness

Restore in Order

Access path, identity, storage, backend runtime, frontend, then supporting integrations

          High-availability entry path
          Primary application runtime
          Persistent platform dependencies
          Recovery priority groups
          Resilience & support services
          DR / availability principles
        