retrystorm · Learn · Interview practice · Glossary · Components

Home › Interview practice › Ledger

Ledger

Credit tips to writers' balances without losing any, even when two arrive together for the same writer.

Design Inkwell Ledger, the service that credits writers for their readers' tips. Every request reads a writer's balance, adds the tip, and writes it back: a read-modify-write, with about 20 ms of work between the read and the write. Support is hearing that writers are missing money: two tips arrive together, both read the same balance, and one is lost.

What it does

  • Write: a tip is added to a writer's balance.

Workload

A steady 120 tips a second for 5 minutes, over 10 000 writers. A few popular writers get most of them: the busiest gets about 18 a second.

How to build it

The app servers and the 20 ms between the read and the write are fixed. The database is already on the canvas as ledger. As found, it runs transactions with no protection: nothing stops two of them from overlapping. It's on a large node, bought when the losses started, in the hope that a faster machine would fix them. You choose how it protects the balance, how many times an aborted transaction may try again, and the database's tier.

  • plain: no lock between the read and the write.
  • locking: the row is locked from the read to the commit, so overlapping transactions wait.
  • optimistic: no lock, but a commit checks that the row is unchanged, and starts over when it isn't.
  1. Build the path: the client, the load balancer, an app server, the database. Run it as it is, and look at the lost updates.
  2. Remove them without failing tips, and keep the busiest writer's wait short.
  3. Then give the database only the tier it needs.

Part of Chapter 31: Transactions and isolation.

About · Contact · Privacy · Terms of use