They're using SQL transactions in their trade engine. That brings an awful lot of speed limitations.
transactions are important, unless you wants to lose data.
Oh I know. There's also some famous questions on stackexchange from (?) bitcoin-24 people:
http://stackoverflow.com/questions/15026825/php-mysql-how-to-prevent-two-requests-update and we know how that all turned out.
The financial / big-iron folks spend a lot of money on doing this fast. The sky's the limit. eg: Battery backed ram (search: nvdimm) is just one more iteration. IBM still make wheelbarrow loads money on this.
But the moment you start doing this sort of thing on commodity hardware you start running into limits like this. Somebody measured 37 transactions per second as their limit. That almost sounds like there's a conventional HDD in their trade engine's processing system somehow.
There's some numbers on random writes per second at
http://en.wikipedia.org/wiki/IOPS - there's a very large spread of performance ranging from HDD and low end SSD through the really expensive stuff. The range is from ~100 operations per second for HDD through nearly 10 million/sec on a fusionio card. That's a spread of 100000x between slowest and fastest.
Personally, I've had great luck with the stec zeus ram / iops devices. The differences in database throughput that involve transactions relative to generic hardware are profound.
I should know better than to drop a 1-line quip on a topic that's not so simple. It would have ben better to say that the transaction throughput is heavily dependent on their back-end hardware if their trade engine is operating at the SQL transaction level.
There's other ways to do this sort of thing but that's an entirely different topic. And orders of magnitude more work and harder to get right.
