CAP theorem says you can't have consistency, availability, and partition tolerance all at once during a network partition. It's easy to nod along to that in the abstract. It's a different thing entirely when you're staring at a design doc for a payment system and realizing partition tolerance isn't a choice — networks partition whether you want them to or not — so the real decision is C or A.
The Tradeoff I Made
For the ledger's core balance writes, I chose consistency over availability. If the system can't guarantee a write is correctly reflected everywhere, I'd rather it reject the request than accept one that could later contradict itself. For read-heavy, non-critical paths — like transaction history lookups — I lean toward availability, since a slightly stale read of your last 10 transactions isn't the same category of problem as a wrong balance.
What I'd Do Differently
In hindsight, I'd have made this CP/AP split explicit in the architecture from day one instead of discovering it component by component. Different parts of the same system can — and probably should — sit on different sides of the tradeoff depending on what's actually at stake if they get it wrong.