Digital wallet (with a parallel to Pix)

01 · CONTEXT

From aggregated balance to ledger

In Square's account, triggering a bank settlement required computing the merchant's balance, which meant an expensive group-by aggregation per merchant. In addition, because it was just a SQL database, nothing prevented payments from becoming inconsistent.

Stripe, for its part, built the Ledger, an immutable and auditable log, as the system of record for its financial data.

02 · DOUBLE ENTRY

Entries that net to zero

Double-entry accounting requires stating not only which financial state change occurred, but also why. By the accounting equation Square uses, every transaction, called a journal entry, must net to zero: every cent lost is offset by a cent gained.

The stated requirement is consistency: it must not be possible to transact with the database in a way that results in an illogical financial transaction.

Each book holds a balance that summarizes that book's changes. In Square's example, computing how much to pay a merchant is a single row in the database and needs no complex grouping or aggregation.

1. The diagram starts at the wallet app, connected to the wallet service.

2. The diagram highlights the service and the journal entry storage: each entry declares what changed and why, and a row is added each time the books change value.

3. Journal entries and the debit and credit entries only receive inserts.

4. The book holds a balance that summarizes its changes, and that current balance is updated on every operation.

03 · IMMUTABILITY

Correcting without deleting

At Square, the sets of journal entries and book entries are effectively append-only and immutable once written.

At Stripe, the Ledger is, at its core, an immutable log of events. Transactions that have been posted cannot be deleted or modified, and past state can be reconstructed by processing the events up to that point.

Faced with an error, Square does not update the data: it writes a new entry that corrects the previous one. The book's balance is adjusted, but there is always a trace of what happened in the system.

04 · RECONCILIATION

Verifying that the balances close

Stripe represents the producing systems as state machines and describes their behavior as a logical flow of funds, the movement of balances (events) between accounts (states). The Ledger is based on double entry, the standard method for ensuring that all the money in a system is accounted for by balancing credits and debits.

1. The diagram shows a producing service with its database and the event ledger.

2. The producing systems are modeled as state machines, and the Ledger describes their behavior as a flow of funds.

3. The clearing metric measures the fraction of the ledger that is zeroed out as it should be in steady state.

4. The completeness check ensures that every ID in the producer's database has a corresponding event in the ledger.

5. For timeliness, it measures the difference between data entering the platform and arriving at the ledger.

6. The Ledger relies on proactive alerts to surface problems and proposed solutions.

If the release event is never published or has the wrong id, the Ledger does not offset the associated account's balance. Even with billions of transactions, a single missing, late, or incorrect transaction immediately creates an accuracy problem detectable by a simple query.

05 · SCALE AND INTERVIEW

Ledger storage and scale

Square reports considerable effort on a SQL database sharding scheme and says it had to deal with cross-shard transactions, in which two merchants could exchange value.

For Books, Square chose Google Cloud Spanner, a fully managed, globally distributed SQL database, which freed it from worrying about sharding and from the burden of maintaining a database.