A crypto exchange must decide which operations require strong consistency and which can be eventually consistent. Where should the line be drawn, and what is the cost of drawing it wrong in each direction?
Show the full answer Hide the answer
The line
Strong consistency where a stale read allows an action that cannot be undone. Everything else can lag.
| Operation | Model | Why |
|---|---|---|
| Wallet balance at the moment of order placement | Strong, single writer per account | A stale balance permits spending money that is not there, and the counterparty has already been paid |
| Order book matching | Strong, serialised per instrument | Two matches against the same resting order is not a display bug, it is two trades |
| Withdrawal authorisation | Strong, plus an idempotency key | Irreversible and external |
| Portfolio valuation | Eventual, seconds | Display only |
| Trade history and statements | Eventual, minutes | Nobody acts on it in real time |
| Price charts and market stats | Eventual, aggressively cached | High volume, low consequence |
| Notifications | Eventual, best effort | Delivery is not the record |
Cost of drawing it wrong in each direction
Too much strong consistency is the more common error in fintech and the more expensive one operationally: every read hits the primary, the primary becomes the bottleneck, latency rises for everyone including the critical path, and availability drops because a partition now blocks reads that never needed to be correct. Teams then add caching in front of a design that assumed no caching, which reintroduces staleness without the reasoning.
Too little is rarer, catastrophic, and usually invisible until a burst. Two concurrent withdrawals against a lagging balance replica both pass validation. The loss is real money and the discovery is a reconciliation break days later.
The mechanism that makes it tractable
Per-account serialisation. Route all writes for one account through one owner — a partition, a shard, a single-threaded actor — and you get strong consistency for the operations that need it without a global coordination bottleneck, because accounts are independent. The system is strongly consistent within an account and eventually consistent across accounts, which matches the business invariants exactly.
The exception is the order book, where the invariant is per instrument rather than per account, so that is the partition key there. Choosing the partition key to match the invariant is the whole trick, and it is a decision that is very expensive to change later.