Process exchange prints, volume checks, and client orders
VoleonSoftware Engineer · OnsiteLast updated
This problem tests your ability to manage high-frequency time-series data using sliding windows and stateful order tracking to enforce trading constraints.
Problem Statement
You are building a matching and execution engine for an exchange. You need to process a stream of events and execute a pending order based on specific volume-participation constraints.
Input
market_prints: A list of events(timestamp, price, volume). These represent actual trades occurring on the exchange.order: A tuple(target_volume, max_participation_rate).window_size: An integer representing the look-back duration (in milliseconds) for volume calculations.
Rules
- Participation Rate: At any time
T, your execution volumeEmust satisfyE <= max_participation_rate * V, whereVis the total market volume in the interval[T - window_size, T). - Pricing: You must execute your order at the latest known
pricefrom themarket_printsstream. - Goal: Return the total volume successfully executed and the total cost incurred given the sequence of incoming market prints.
Interface
def process_trades(market_prints, order, window_size):
# market_prints: List of (timestamp, price, volume)
# order: (target_volume, max_participation_rate)
# window_size: int
pass
Example
market_prints = [(100, 10.0, 50), (150, 10.1, 100), (250, 10.2, 50)]order = (100, 0.1),window_size = 200
At T=100, total volume in window is 0. Execution = 0.
At T=150, market volume is 50. Max exec = 0.1 * 50 = 5. Price = 10.1. Remaining order: 95.
At T=250, market volume (in [50, 250]) is 100 + 50 = 150. Max exec = 0.1 * 150 = 15. Price = 10.2. Remaining order: 80.
Constraints
market_printsare sorted by timestamp.- Time complexity should be
O(N)whereNis the number of prints. - Handle edge cases where the
window_sizespans multiple prints or no prints.
Hints
Hint 1
Use a sliding window technique (like a queue or two pointers) to maintain the sum of volumes within the last `window_size` duration.
Hint 2
As you iterate through the prints, keep track of the most recent price seen so far to use as the execution price.
Hint 3
Ensure you only count volume that occurs *before* the current event when calculating the participation limit for the current step.
Follow-up questions
- How would you modify the system if the execution engine had a latency of X milliseconds, meaning you only see prints up to T-X?
- What data structures would you use if you needed to support this for thousands of different symbols simultaneously?
- How does the choice of `window_size` impact the volatility of your order execution?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.