Skip to main content

Part of topic: Next.js Architecture, Zero-Trust Infrastructure, Full-Stack Systems Design

StackRoleYearStatus
Next.js 14, React 18, TypeScript, NestJS, PostgreSQL, Prisma, MongoDB, Mongoose, JWT, Passport.js, TanStack Query, Recharts, Tailwind CSS, AxiosFull-Stack Software Engineer2026Live
LedgerX — Secure, Multi-Tenant Financial Platform Architecture Diagram - Hero Preview by Ancel Ajanga.

LedgerX — Secure, Multi-Tenant Financial Platform

Production-grade invoicing, payments, double-entry ledger, audit, fraud detection and diagnostics

LedgerX — Secure, Multi-Tenant Financial Platform — Production-grade invoicing, payments, double-entry ledger, audit, fraud detection and diagnostics is a technical case study on ancel.co.ke documenting architecture, trade-offs and outcomes. To fix weak boundaries and poor auditability, I designed LedgerX so every request is org-scoped, every important action is an event and payments and diagnostics fail in controlled ways without corrupting the ledger. Ancel Ajanga wrote this case study from hands-on delivery exp…

Written by Ancel AjangaLead Software Engineer & Head of IT
Full-Stack Software Engineer
Ongoing (2026)
Live
Next.js 14
React 18
TypeScript
NestJS
PostgreSQL
Prisma
MongoDB
Mongoose
JWT
Passport.js
TanStack Query
Recharts
Tailwind CSS
Axios
View full tech stack

LedgerX is a production-grade, multi-tenant financial platform designed to handle invoicing, payments, accounting (double-entry ledger), audit/compliance, fraud detection and system diagnostics in a single, cohesive system.

The Problem

Most small-to-mid business financial tools suffer from weak multi-tenancy boundaries, poor auditability and compliance trails, payments tightly coupled to providers, no real fraud model beyond manual review, little observability when things degrade and frontends that break under real usage. LedgerX was designed to solve these problems holistically.

To fix weak boundaries and poor auditability, I designed LedgerX so every request is org-scoped, every important action is an event and payments and diagnostics fail in controlled ways without corrupting the ledger.

The Solution

I built LedgerX around six non-negotiables: strong multi-tenant isolation (every request and query organization-scoped), auditability by default (important actions are events and recorded), financial correctness (true double-entry ledger with append-only hash chain), resilience under failure (circuit breakers, graceful degradation), operational visibility (health, metrics, diagnostics, feature flags, controlled remediation) and security that earns respect (JWT + token versioning, rate limiting, role-restricted audit/diagnostics).

Key Technical Terms

  • Idempotency (payment intents):In LedgerX each payment intent is idempotent so duplicate webhooks or retries do not double-charge; that directly supports the goal of financial correctness and safe reconciliation with Stripe and M-Pesa.
  • Double-entry ledger with hash chain:Every financial movement is a balanced ledger entry in an append-only hash chain so we can detect tampering and reconcile; that supports auditability and compliance for the platform.
  • Circuit breakers:Stripe and M-Pesa adapters sit behind circuit breakers so when a provider is down or slow we fail fast and degrade gracefully instead of blocking or corrupting ledger state.

The Impact

LedgerX demonstrates senior-level backend architecture, security-first thinking, event-driven system design, fintech-grade data integrity and operational maturity beyond CRUD. It is designed to be read, reviewed and respected by experienced engineers.

Org-scoped

Every request and query organization-scoped

Double-entry

Append-only hash chain for integrity

Stripe + M-Pesa

Adapters behind circuit breakers

Health + Metrics

Diagnostics, feature flags, remediation

Outcomes

  • Production-grade multi-tenant fintech with event-driven architecture
  • Auditability by default; financial correctness via double-entry and hash chain
  • Fraud model and risk enforcement built into the core workflow
  • Operational visibility: health, metrics, diagnostics, feature flags, remediation
  • Security by design: JWT, token versioning, rate limiting, secret redaction
  • Deployed on Render (backend) and Netlify (frontend); live and GitHub retained

Architecture Deep-Dive

Backend: NestJS, single process. PostgreSQL (Prisma) for core transactional and compliance data; MongoDB for activity logs (high-volume, flexible schema). Domain event bus (in-process) for PaymentCompleted, LedgerTransactionPosted, InvoiceOverdue, DiagnosticsRemediationExecuted—powering audit, fraud and diagnostics. Stripe and M-Pesa adapters behind circuit breakers; idempotent payment intents; verified webhooks with raw body. Double-entry ledger with append-only hash chain. Frontend: Next.js 14 App Router, React 18, TanStack Query, role-gated navigation, org switcher. Deployed on Render (backend) and Netlify (frontend).

Key Engineering Decisions

I intentionally avoided Docker to reflect environments where containerization is not available and I chose E2E tests over exhaustive unit tests for real system confidence. I kept fraud rules deterministic rather than ML-heavy so behavior is auditable and predictable. I focused on operational correctness over UI polish. I used a synchronous in-process event bus instead of an out-of-process queue to reduce moving parts and keep the system understandable; single region/process. These decisions are documented in the repo.

Failure Modes & Resilience

Payment provider down: circuit breakers open so we do not block requests; we return clear errors and can retry or queue when the provider recovers. Webhook duplicate or replay: idempotent handling ensures we do not double-post to the ledger or double-fulfil an intent. Database or process crash: PostgreSQL transactions and append-only ledger keep data consistent; we can recover and replay from events where needed. Unauthorized access: JWT, token versioning and role-restricted audit/diagnostics limit blast radius and are audited.

Outcome & Future Potential

LedgerX demonstrates senior-level backend architecture, security-first thinking, event-driven system design, fintech-grade data integrity and operational maturity beyond CRUD. It is designed to be read, reviewed and respected by experienced engineers.

Roadmap & Expansion

Documented limitations: single region/process, synchronous event bus, MongoDB for activity only, no built-in queue. Path to extend: add queue, more E2E, horizontal scaling. LLM summarization for diagnostics is feature-flagged and optional.

Org-scoped

Multi-Tenancy

Every request and query organization-scoped

Double-entry

Ledger

Append-only hash chain for integrity

Stripe + M-Pesa

Payments

Adapters behind circuit breakers

Health + Metrics

Observability

Diagnostics, feature flags, remediation

Project Gallery

LedgerX — Secure, Multi-Tenant Financial Platform Architecture Diagram - Gallery Image 1 by Ancel Ajanga.
LedgerX — Secure, Multi-Tenant Financial Platform Architecture Diagram - Gallery Image 2 by Ancel Ajanga.