Oh hi! It's going on - and indeed, your question prompted the note.
As one might expect, the original scope was ... insufficient. The exchange team have taken over the responsibility for new customer-facing stream API. The current one is starting to bump into a number of edges that were not obvious two years back.
I can however happily say that the first major migration is complete: the team moved settlements from the old Erlang-based system to C++. (The final remnants of the old component were removed from our tree less than a month ago.) This doesn't necessarily sound like much, but it required a lot of walltime due to multi-month shadow deployment. Since the last time we visited the topic, they have also migrated the market state updates from their old "teed off" feed to a dedicated subsystem with higher throughput and better reliability - though not without hitches.
A kafka client library bug caused them (and our customers) quite a lot of grief. The postmortem for that was rather uninteresting, even if the visible impact was bad enough. When the solution to a problem is "downgrade client library, wait until upstream fixes are in place, avoid local delta", the technical aspect scores quite high on boring.
Another component, a customer-facing "recent orders cache" subsystem written in C++ now augments its Erlang predecessor. A service designed to run in a K8S cluster from inception is obviously an easier deployment and maintenance target.
The two really big ones left are the actual exchange core ("matching engine") and market maker trading API. Both under active development. It'll probably be some months still before the new trading API can take over. And it will be a long road to validation, but the matching engine has also recently graduated to an early shadow mode, feeding off of the the order flow spigot.
As one might expect, the original scope was ... insufficient. The exchange team have taken over the responsibility for new customer-facing stream API. The current one is starting to bump into a number of edges that were not obvious two years back.
I can however happily say that the first major migration is complete: the team moved settlements from the old Erlang-based system to C++. (The final remnants of the old component were removed from our tree less than a month ago.) This doesn't necessarily sound like much, but it required a lot of walltime due to multi-month shadow deployment. Since the last time we visited the topic, they have also migrated the market state updates from their old "teed off" feed to a dedicated subsystem with higher throughput and better reliability - though not without hitches.
A kafka client library bug caused them (and our customers) quite a lot of grief. The postmortem for that was rather uninteresting, even if the visible impact was bad enough. When the solution to a problem is "downgrade client library, wait until upstream fixes are in place, avoid local delta", the technical aspect scores quite high on boring.
Another component, a customer-facing "recent orders cache" subsystem written in C++ now augments its Erlang predecessor. A service designed to run in a K8S cluster from inception is obviously an easier deployment and maintenance target.
The two really big ones left are the actual exchange core ("matching engine") and market maker trading API. Both under active development. It'll probably be some months still before the new trading API can take over. And it will be a long road to validation, but the matching engine has also recently graduated to an early shadow mode, feeding off of the the order flow spigot.
In a nutshell: plumbing. So much plumbing...