Design a Low-Latency Execution System

Follow one order through its life. Somewhere inside the firm a quoting or hedging decision fires, and it hands the execution system an instruction: buy 500 of a symbol at a price. Before that instruction goes anywhere near a venue the system has to prove it is safe. The price is no typo three ticks wide of the market. The position it would open is inside the limit, and the firm has the exposure headroom for it. It will not cross the firm's own resting order. Only then does the order leave on the wire. Microseconds later the venue answers with an acknowledgment, then fills, or a reject, or a cancel confirmation, and the system folds each of those back into the firm's picture of what it holds. The whole loop is the hot path, and the budget is microseconds for the checks and low microseconds to milliseconds for the round trip.

Name the shape of the problem before drawing a box. This is not a web request that can lag a little and be retried whenever. An order is a real instruction to move money in a venue the firm does not control, and once it is on the wire it cannot be unsent. The checks in front of it are not optional. Every message in and out has to be recorded precisely enough to replay the session exactly, later, for both compliance and debugging. So the ranking is clear: correctness and determinism come first, latency is the constraint they have to live inside, and raw volume is the part that scales out cleanly. Get that ranking right and the design mostly writes itself.

The Jane Street angle

Jane Street runs no separate whiteboard system-design round, so this design lives inside a conversation, not on a scaling diagram. For most software-engineering candidates "design" shows up as a coding exercise the interviewers extend one requirement at a time. For senior and low-latency-systems roles it also shows up as architectural reasoning woven into the project discussion, and this execution path is the canonical thing that conversation reaches for.