Skip to main content
A restored database can be technically healthy while missing work that was previously acknowledged. If Gateway treats those missing records as proof that the work never happened, recovery can create duplicates or lose unresolved obligations. The selected recovery design therefore asks for more than a successful process restart.

​
What the objectives mean

Recovery point objective, or RPO, describes the allowed loss of records under the stated failure model. Gateway’s selected objective is zero loss of confirmed evidence in its qualified scope. Recovery time objective, or RTO, describes how long recovery may take under that same scope. The selected objective is at most 30 minutes. These are design objectives, not measured current production guarantees. A test on one local machine does not establish independent failure domains, offsite recovery or the complete operational time needed to resume safe serving.

​
Preserve the selected durability profile

The native-history contract retains a three-PostgreSQL-instance topology and its specified durable-flush requirements. A simplified explanation about surviving copies must not silently weaken those requirements into another topology. The company core database migration and the isolated Gateway experiments are distinct evidence sets. They cannot be joined into a production disaster-recovery claim merely because both use PostgreSQL 17.

​
Recover authority along with data

Before confirming an old operation or admitting new work, the runtime needs the authoritative current history, correct restore generation and valid writer and reader custody. Stale execution processes must be fenced so they cannot resume as if nothing changed. An old instance must not borrow a new controller or create another attempt for an operation whose remote result is unknown. This is a conceptual recovery sequence, not a substitute for the operator-owned recovery procedure or a guarantee that every stage has been tested.

​
Unfinished obligations survive a restart

Pending settlement notifications, uncertain financial effects, duplicate-protection keys, corrections and native-capacity history must remain linked to the original operations. An acknowledged execution record does not settle a foreign wallet effect. Financial owners still reconcile their own original operations and prevent duplicate or late debits. Likewise, a nominal retention interval does not authorize deletion while protected obligations remain. Lawful purge requires the actual dependency and writer coverage; uncertainty about that coverage holds deletion.

​
What a recovery claim needs

A credible acceptance receipt identifies the deployed source and database profile, failure model, actual backup and history custody, writer exclusion, preserved acknowledged records and measured return to safe serving. This publication performs no database migration, destructive cleanup or disaster drill. The available local results are described in Implementation status, and the request-level ambiguity is explained in When a confirmation is lost.