High availability

Self-hosted DALP deployments need an availability design before production workloads go live. Start with a cloud-native, multi-zone approach when you can use managed Kubernetes, PostgreSQL, a cache layer, and object storage. Move to hot-warm, hot-cold, or hot-hot only when the recovery target, a geographic requirement, or a cost constraint justifies the added operating burden.

What the availability design covers

An availability design decides how DALP keeps the application, database, cache, object storage, backups, indexing, chain access, and dependent infrastructure usable when an infrastructure component fails.

This overview is for platform operators preparing the deployment, buyers comparing operating models, and security or risk reviewers checking recovery ownership.

The chosen approach does not replace your incident process, custody procedures, client communication plan, or post-incident validation. Before production, assign owners for failover decisions, restore testing, and post-incident checks. The approach only works when those duties are staffed and tested.

For the recommended baseline, read cloud-native next.

Responsibility split

Three layers make up the availability picture. Keep them separate when you review any production deployment.

DALP availability depends on the configured infrastructure and vendor contracts. Do not present a deployment pattern, an RTO target, or a successful drill as an SLA commitment. The contractual SLA, cloud SLA, custody SLA, and RPC SLA must all support that commitment before you make it.

The design has two loops. The live-service loop keeps ingress, DALP services, and the data layer (PostgreSQL, Redis, plus object storage) available during normal operation. The verification loop proves that backups are reachable and an owner can complete a restore and sign off within the selected RTO. Replication checks validate the chosen RPO. Test the two loops independently: a healthy live service does not prove that the backup path works.

Recovery metrics

RTO and RPO are targets. RTT is evidence. A deployment is not production-ready until you have run a recovery drill, measured restore time, and validated application and data state. Accept any gap between the goal and the tested result before treating the setup as production-ready.

Choose a deployment scenario

Use the scenario table as an operating model filter. The RTO and RPO ranges are planning goals for each option. The ranges become verified only after the operator runs the matching restore or failover drill, records the achieved recovery time, and validates the data-loss window from backup age, replication lag, or restored data timestamps.

Start with the cloud-native pattern unless a specific requirement rules it out. Managed services handle PostgreSQL failover, Redis failover, and object storage availability. Use the alternative patterns only when you accept the extra runbook and drill burden.

Document that acceptance before production. The chosen pattern, staffing model, and contractual SLA must stay in sync.

Kubernetes high availability assumptions

Production self-hosting assumes a Kubernetes or OpenShift cluster that can keep workloads scheduled during a zone or node failure. The baseline is at least three availability zones, enough worker capacity to reschedule pods after one zone is unavailable, standard topology labels, pod disruption budgets, and a load balancer or route layer that can send traffic only to healthy pods.

Control-plane availability belongs to the cluster provider or the operator's Kubernetes platform team. The DALP design assumes the control plane remains reachable for scheduling and rollout work during an incident, and reachable when a zone fails. If the control plane is self-managed, document the quorum design before production. Include backup, restore, and upgrade procedures in that documentation.

Failover triggers must be observable. Treat pod crash loops, node readiness loss, zone unavailability, PostgreSQL failover, cache failover, object storage failure, RPC endpoint failure, indexer lag, and queue backlog as conditions that can start the incident runbook.

Chain access and indexing recovery

DALP uses EVM RPC and the chain indexer as part of the availability design. RPC access and indexed views need separate redundancy checks because endpoints and indexers fail differently from application pods.

Ledger Index replica scope

Ledger Index is an active chain indexer, not a stateless web service. The DALP chart runs one Ledger Index replica per deployment and requires a Recreate rollout strategy so two active indexer pods do not overlap during an update.

For HA planning, treat the Ledger Index as a recoverable indexing component. Monitor its sync lag, handler errors, and backfill progress. In a regional failover, bring up or promote the recovery-side indexer through the tested runbook, then validate indexed state against chain data before ending the incident. Do not add horizontal replicas to one Ledger Index deployment to meet an RTO goal.

Disaster recovery region coverage

A regional disaster recovery plan needs at least two roles: one primary service region and one standby site. The primary region serves production traffic. The standby site holds the infrastructure, secrets access, database restore path, object storage replication or backup access, RPC configuration, and runbooks needed to resume service.

Hot-warm is active-passive. The primary region serves traffic; the standby stays ready for promotion. Failover transfers full service ownership to the standby. Every layer moves together: the application stack, data services, RPC access, indexer, and ingress routing. Your runbook drives each step.

Hot-cold is restore-based active-passive. The standby region may not run the full stack until an incident starts. The runbook must prove that backups, images, secrets, DNS or ingress, and provider access can recreate the service inside your accepted RTO and RPO. Hot-cold carries the lowest monthly effort, and restore-based recovery takes longer than promoting a warm standby or switching to a running cluster.

Hot-hot is active-active. More than one region serves traffic simultaneously. Use this pattern only when you can handle multi-cluster routing, data consistency, indexed-state reconciliation, and provider limits, and only when incident ownership spans all active regions.

Monitoring and alerting expectations

Monitoring must cover the platform and infrastructure, plus any external dependencies the selected availability design relies on. At minimum, alert on:

• API availability, request latency, error rate, and authentication failures.
• Pod restarts, crash loops, node readiness, zone status, and ingress or route health.
• PostgreSQL failover state, replication lag, connection pressure, backup success, and restore-test age.
• Cache primary state, memory pressure, persistence status, and failover.
• Object storage availability, backup write status, replication status, and restore access.
• Queue backlog, worker state, transaction workflow age, and stuck execution states.
• RPC endpoint availability, chain head age, block lag, and provider errors or rate limiting.
• Indexer process state, per-chain indexing lag, replay progress, and reorg or retraction events.
• Custody or HSM reachability for signing-dependent workflows.

Every alert needs an owner, severity, runbook link, escalation path, and test cadence. Dashboards are evidence only when alerts fire, route to the right owner, and drive a tested response.

Use platform status endpoints when an operations console or runbook needs DALP's read-only status panels covering data freshness, workflow execution, platform API activity, and snapshot history. For request logs and endpoint metrics, see API monitoring. For chain health, RPC availability, and indexer lag, see blockchain monitoring.

Production checks before go-live

Before treating any deployment as production-ready, confirm that the operator has:

Next pages

• Buyers comparing operating models should start with cloud-native for the recommended baseline. Read hot-warm next if geographic redundancy matters. Move to hot-cold when cost is the primary constraint, or to hot-hot when active-active operation is required.
• Platform operators preparing a deployment should read self-hosting prerequisites, choose the matching pattern page, and use backup and recovery to plan restore tests and recovery drills.
• Security and risk reviewers should use the pattern page to confirm what failover covers, then review backup and recovery for restore ownership and drill evidence.