Katkat

Process exchange prints, volume checks, and client orders

VoleonSoftware Engineer · Onsite

Last 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

  1. market_prints: A list of events (timestamp, price, volume). These represent actual trades occurring on the exchange.
  2. order: A tuple (target_volume, max_participation_rate).
  3. window_size: An integer representing the look-back duration (in milliseconds) for volume calculations.

Rules

  • Participation Rate: At any time T, your execution volume E must satisfy E <= max_participation_rate * V, where V is the total market volume in the interval [T - window_size, T).
  • Pricing: You must execute your order at the latest known price from the market_prints stream.
  • 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_prints are sorted by timestamp.
  • Time complexity should be O(N) where N is the number of prints.
  • Handle edge cases where the window_size spans 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?