High availability and disaster recovery

Banking OS Connectivity provides enterprise-grade high availability and disaster recovery capabilities for critical banking operations. The platform minimizes downtime and data loss through automated recovery and self-healing infrastructure.

​

Service level agreements

Depending on your contract, your uptime SLA is 99.9% or 99.5%. For enhanced throughput commitments, see Add-ons. Recovery commitments:

• Recovery Time Objective (RTO): 6 hours for nominal situations
• Recovery Point Objective (RPO): Varies by data criticality; critical financial data uses synchronous replication for minimal data loss

​

High availability architecture

The platform uses redundant infrastructure and automated recovery to maintain continuous operation during failures.

​

Multi-zone deployment

The platform deploys services across multiple Azure availability zones within each region:

• Availability zones: Each zone operates independently with isolated power, cooling, and networking.
• Container distribution: Kubernetes pods spread across zones using anti-affinity rules and zone-aware scheduling.
• Data redundancy: Databases and storage replicate synchronously across zones for automatic failover without data loss.
• Network resilience: Load balancers distribute traffic across zones and reroute automatically when zones become unhealthy.
• Active-active-active deployment: Services run across three availability zones. The platform remains operational if two zones fail, provided the surviving zone has sufficient capacity to handle the workload.

​

Auto-scaling and load balancing

The platform automatically adjusts capacity based on demand:

​

Health monitoring

Kubernetes probes ensure application health:

• Readiness probes: Check if pods are ready to receive traffic.
• Liveness probes: Restart unhealthy containers automatically.
• Startup probes: Allow extended initialization time for slow-starting containers.

​

Fault tolerance patterns

The platform implements patterns to prevent cascade failures:

• Circuit breakers: Detect failing services and fail fast to protect the system.
• Exponential backoff: Retry with increasing delays to prevent retry storms.
• Fallback services: Serve cached responses when primary services are unavailable.
• Dead letter queues: Route permanently failed requests for later analysis.

​

GitOps and self-healing

The applications-live repository acts as the single source of truth for your runtime environment. ArgoCD continuously monitors cluster state:

• Drift detection: ArgoCD detects when cluster resources deviate from Git configuration, such as manual changes.
• Automated sync: The SelfHeal feature automatically reverts the cluster to the desired state defined in Git.
• Configuration reload: Reloader watches for ConfigMap and Secret changes and performs rolling restarts to apply new configurations.

​

Observability stack

The platform includes a pre-configured monitoring stack. Access is controlled through roles assigned in the self-service.tfvars file.

​

Grafana

Visualization dashboards for cluster health, performance metrics, and business logic.

​

Additional observability tools

Sync Hub services report into the same observability stack, with Grafana dashboards and log queries for the producer and consumer. For more information, see Monitor and troubleshoot Sync Hub.

​

Disaster recovery strategy

The platform implements multi-region failover to ensure business continuity during regional outages.

​

Cross-region replication

Data and services replicate across multiple Azure regions for geographic redundancy:

​

Data replication patterns

​

Backup strategy

Backup storage uses geo-redundant storage with encryption at rest, immutable storage, and long-term retention.

​

Failover procedures

Failover triggers include:

• Critical failures: Region outages, database corruption, security breaches
• Performance degradation: Response time thresholds, error rate spikes, SLA breaches
• Planned maintenance: Scheduled updates, infrastructure upgrades

The failover process executes through coordinated phases:

1. Detection: Automated monitoring identifies issues
2. Assessment: Evaluate scope and determine recovery strategy
3. Redirection: Update DNS and load balancer configurations
4. Validation: Health checks verify recovered services

​

Recovery testing

The platform also uses chaos engineering to inject controlled failures and validate resilience.

​

Incident management

​

Incident classification

​

Escalation procedures

• Automated escalation: Time-based rules, severity-based routing, on-call integration
• Communication protocols: Stakeholder notifications, status page updates, customer communication

​

Regulatory compliance

The platform supports banking regulatory requirements for business continuity:

​

Next steps