Event Driven Trading Systems Interview Guide
Event-driven trading systems interview guide for market data events, order events, state machines, ordering, concurrency, and testing.
Candidates discussing asynchronous trading infrastructure and stateful systems.
Events change state
Market data updates, order acknowledgments, fills, cancels, timers, and risk events can all trigger state transitions. The design should say which component owns each state.
Ordering is a real design issue
Asynchronous systems can process messages in surprising orders. A careful answer discusses sequence numbers, timestamps, queues, and how inconsistent state is avoided.
Concrete example
A fill might arrive before an internal cancel confirmation. The order state machine should handle that sequence without double-counting position or assuming the order disappeared.
Testing needs deterministic paths
Replayable event streams, small state-machine tests, and injected failures help verify behavior that is hard to reason about from diagrams alone.
Common mistakes
Candidates often draw boxes and arrows without explaining state ownership. Event-driven systems succeed or fail based on state transitions, ordering, and recovery behavior.
Practice the pattern
Use the LeetQuidity curriculum and calibration to turn this topic into a focused practice plan.