The circular does not require everything to move onshore. It requires payment transaction data to be stored and processed in Nigeria. Everything else can stay hybrid or stay offshore.
That means the post-migration architecture has three environments: an onshore primary, an onshore DR site, and an offshore analytics and AI environment. Designing this topology so it works without making the team hate their lives is the subject of this article.
This is a playbook. If you are an infrastructure architect or platform engineer, you can take the patterns here and apply them directly to your migration plan.
The three-environment model
Here is what each environment runs.
Onshore primary (Lagos colocation or sovereign cloud). This handles all payment transaction processing. Every transaction the circular covers originates, processes and stores here. This environment is the compliance boundary.
Onshore DR (Kano, Abuja or Port Harcourt colocation). This runs the same workloads as the primary site. It receives near-synchronous replication from the primary. If the primary goes down, the DR site takes over within minutes. It is fully capable of running the entire transaction load independently.
Offshore (existing hyperscaler region, for example AWS af-south-1 or eu-west-2). This runs everything that is not payment transaction data. Analytics, AI and ML training, business intelligence, archival and non-production environments. It also serves as a third-layer DR option for non-transaction workloads.
Each environment has its own failure mode. The onshore primary fails (Lagos power outage, fibre cut). The onshore DR fails (Kano has its own risks, though different from Lagos). The offshore environment fails (hyperscaler region outage, rare but possible). The architecture should handle any single-environment failure without customer-facing impact.
Boundary 1: the compliance boundary
The most important line in this topology is between the onshore environments and the offshore environment. Payment transaction data stays onshore. It does not cross to offshore for any reason.
This is not a policy. It is an architecture constraint. If the network allows transaction data to leave the onshore environments, the architecture is non-compliant regardless of what the operating procedures say.
Enforce this boundary at three levels:
- Network level. The onshore environments should not initiate outbound connections to the offshore environment for payment transaction data. If transaction data needs to move, it moves through a controlled data path that is logged and monitored. No general-purpose egress.
- Identity level. Roles and permissions in the onshore environment should not grant access to offshore resources, and vice versa. If a service account in the onshore primary can read from an offshore database, that is a compliance risk.
- Application level. Application code should know which environment it runs in and behave accordingly. A service running in the onshore environment should not attempt to write transaction data to an offshore endpoint. Enforce this in code, not in documentation.
Boundary 2: the replication path
Transaction data replicates from the onshore primary to the onshore DR site. This is the only cross-environment data path that carries payment transaction data.
The replication pattern depends on your latency profile. If the round-trip time between the Lagos colocation and the DR site is under 10 milliseconds, synchronous replication is viable. Every transaction writes to both sites before returning success. This is the strongest consistency model.
If the latency is higher (10 to 50 milliseconds), use near-synchronous replication. The primary writes the transaction and sends a replication stream to the DR site within a few seconds. This introduces a small window of data loss if the primary fails before the DR site receives the replication.
If the latency is unpredictable or the DR site is not designed for synchronous workloads, use asynchronous replication with a confirmation step. Every transaction batch is confirmed by the DR site before the primary considers it complete. This is slower but safer over unreliable links.
Test your replication under production load before the migration. Run a load test that matches peak transaction volume and measure the replication lag. If the lag exceeds the recovery point objective (the amount of data you are willing to lose in a failover), adjust the replication pattern or the topology.
Which workloads land where
Here is how the classification from Article Three maps to the three environments.
| Workload type | Onshore primary | Onshore DR | Offshore |
|---|---|---|---|
| Payment transaction processing | Yes | Yes (standby) | No |
| Transaction log storage | Yes | Yes (replicated) | No |
| Settlement data | Yes | Yes (replicated) | No |
| Analytics aggregates (no transaction data) | No | No | Yes |
| AI and ML training data | No | No | Yes |
| Business intelligence dashboards | No | No | Yes |
| Archival storage (older than 90 days) | No | No | Yes |
| Non-production (dev, test, staging) | No | No | Yes |
| DR failover for offshore workloads | No | No | Yes (cross-region) |
The "no" cells are the compliance boundary. The "yes" cells in the DR column are the replication path.
The control plane choice
You need to decide whether the onshore and offshore environments share a control plane or operate independently.
Shared control plane. One set of IAM, one deployment pipeline, one monitoring dashboard, one configuration store. The tooling abstracts the environment so the team does not need to think about where a service runs. Simpler to operate. The risk is that a control plane failure affects both environments simultaneously.
Separate control planes. Each environment has its own IAM, deployment pipeline, monitoring and configuration. More operational overhead. Better isolation. A control plane failure in one environment does not affect the other.
Start shared and add isolation over time. The first six months of a migration are chaotic enough without maintaining two monitoring dashboards. Once the migration is stable, you can evaluate whether the isolation benefits justify the operational cost.
The latency trap
Moving transaction processing from a hyperscaler region to a Lagos colocation changes your latency profile. What used to be a 50-millisecond round trip from a Lagos office to Cape Town becomes a 2-millisecond round trip to a Lagos colocation. That is an improvement for most operations.
But some things get worse. If the application architecture assumes that all services are in the same cloud region, moving some services onshore and leaving others offshore introduces cross-environment latency. A service that calls an offshore API from the onshore environment now has a 50 to 100 millisecond penalty for each call.
The fix is to group services by data gravity. Services that handle payment transaction data should all move onshore together. Services that do not handle transaction data can stay offshore. Cross-environment calls should be asynchronous where possible. Synchronous cross-environment calls should be rare and explicitly designed for latency tolerance.
Test this before cut-over. Set up the onshore environment, deploy the transaction-processing services and run a performance test that mirrors production traffic. Measure the latency of every cross-environment call. Fix the ones that are too slow. Do not assume the latency will be acceptable because the colocation is physically closer.
Putting it together
A complete hybrid topology for a typical bank or large fintech looks like this:
- Lagos colocation: 20 to 40 rack units, redundant power and network, connected to the DR site via dedicated fibre or VPN
- Kano colocation (DR): 10 to 20 rack units, Tier IV, PCI-DSS, same application stack as the primary, warm standby
- Offshore cloud region: existing hyperscaler account, analytics workloads, non-production environments, third-layer DR for non-transaction data
- Shared control plane: one IAM domain with federated access to both onshore environments, one deployment pipeline, one monitoring dashboard
- Replication: near-synchronous from Lagos to Kano for transaction data, asynchronous from onshore to offshore for analytics aggregates
- Compliance boundary: enforced at network, identity and application levels. No transaction data leaves the onshore environments.
This topology survives a Lagos outage, a Kano outage, an offshore region outage and a control plane failure (if isolation is added later). It is compliant with the circular. It does not require moving everything onshore.
The position of this Journal
This is the complete design the series has been building toward: classification from Article Three, the control plane from Article Four, the second-site discipline from Article Five, and now the three-environment topology that holds them together. It is also the full description of what Kaliabe builds: the sovereign platform layer, the DR estate, the replication paths and the control plane, specified and delivered as one system. The deadline is fixed. The architecture is now fully knowable.
FIG. J6 — HYBRID TOPOLOGY · THREE ENVIRONMENTS · TWO BOUNDARIES · THE COMPLETE DESIGN