How to Scale a Ledger, Part VI

Note: This post is the sixth chapter of a broader technical paper, How to Scale a Ledger.

Advanced Topics

The ledger described in this paper is immutable, double-entry balanced, resilient to concurrent writes, and fast to aggregate Account balances—and still, it will only get you so far. As product requirements become more complex and the throughput required by your system increases, the architecture will start to strain.

Here are four major areas of improvement we’ve invested in for our Ledgers API that a truly global, scalable ledger management process will need:

1. Account Aggregation

For many products and reporting needs, aggregating at the Account level is not sufficient. For example, you may want to see combined Transactions and balances for all “revenue” Accounts.

On the product side, you may want to implement sub-accounts—groupings of Accounts that, from the user’s perspective, share a balance and Transactions.

We believe the best way to model these scenarios is with a graph structure we call Account Categories. See our documentation for Ledger Account Categories.

2. Transaction Search

Building Account statements, performing marketplace payouts, and showing real-time Account summaries all require different searches of Transactions. The search may be by date ranges, require custom sorting, and efficient pagination.

Additionally, you may need fuzzy search, for example allowing credit card customers to search their Transaction history for a restaurant name rather than the precise statement description. Performant search is a constantly moving target as the volume of Transactions increases and the types of queries change. It requires careful choice of architecture and ongoing index tuning, along with latency and throughput monitoring.

3. High-throughput Queues

The best fintechs in the world easily surpass 5,000 QPS on their ledgers. Depending on the problem domain, a common architecture at that scale is a queue for processing recorded Entries. This queue must be designed to accept unlimited QPS for writes.

4. Account Sharding

At a global scale, the throughput and data storage requirements of a ledger can’t be accommodated by a single database. Some ledgers scale by migrating to an auto-sharding database like Google Spanner or TiDB. But more commonly, ledgers implement their own sharding strategy, typically at the Account level.

Devising a strategy that can implement double-entry atomicity and can aggregate efficiently across Accounts is very challenging when Accounts aren’t colocated in the same database.

Next Steps

We hope this paper has given a good overview of the importance of solid ledgering and the amount of investment it takes to get right. This guide can be used to ensure your ledger meets the requirements of correctness and performance to move money confidently on behalf of your business or your customers.

If you want a ledger that meets these requirements today and can scale with you, check out Modern Treasury Ledgers.

Read the rest of the series:

Part I | Part II | Part III | Part IV | Part V