D5 · Continuity, recovery and backups

This plan defines how Bolívar Connect keeps the service running during an interruption, how it recovers it after a disaster and how it protects its data with backups.

1. Recovery objectives

Indicator	Objective	What it means
RTO (recovery time objective)	4 hours	Maximum time to restore the API service
RPO (recovery point objective)	5 minutes	Maximum data that can be lost, thanks to point-in-time restore

2. Critical processes

Process	Impact if it stops	Priority
Receiving and validating payment instructions	Clients cannot order payments	1
Transmission to the regulated financial institution and status tracking	Payments not executed or not confirmed	1
Webhook notifications to clients	Clients do not learn the outcome of their payments	2
Reconciliation against the regulated financial institution	Undetected differences	3

3. Resilience by design

The platform is built so that an outage neither loses nor duplicates payment instructions:

• every instruction is idempotent and atomic, and a retry does not generate a second payment;
• instructions with an ambiguous result are resolved automatically against the regulated financial institution and are never resent by another route;
• client notifications go out from a persistent queue (outbox) that redelivers them when the service comes back;
• service shutdown is orderly and lets in-flight operations finish;
• a circuit breaker isolates a failing third party without stopping the rest of the platform.

4. Scenarios and response

Scenario	Response
Application failure	Automatic service restart by the operating system
Instance failure	Instance recreated from infrastructure as code and data restored
Data corruption or deletion	Database restored to the last valid point before the event
Outage of an AWS availability zone or region	Infrastructure recreated in another zone or region from code and the most recent backup
Outage of the regulated financial institution	Circuit breaker, instructions held with their status and clients notified; they resume when the institution comes back
Security compromise	Incident response plan (D4)

5. Disaster recovery

1. The Coordinator declares the disaster and notifies Management.
2. The infrastructure is recreated from the versioned AWS CloudFormation template.
3. The database is restored from the most recent backup or point in time.
4. Secrets are loaded from AWS Secrets Manager and the current version of the code is deployed.
5. Service health, the traceability ledger invariants and the reconciliation against the regulated financial institution are verified.
6. Clients are notified and the service resumes.

6. Backup policy

Aspect	Rule
What is backed up	The entire database. Code and infrastructure are recovered from the repository, and secrets from AWS Secrets Manager
Frequency	Automatic daily backup plus a continuous transaction log, which allows restoring to any point
Retention	7 days of point-in-time restore; manual snapshot before every relevant change; final snapshot if the infrastructure is deleted
Encryption	AES-256 with AWS KMS
Location	AWS, us-east-1 region, outside the application instance
Access	Only authorized technical personnel according to D2

7. Testing

• Restore: once a quarter a backup is restored in an isolated environment and the data is verified to be complete and consistent.
• Plan exercise: once a year a scenario from section 4 is simulated, the actual recovery time is measured against the RTO and the results and improvements are recorded.