Design a reusable event-driven framework for trading strategies

As a take-home project, build a framework for trading strategies, including an event-handling layer, that a team will keep using and extending after you hand it over. Team members write strategies; the framework delivers events to them, such as new market data, and carries out the orders the strategies decide to send. Describe and sketch the framework you would build: its architecture, its core interfaces, and the path of an event from its arrival to a strategy's decision to an order. Explain how the framework stays easy for the team to extend with new strategies, data sources and execution venues. ```hint One timeline Imagine market data and order fills reaching a strategy through separate paths, each with its own idea of the current time. Think about what that does to event ordering, and to whether a historical test agrees with live trading. ``` ```hint What the team will change most List what the team will add most often after you leave, such as new strategies, new data sources or new venues, and make each of those a small, isolated extension point. ``` ```hint Between a decision and an order Consider what should sit between a strategy deciding to trade and an order reaching a venue, so that a single faulty strategy cannot run away with positions. ``` ### Constraints and Clarifications - The take-home brief, as reported, asks only for a strategy trading framework with event handling that the team can continue to use. Asset class, data sources, venues, latency targets and language are not given: ask, or state your assumptions. - The deliverable is code that other people will maintain, so the interfaces, tests and documentation are part of the answer, not extras. ### Clarifying Questions - Should the same strategy code run in historical backtests, in simulated (paper) trading and in live trading? - Which events must be supported: quotes, trades, bars, order acknowledgements, fills, rejections, timers, others? - How many strategies run at once, and do they share market data subscriptions, positions or risk limits? - Is there a latency requirement, and does it outweigh ease of writing strategies? - Which language should the framework use, and is there existing market data or order-routing infrastructure to build on? ### What a Strong Answer Covers - An event model and a dispatch loop with a defined ordering guarantee and a single source of time - A small strategy interface that separates trading logic from data access, order execution and state keeping - Swappable adapters for data and execution, so the same strategy runs in a backtest and live - Order lifecycle tracking, positions, and pre-trade risk checks between strategies and venues - Isolation of failing strategies, logging and replay, configuration, tests and documentation for the team ### Follow-up Questions - A strategy's event handler throws an exception during a live session. What should the framework do with that strategy and its open orders? - How would you make a backtest deliver events in exactly the order a live session would have seen them? - One strategy needs to react within microseconds. What in your design would you change, and what would you give up? - How would two strategies share one market data subscription without a slow strategy delaying the other?