Fintech SaaS MVP — Concurrent Ledger APIs

Context

A Series-A fintech needed the ledger MVP to survive real concurrency before the next funding demo. Rewriting the database was off the table.

The problem

Ledger reads and writes piled up as concurrent users spiked. The MVP shared one Postgres pool with the rest of the product, so row locks on the ledger table stalled transfers, balances, and the React console at once.

Architecture

Split the ledger into a Node.js worker service behind a Redis token-bucket rate limiter. Hot paths used an outbox + Redis cache for balances; the legacy store stayed the system of record. React talked only to the new API, not the old monolith.

Outcome

p95 database latency dropped 40% under the same concurrency profile. Transfers stayed consistent; the client kept the existing schema.

Handover

Source, runbooks, rate-limit config, and infra access transferred to the client team under NDA.

What we shipped

• Token-bucket rate limiter in Redis so burst traffic queued instead of saturating Postgres.
• Ledger writes on a dedicated Node.js worker with idempotent transfer IDs.
• Balance reads served from Redis with short TTL, invalidated on commit.
• React ops console switched to the new REST surface with pagination and retry semantics.