What is Ledger Sharding?

Some examples of ledger sharding include:

• Geographic sharding: When partitions are based on geographic datamarkers (e.g., sharding for APAC vs EMEA, or across time zone regions of the US) .
• Account ID-based partitions: When a certain prefix or key determines which shard to send the data to.

Why Teams Choose To Shard a Ledger

Typically, organizations choose to shard their ledger for:

• Performance scaling: By distributing transactions, a ledger database can process more transactions simultaneously, improving throughput.
• Storage management: With each shard holding less data, there is reduced pressure on any single database.
• Reliability: Sharded databases can be more reliable, helping isolate faults. If one shard goes down, it doesn’t necessarily cause system-wide outages.

The Challenges of Sharding a Ledger

Sharding can also produce challenges, which may include:

1. Atomicity maintenance: When debits and credits span shards (e.g., in geographic sharding where money movement is international and possibly cross-currency), there is a risk of partial failures. The result is broken all-or-nothing guarantees.
2. Balance aggregation: Querying total balances across shards can be difficult because of asynchronicity. The risk is not being able to maintain accurate balance checks for compliance or reporting reasons.
3. Balance drift detection: The standard operating procedures that run checks for balance drifts, or mismatches, are hard to apply across partitions. The risk is subtle mismatches going unnoticed for longer, leading to issues in drift.
4. Operational complexity: Schema management and migration across shards is harder than if you use a single ledger. The risk is that it’s harder to debug a distributed ledger state, creating a potential for a major operational burden.

To Shard or Not To Shard

Not all ledgers use sharded databases. When to use a sharded ledger vs. when not to will depend on the context of a business. In general:

• Shard when:
  • A single ledger database hits performance ceilings
  • Accounts are naturally partitionable (e.g., split by region or business unit)
• Don’t shard when:
  • Transaction volume is still manageable on a single node or database without sharding in place
  • Cross-account atomicity is core to the product and isn’t able to tolerate distributed complexity.

Ledger sharding is powerful, but it doesn’t come without risks. While you can scale and have higher throughput with a sharded ledger database, it also introduces some risks, like partial failures or delayed balance aggregation. Teams need to balance performance needs against consistency and operational complexity.