Scaling Isn’t the Hard Part — Staying Correct Is
Scaling Isn’t the Hard Part — Staying Correct Is is an expert-authored guide on https://ancel.co.ke/guides. How to build a finance platform that stays correct when payment providers are async, callbacks are delayed or duplicated and caches fail. Ledger-backed double-entry, idempotent M-Pesa, fail-closed locks. It answers how teams should think about: Building a finance system isn't CRUD—it's correctness under failure. Ancel Ajanga wrote this guide tying patterns to real portfolio systems.
Part of topic: Node.js & Backend Systems, Zero-Trust Infrastructure, Full-Stack Systems Design
What problem does this guide address?
Building a finance system isn't CRUD—it's correctness under failure. The system must remain predictable when payment providers are asynchronous, callbacks are delayed or duplicated, caches fail and networks are unreliable. The core challenge is fault isolation and ledger correctness across multiple storage models and external integrations.
How is the system architected?
Hybrid storage: PostgreSQL for wallets and ledgers (single source of truth), MongoDB for events and audit logs, Redis for locks, queues and rate limits. Stateless NestJS backend with JWT; M-Pesa Daraja flows are idempotent, timeout-aware and guarded by retries, backoff and circuit breakers. Real-time UX via Socket.io when callbacks are processed. Withdrawals follow request → approval → execution → callback with database-enforced idempotency; DISPUTED state for manual reconciliation when provider response is ambiguous.
What outcomes can you measure?
NestFi delivers correctness-first design: financial truth is never inferred; explicit handling of timeouts, replayed callbacks and split-brain risk; real-time payment experience; strong auditability aligned with Kenyan fintech. Completion ~87% with core ledger, M-Pesa B2C, mobile deposits, autosave batching and audit flows implemented. Fail-closed distributed locks and idempotent callback processing throughout.
Deep dive
Hook Building this system looked easy on paper. In production, it nearly destroyed the backend.
Problem Theoretical guides fail to mention what happens during thousands of concurrent operations.
Struggle Race conditions and missing indices led to silent failures that were nearly impossible to trace.
Solution I adopted a rigorous constraint-based architecture that failed securely rather than succeeding incorrectly.
Insight Real-time systems fail quietly, not loudly.
Review the Case Studies to see it in action.
Frequently asked questions
- What engineering problem does this guide tackle?
- Building a finance system isn't CRUD—it's correctness under failure. The system must remain predictable when payment providers are asynchronous, callbacks are delayed or duplicated, caches fail and networks are unreliable. The core challenge is fault isolation and ledger correctness across multiple storage models and external integrations.
- How is the system architected?
- Hybrid storage: PostgreSQL for wallets and ledgers (single source of truth), MongoDB for events and audit logs, Redis for locks, queues and rate limits. Stateless NestJS backend with JWT; M-Pesa Daraja flows are idempotent, timeout-aware and guarded by retries, backoff and circuit breakers. Real-time UX via Socket.io when callbacks are processed. Withdrawals follow request → approval → execution → callback with database-enforced idempotency; D…
- What measurable outcomes can you expect?
- NestFi delivers correctness-first design: financial truth is never inferred; explicit handling of timeouts, replayed callbacks and split-brain risk; real-time payment experience; strong auditability aligned with Kenyan fintech. Completion ~87% with core ledger, M-Pesa B2C, mobile deposits, autosave batching and audit flows implemented. Fail-closed distributed locks and idempotent callback processing throughout.
Related case studies & projects
Developer Journalfor narrative deep dives, or get in touch for a conversation.