Double-Entry Ledger Service for Marketplace Wallets and Payouts

The problem with tracking money in a normal database table

Most student and startup marketplaces store money as a single balance column on a user row and run UPDATE balance = balance - 500 when something is bought. It works in the demo. It breaks the first time a payment webhook arrives twice, two checkout requests race each other, a refund lands after a payout, or an accountant asks what a seller's balance was on the last day of the quarter. At that point nobody can explain where the money went, because the system kept the current number and threw away the history.

Every serious payments company solves this the same way: a double-entry ledger, where money never appears or disappears, it only moves between accounts, and every movement is an immutable record. Stripe has written about its internal Ledger system for tracking and validating money movement, and Uber has written about LedgerStore, its immutable store for money events. Small marketplaces, wallet apps, school fee portals and ride or delivery startups in Pakistan and elsewhere need the same correctness without building a payments team first.

What already exists and the gap

• TigerBeetle is an open source database built only for double-entry accounts and transfers, very fast and heavily tested, but it is a new piece of infrastructure a small team has to run and learn.
• Modern Treasury Ledgers and Fragment offer ledgers as a hosted API, priced and designed for funded fintech companies.
• Accounting packages such as Xero or QuickBooks keep books for humans, not a real-time API that a checkout flow can call a thousand times a minute.

The gap is a small, well-tested ledger service that runs on plain PostgreSQL, which a three-person startup already knows how to operate, with the marketplace flows (holds, splits, refunds, payouts) already modelled.

What you build

A standalone ledger service with a clean API and one demo marketplace that uses it.

• Accounts have a type (asset, liability, revenue, expense), a currency and an optional non-negative rule.
• Transactions have two or more entries that must sum to zero, an idempotency key, a timestamp and metadata linking them to an order or payout.
• Holds reserve funds at checkout, then capture or void them later, the same authorise-then-capture shape card networks use.
• Queries return current balance, balance as of a timestamp, and the entry history behind a balance.
• The demo marketplace is a thin web app where a buyer pays, the platform takes a fee, the seller is credited, a refund reverses it and a payout batch runs weekly.

The technically interesting part

The hard problem is correctness under concurrency and retries. You must show three things to your evaluators. First, idempotency: the same request replayed after a timeout creates one transaction, not two, including when the retry arrives while the first attempt is still running. Second, no overdraft: two parallel captures against a seller account with 1,000 in it cannot both succeed if each needs 800. Third, invariants hold forever: the sum of all accounts is zero and every balance equals the sum of its entries.

Compare at least two concurrency strategies, for example SELECT FOR UPDATE on the account rows versus optimistic version numbers with retry, and measure how each behaves when one popular seller account becomes a hotspot. Property-based tests are your strongest evidence here: generate thousands of random operation sequences, including duplicates and failures, and check the invariants after every step.

How to evaluate it

• Correctness: zero invariant violations across at least 100,000 generated operations, with the test seed recorded so anyone can rerun it.
• Idempotency: a retry-storm test that fires each request 5 times concurrently and proves exactly one transaction per key.
• Throughput and latency: transactions per second and p95 latency for spread-out accounts versus a single hot account, under each concurrency strategy.
• Audit: reconstruct any balance at any past time and show it matches a replay of the entries.
• Usability: two developers outside the team integrate the demo checkout using only your API docs; record where they got stuck.

Suggested plan

1. Weeks 1 to 3: read the Stripe and Uber ledger posts and the TigerBeetle docs, write the data model and the invariants on one page.
2. Weeks 4 to 8: accounts, balanced transactions, idempotency keys and the property-based test harness.
3. Weeks 9 to 12: holds, reversals, balance-as-of queries and the nightly zero-sum check.
4. Semester 2, weeks 1 to 5: the demo marketplace flows and payout batches.
5. Weeks 6 to 9: concurrency strategy comparison and load tests.
6. Weeks 10 to 14: documentation, external developer test and the final report.

Path to a product

The first customer is a local marketplace, school fee platform or wallet startup that currently keeps balances in a single column and has already had one reconciliation scare. Sell it as an open source core with a paid hosted version or a support contract. A realistic model is a monthly fee per environment plus a setup engagement to migrate existing balances. Scale by adding reconciliation importers for common banks and wallets, which is where most operations teams spend their time.

Scope warning

Do not move real money, integrate a live payment gateway or hold customer funds: use a sandbox or simulated gateway. Do not build a general accounting package with invoices and tax. Do not add a blockchain; an append-only table with constraints gives you everything this problem needs.

Learn what you need on Sefism

• System Design roadmap : consistency, idempotency and hotspot handling are the core of this project.
• Backend cheat sheet : transactions, isolation levels and API design in one place.
• Stripe Engineering Blog : primary reading on how a payments company tracks money movement.
• PostgreSQL Documentation : row locks, constraints and isolation levels you will rely on.
• Stripe Documentation : see how a mature API models idempotency keys and authorise-then-capture.

Get help with this idea

This is a strong project for anyone aiming at backend or fintech roles, but it lives or dies on the invariants you choose to prove. If you want a second opinion on scope, stack or how to evaluate it before you pitch it to your supervisor, bring your draft proposal and we will pressure-test it together. You build it; the guidance is on the decisions.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session

New here? Create a free account first.