A Multi-Country Transfer Platform
The synthesis design: home regions for residency, one journey driven by country configuration, domestic transfers inside a region, cross-border transfers as sagas through FX and settlement, global non-personal services, and country-scoped failure.
Brief, questions and numbers
- One app lets customers in Nigeria and Kenya (and later Ghana and Egypt) hold balances, pay locally and send money across borders.
| question | answer we assume |
|---|---|
| countries? | 2 now, 6 within two years |
| residency? | personal data stays in country or approved region |
| rails? | NIP in Nigeria, M-Pesa in Kenya, others later |
| consistency? | strong per account; cross-border may take minutes |
| availability? | one country's outage must not stop others |
customers = 8M (NG 6M, KE 2M); transfers 4M/day ≈ 46/s average, ~500/s peak cross-border share ≈ 3% → ~120k/day, each a multi-step saga per-region ledgers sized like part 3; global services small and stateless
v1, the break, and v2
v1. One global deployment in a single region with one ledger database and per-country if statements throughout the code.
The break. Residency rules are violated, latency is high for distant countries, every new country edits core code, one outage takes every country down, and cross-border transfers are a single distributed transaction that cannot be made safe.
v2. Home regions per country with regional ledgers and data, a shared core with country adapters and configuration, local rail adapters, cross-border transfers as sagas through a global FX and settlement service, anonymised global reporting, and per-country SLOs, incidents and reconciliation.