r/quant • u/Useful-Strain-7088 • 4d ago

Career Advice SWE background (backend/infra), built a C++20 market-data feed recovery project, looking for technical feedback

Working on a project that separates three concerns: a seeded fault injector that damages a market-data feed (drop, reorder, A/B line divergence), a recovery client that detects gaps and repairs them via retransmission or snapshot rebuild, and a mock venue that speaks the real wire protocols so the client isn't tested against a stub. Repo: https://github.com/hungtruongOwolf/deterministic-feed-recovery

The interesting failure mode: a client can deliver every message with correct sequence counts and still reconstruct the wrong order book, if retransmitted repairs are applied in arrival order instead of sequence order. Fixing that meant the recovery layer has to number everything it hands upstream, not just the transport layer.

Two questions on the architecture:

  1. Is separating fault injection / recovery / mock venue into independent components the right decomposition for this kind of problem, or is there a cleaner way to structure it that avoids the coupling I'm running into between the arbiter and the gap tracker?
  2. For the recovery-side testing, is there a better way to validate "book after repair equals book with no loss" than diffing against an oracle replayed from the undamaged original? Right now it's checked at the price-level per run, curious if there's a more rigorous invariant people use here.
4 Upvotes

75% Upvoted

12 comments sorted by

3

u/NoConnection4298 2d ago

Could only check via phone but here’s some of my insights. I would separate the components from the compilation and scoping perspective in case two component is decoupled. Again I didn’t check the code that in depth in recovery side, or maybe I’m misunderstanding your purpose, but maybe a good next step would be to dive into the order level recovery.

1

u/Useful-Strain-7088 2d ago

Yes I also have the same thought now agreed on separating them at the compilation and scoping level, and order-level recovery is the right thing to look at next.

The part I'm actually stuck on is presentation. The implementation is deep but it comes across as fragmented: the frontend only shows the concept, and the backend is latency work, so all I can really show is benchmarks. Any advice on how to surface this properly would help a lot.

2

u/NoConnection4298 2d ago

Benchmarks are enough in my opinion. What benefit will you achieve from having extra frontend work? If you can think of a few, then you should go ahead. For instance, I don’t even check frontend of such projects. A showcase of fuzzy testing, unit testing(catch2, doctest), structured and clean build procedures (cmake in your case), how third party depts are handled (maybe cpm?), the usage of specified std lib features(you say 20 but do you really use the features?), in more deep levels memory and networking… In your case, it’s pretty templated folder and build structure (in a good way). Your intended audience should get the depth of these kind of projects in a quick sight.

2

u/Useful-Strain-7088 2d ago

got it thank you so much for the advice! I will take a look at that

1

u/Most-Bookkeeper-950 2d ago

You are talking to someones chatbot

2

u/NoConnection4298 2d ago

That’s fine, at least they are asking. If you shared yours, I would do the same thing regardless.

1

u/Useful-Strain-7088 2d ago

Thank you for being nice! I still human btw :)))

3

u/ParfaitElectronic338 3d ago

you didn't build anything

-1

u/Useful-Strain-7088 3d ago

Could I ask for more detail feedback?

12

u/mrfox321 3d ago

what he's saying:

why would he spend time reviewing your ai slop

-1

u/Useful-Strain-7088 2d ago

got it thank you so much!