Discrete Event Simulation

In DES, the system state remains constant between events and only updates when an event is processed. This mirrors real-world exchange behavior where a strategy's logic is triggered by market data events (trades, quotes) rather than continuous polling.

• Event: An instantaneous occurrence that changes the system state
• State: The collection of variables describing the system at any point
• Transition: The atomic update triggered by event processing

Example: A limit order submission is an event; the order book depth is the state; the fill confirmation is a subsequent event.

The simulation engine maintains a future event list (FEL) implemented as a priority queue, ordered by event timestamp. The engine repeatedly extracts the next chronological event and advances the simulation clock to that precise moment.

• Min-heap data structures provide O(log n) insertion and extraction
• Tie-breaking rules resolve simultaneous events deterministically
• Event cancellation handles order modifications and deletions

This mechanism ensures that strategy logic executes in the exact temporal sequence it would encounter in live trading.

Unlike continuous-time simulation, DES advances the clock directly from one event timestamp to the next, skipping idle intervals. This variable time advance mechanism is computationally efficient because no processing occurs during empty periods.

• Next-event time advance: Clock jumps to the earliest pending event
• Fixed-increment alternative: Used for periodic tasks like portfolio rebalancing
• Wall-clock synchronization: Optional mode for real-time simulation testing

The deterministic clock enables exact reproducibility when combined with fixed random seeds.

DES models the system as entities (orders, positions) flowing through resources (liquidity, capital) that have finite capacity. Entities queue for resources, and the simulation tracks utilization, wait times, and throughput.

• Entities: Dynamic objects that move through the system (market orders, limit orders)
• Resources: Constrained assets with limited availability (available volume at price level)
• Queues: Ordered waiting lines when resources are unavailable (order book priority)

This abstraction maps directly to limit order book dynamics where resting orders compete for incoming liquidity.

The simulation engine continuously collects time-persistent and tally-based statistics during execution. Time-persistent metrics (like position value) are integrated over time, while tally metrics (like fill prices) are recorded at discrete events.

• Time-weighted averages: Integrate state variables over simulation time
• Event counters: Track frequency of fills, rejections, and cancellations
• Confidence intervals: Generated via independent replications with varying seeds

These statistics form the raw data for computing Sharpe ratios, drawdowns, and other performance analytics.

A backtesting DES defines a taxonomy of event types, each with a dedicated handler. The event dispatcher routes incoming events to the appropriate handler based on type, enabling modular strategy logic.

• MARKET_DATA: New trade or quote from the exchange feed
• SIGNAL: Strategy-generated trading decision
• ORDER: Submission, modification, or cancellation of an order
• FILL: Confirmation of a matched order execution

This event-driven architecture decouples market data ingestion from strategy evaluation, mirroring production trading system design.

A simulation architecture where strategy logic executes only when a market event occurs—such as a new trade, quote, or order book update. Unlike vectorized approaches that process entire arrays at once, event-driven engines maintain a priority queue of timestamped events and process them sequentially.

• Replicates real-time trading engine behavior
• Essential for modeling path-dependent strategies
• Enables accurate fill simulation and latency modeling

A behavioral design pattern that manages the deterministic transition of orders between discrete statuses within a backtesting engine. Each order progresses through states such as PENDING → ACKNOWLEDGED → PARTIALLY FILLED → FILLED or CANCELLED based on market events.

• Prevents invalid state transitions
• Enables precise fill simulation logic
• Critical for audit trail reconstruction

A critical simulation safeguard ensuring strategies only access information that would have been available at the historical decision point. Discrete event simulation enforces this by processing events in strict chronological order and maintaining point-in-time data snapshots.

• Prevents using restated financials before publication
• Blocks access to future price data in indicator calculations
• Essential for realistic performance estimation

The logic determining whether a simulated order executes based on available historical volume, order book depth, and queue position. In discrete event architectures, fill simulation checks market conditions at the exact timestamp of order arrival.

• Models partial fills when volume insufficient
• Accounts for queue priority in limit order books
• Integrates with slippage models for realistic execution

The ability to reproduce an identical backtest result by fixing random seeds and event timestamps. Discrete event engines achieve this through strict event ordering and deterministic state transitions, ensuring full auditability.

• Enables debugging of specific execution paths
• Required for regulatory compliance documentation
• Supports parameter sensitivity analysis with controlled variables

A strategy characteristic where the current trading decision is contingent on the sequence of prior events and executions. Discrete event simulation captures this by maintaining precise state across every event transition.

• Critical for strategies using trailing stops or dynamic position sizing
• Requires exact order fill sequencing
• Cannot be accurately modeled in vectorized backtests