Once sequencing is done, the matching algorithm can run with some parallelism.

For example, Order A and order B might interact with eachother... but they also might not. If we assume they do not, we can have them processed totally independently and in parallel, and then only if we later determine they should have interacted with each other then we throw away the results and reprocess.

It is very similar to the way speculative execution happens in CPU's. Assume something then throw away the results if your assumption was wrong.

▲

noitpmeder 3 days ago | parent [-]

Off the cuff, id expect this leads to less improvement than you might think. The vast majority of orders, especially orders arriving in sequence close to one another, are likely on a small set of extremely liquid symbols, and usually all for prices at or near the top of the book for those symbols.

Happy to discuss more, might be off the mark... these optimizations are always very interesting in their theoretical vs actual perf impact.

▲

eep_social 3 days ago | parent [-]

in high scale stateless app services this approach is typically used to lower tail latency. two identical service instances will be sent the same request and whichever one returns faster “wins” which protects you from a bad instance or even one which happens to be heavily loaded.

	▲	noitpmeder 2 days ago \| parent \| next [-]
		I'm not sure I follow. In this instance we're talking about multiple backend matching engines... Correct? By definition they must be kept in sync, or at least have total omnipotent knowledge about the state of all other backend book states.
	▲	lanstin 2 days ago \| parent \| prev [-]
		And the tail latencies are wildly improved with each addition dup. Has to be idempotent of course.