[lmm]

It is, and I acknowledged that. But it gives a sense of the scale involved. Just as there are very few websites/apps that need to handle, what, 2000 requests/second (and simultaneously don't intend growing by more than a factor of two or so), systems that need that kind of performance in any other field are similarly rare.

[dogma1138]

Not really, it’s also not necessarily not needing to grow but not everything can scale in the same manner as Netflix or Facebook.

Financial systems especially trading platforms need to ensure market fairness they also need to have at the end a single database as you can’t have any conflicts in your orders and the orders need to be executed in the order they came in across the entire system not just a single instance.

This means that even when they do end up with some micro-service-esque architecture for the front end it still talks to a single monolithic database cluster in the end which is used to record and orchestrate everything.

[lmm]

That is indeed one case where a large single-node database makes a certain amount of sense (though it's not the only solution; you need a globally consistent answer for which orders match with which, but that doesn't have to mean a single database node. Looking at the transaction numbers I'd assume that e.g. the busiest books on NYSE must be multi-node systems just because of the transaction rates). But fundamentally there are what, 11 equity exchanges in the US total (and less than half of those are high-volume). And the market fairness requirements are very specific to one particular kind of finance; they're not something that would be needed in healthcare, general enterprise, or most financial applications. Like I said, niche.