Payment Checkout & Ledger Service  ·  View 18 of 24  ·  Operations

Deployment — Two In-Country Data Centres

Both sites serve authorization; only the ledger has a single writer.

Editable source SVG draw.io All views
DC-1 (primary) — in country Edge tier L4 load balancer anycast VIP Gateway pods Envoy · HPA Authorization pool Kubernetes cluster 3 control nodes Intent + router pods scaled on in-flight Adapter pods static egress IPs CDE segment Card proxy + vault separate cluster Network HSM pair FIPS 140-3 Record tier Kafka · 5 brokers RF 3 · min.isr 2 Ledger primary PostgreSQL · sync Payment state sharded by merchant DC-2 (warm, same country) — 40 km, 1.4 ms RTT Edge and authorization Gateway pods live, 30% share Intent + router pods active Record tier Ledger sync standby RPO 0 Kafka stretch replica CDE + HSM pair Batch tier Settlement + payout jobs runs here by default Projection rebuild Shared control Platform services Observability stack both DCs Secrets + PKI CI/CD runners air-gapped promote Acquirers leased line + IPsec A2A rail allowlisted egress Settlement bank SFTP sync replication static IP payout file Deployment — Two In-Country Data Centres Security / platform Interface / broker Application we own Queue / topic Data store External / third party synchronous batch Both DCs serve authorization traffic; Kafka is stretched across them. Only the ledger has a single writer, and only its failover is a declared operation. v 1.0 · owner Payments Platform Architecture · date 2026-10

Decisions

  • Open source on self-managed Kubernetes in two in-country data centres, rather than a hyperscaler: data localisation plus PCI-DSS scope containment, and a money path with no dependency on a provider the regulator has not approved (ADR-18).
  • The ledger is synchronously replicated at 1.4 ms RTT, which is what makes RPO 0 affordable. That number is the reason the second site is 40 km away and not 1,400 km.
  • Settlement and payout batch jobs run in DC-2 by default, keeping reporting load off the site taking the payments (ADR-16).

Numbers

  • Authorization plane RTO ≤ 120 s; ledger write path RTO ≤ 15 min; reporting RTO ≤ 4 h.
  • Ledger RPO 0; payment state RPO ≤ 5 s.
  • DC-2 carries ~30% of authorization traffic in steady state, so failover is a weight change rather than a cold start. Stated assumptions.

Risks

  • Two sites 40 km apart share a metro. A regional event takes both, and the response is a declared, announced outage with RPO 0 rather than a third site — a deliberate limit of this design (ADR-18).
  • Self-managed Kubernetes, Kafka, PostgreSQL and HSMs is a real operational staffing commitment. It is the cost of the localisation decision, not a free choice.
◀  Merchant Notification by Event Class All views Observability — Signal by Pipeline Stage  ▶
Solution Architecture v1.0 · open source, self-hosted on Kubernetes across two in-country data centres · Payments Platform Architecture · 2026-10 · 24 views · 18 architecture decision records18-deployment-architecture