> Its not like you can throw together some trading system with an eventually consistent datastore in the back. Loosing a couple of trades without an audit trail crashes markets.
That's not consistency, though, that's durability. Consistency in banking is basically the part where you don't allow people to spend money twice. That can be "eventual" and violating it can be OK under some circumstances, like when your bank issues you an overdraft (and applies a fee) or when your airline sells too many seats.
So the eventually consistent data store in the back is fine... as long as it's durable and as long as you're willing to invest man-years of effort in understanding the implications of your selected consistency model so that you don't screw it up and can perform operations which are compliant with some set of business rules that the business understands and approves of, naturally.
A trading platform must have a 1:1 mapping of buyer to assets when trades are agreed. You cannot have a situation where two people buy the same share, as it requires unwinding. A trade must be atomic.
traders want to see all the bids/asks of the whole market. Otherwise you'll effectively have a random assortment of tiny markets under one supposedly united trading platform.
Thats the other thing, trades need to be reversible. There is a good correlation between massive trade volumes and the need to reverse transaction. Having an eventually consistent model is just not going to work.
Being overdrawn is not eventual consistency. The act of an overdraft is not a failure of a bank to properly account for your balance, its a deliberate business move to generate cash.
So no, its consistency, one price, one bid, one ask.
The concept of overdrafting is a combination of modern business rule and ancient technological limitation (dating back to before-computers when accounting was manual and checks and checkbooks were also big deal, which his hella-eventually consistent). It can still serve as a useful metaphor, regardless.
But if you care about operating the EXCHANGE ITSELF then your allusion to the audit trail is a bit of a red herring, isn't it? In fact, the data store itself becomes pretty irrelevant for the live trade-matching - presumably you shard just the hell out of your data, keep the working set in RAM, keep most of your stuff colocated in the same place and just solve for availability by doing something crazy and hardware-intensive like having hot spares for everything.
That's not consistency, though, that's durability. Consistency in banking is basically the part where you don't allow people to spend money twice. That can be "eventual" and violating it can be OK under some circumstances, like when your bank issues you an overdraft (and applies a fee) or when your airline sells too many seats.
So the eventually consistent data store in the back is fine... as long as it's durable and as long as you're willing to invest man-years of effort in understanding the implications of your selected consistency model so that you don't screw it up and can perform operations which are compliant with some set of business rules that the business understands and approves of, naturally.