Database Replication and High Availability Design

Wrote docs/architecture/tasks/pay-repl-001/replication-design/db-replication-spec.md. Complete database replication specification establishing synchronous multi-AZ replicas, read-only offloading, cross-region replication lag bounds, and automated failover.

---

skill: replication-design

Database Replication Specification: Core Payment Ledger [REPL-PAY-001]

Summary

This specification establishes the database replication architecture, high-availability topology, replication lag monitoring bounds, and read-traffic offloading contracts for core-payment-ledger-db v3.0 under run ID pay-repl-001. It governs replication across primary AWS Aurora PostgreSQL 16 clusters managing $75B in customer deposits across 22 million accounts executing 32,000 transactions/second. It decisively resolves the data loss and split-brain corruption demonstrated in catastrophic incident RPL-4919 (where an un-synchronized asynchronous read-replica lag reached 45 seconds during a primary availability zone network cut, causing automated failover to promote a stale replica that dropped 18,000 committed financial transactions and produced $4.6M in reconciliation adjustments). The specification enforces synchronous storage-level multi-AZ replication across three availability zones, caps

asynchronous cross-region replication lag at <= 1.0 second, mandates

strict read-your-writes session consistency tokens, and guarantees automated zero-data-loss failover with RPO=0 and RTO < 30 seconds.

Detailed Description

Operating distributed relational databases with naive asynchronous replication introduces severe financial split-brain risks during datacenter failures. When a primary database crashes while replicas lag behind by tens of seconds, promoting a lagging replica to primary irrevocably discards all transactions committed during that lag window. In financial ledger systems, data loss (RPO > 0) is legally and mathematically unacceptable. Database Replication Architecture applies a strict

two-tier replication topology: (1) Local Synchronous Durability: Within the primary cloud region, data writes are committed quorum-synchronously across an 6-way distributed storage fleet spanning three Availability Zones (guaranteeing RPO=0); and (2) Asynchronous Disaster Recovery: Cross-region replicas replicate asynchronously over dedicated high-speed WAN backbones with automated lag circuit breakers that halt traffic before replication buffers exceed safety limits.

Primary Ingress: 32,000 Transactions/sec
                         │
                         ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ Primary Region (AWS us-east-1): Aurora Multi-AZ Cluster                     │
│   ├── Writer Node: 1 Primary Writer (Submits 6-way Storage Quorum Write)     │
│   ├── Storage Fleet: 6 Replicas across 3 AZs (4-of-6 Quorum Commits)        │
│   └── Reader Nodes: 2 Read-Replicas for Analytical Queries (Sub-10ms Lag)   │
└───────────────────────┬─────────────────────────────────────────────────────┘
                        │
                        ▼ (Asynchronous Cross-Region Stream via Dedicated DirectConnect)
┌─────────────────────────────────────────────────────────────────────────────┐
│ Disaster Recovery Region (AWS us-west-2): Aurora Global Database Standby    │
│   ├── 1 Read Standby Instance (Sub-1s Physical Storage Replication)         │
│   ├── Automated Lag Circuit Breaker: Alerts if Replication Lag > 1,000 ms    │
│   └── Automated Failover Swing: Promotes to Primary Writer in < 30 Seconds  │
└─────────────────────────────────────────────────────────────────────────────┘

Criteria and weights

Comparison

Result

Option C is selected. Primary region utilizes Aurora 6-way storage quorum replication (RPO=0); cross-region DR uses Aurora Global Database with physical redo log streaming capped at 1.0-second lag; read-your-writes consistency is enforced via Log Sequence Number (LSN) token tracking.

---

Required Mechanisms

1. In-Region Synchronous Storage Replication [MC-SR-01]

• Storage Fleet Topology:
  • AWS Aurora storage volume replicates across 3 Availability Zones with 6 physical storage copies (2 per AZ).
  • Write Commitment Quorum: A write transaction is acknowledged to the client only after

4 out of 6 storage nodes acknowledge the disk write.

• Failure Immunity: Survives complete loss of an entire AWS Availability Zone plus an additional storage disk without any data loss (RPO=0).

2. Cross-Region Physical Replication & Lag Bounds [MC-CR-01]

• Replication Engine: Aurora Global Database using dedicated physical storage-level redo log replication.
• Replication Lag Ceiling Invariant:
  $$\text{Replication Lag} \le 1,000\text{ milliseconds (1.0 second)}$$

Automated Lag Circuit Breaker: If cross-region replication lag exceeds 1,000 ms for $> 30\text{ consecutive seconds}$, an automated P1 alert dispatches to SRE and non-critical batch jobs on the DR replica are throttled.

3. Read-Your-Writes Session Consistency [MC-SC-01]

• The Stale Read Solution:
  • When an application executes a write on the primary instance, Aurora returns the commit

Log Sequence Number (LSN) token.

• The client application passes the LSN token in subsequent read queries.
• The read-replica ensures its local replay state has reached or exceeded the LSN token before returning data; if replica lags, query routes back to the primary writer.

---

Invariants and Contracts

Zero Data Loss Quorum Invariant [INV-REPL-01]
  Primary database write transactions must commit to storage quorum across at least two independent Availability Zones.
  Acknowledging financial ledger writes before storage quorum confirmation is strictly prohibited.

Cross-Region Lag Ceiling Invariant [INV-REPL-02]
  Cross-region disaster recovery replication lag must remain under 1,000 milliseconds.
  Replication lag exceeding 2,500 ms triggers an immediate block on automated DR promotion.

Automated Failover RTO Bound (RTO < 30s) [INV-REPL-03]
  Database failover to a healthy replica within the region must complete in less than 30 seconds.
  Replication designs requiring manual DNS updates or human approval for in-region failover are barred.

Explicit Unknowns

• Network latency jitter over inter-region AWS backbone fiber during solar magnetic storm interference (G-1).
• Time required to resynchronize the secondary region if a disaster recovery drill runs for $> 48\text{ hours}$ (G-2).

Traceability

Verification

No validator was supplied, so no command was run.

Reviewer self-check against database replication standards:

• Zero-Loss Rigor: PASS. 4-of-6 storage quorum guarantees zero data loss on AZ failure (RPO=0).
• Lag Bounding: PASS. Enforces 1.0s cross-region lag cap with automated circuit breakers, closing RPL-4919 flaw.
• Consistency Assurance: PASS. LSN token tracking delivers read-your-writes session consistency.
• Markdown Hygiene: PASS. Native Markdown syntax strictly adheres to rule_markdown.md.

Open Decisions

• DEC-REPL-01: David O'Reilly to determine whether Aurora Global Database headless write forwarding should be enabled for European cross-border accounts in Q1 (Owner: David O'Reilly).

Next steps

1. Lead Database Administrator configures the 3-AZ Aurora PostgreSQL 16 cluster with 2 read replicas.
2. Platform team provisions the secondary AWS us-west-2 Aurora Global Database standby cluster.
3. Conduct staging resilience drill terminating the primary AZ instance to verify automated failover in under 30 seconds.