Building Resilient Core Banking APIs: Lessons from Processing 8B+ Transactions
How we architected our cloud banking platform to handle millions of transactions with 99.9% uptime across multiple African markets.
Every year, more than eight billion transactions flow through the banking infrastructure we operate — transfers, ledger postings, balance checks, and settlement runs across multiple African markets. Each one has to be fast, correct, and auditable. There is no room for an almost-correct ledger.
This post shares what we learned building the core banking APIs behind Banq Pro: the architectural choices that keep us at 99.9% uptime, and the mistakes we made along the way.
Idempotency is non-negotiable
Mobile networks drop, clients retry, and webhooks fire twice. Our first hard rule: every mutating endpoint accepts an idempotency key, and retries with the same key return the original result instead of posting twice.
This single constraint eliminated an entire class of double-debit incidents. If you take one thing from this article, take this: design every money-moving endpoint to be safely retryable before you design anything else.
Separate the ledger from everything else
The ledger is the one component that must never be wrong, so we keep it small, synchronous, and boring. Balance checks, notifications, analytics, and webhooks all happen asynchronously downstream of a committed posting.
When a downstream consumer fails, the money is still right — only the notification is late. That ordering of priorities has saved us more times than any amount of infrastructure.
Design for the networks you have
African banking rails and mobile networks have their own failure modes: timeouts that actually succeeded, settlements that arrive in batches, and providers that degrade instead of failing cleanly. We reconcile continuously rather than trusting any single response.
Every integration runs against a reconciliation loop that compares our ledger with provider statements and flags mismatches for review. Boring, relentless reconciliation beats clever error handling.
What we'd do again
Start with the ledger, enforce idempotency everywhere, reconcile continuously, and keep the blast radius of every service small. None of this is exotic — resilience in banking comes from discipline, not novelty.
If you're building on top of banking infrastructure instead of building it yourself, that is exactly what Banq Pro exists for.