Event-Driven Backtesting & Research Platform

Problem

Research code often starts with a useful shortcut: calculate features, signals, and returns in a single table. That can be efficient for exploration, but it also makes event ordering, point-in-time availability, execution latency, and portfolio state easy to blur together.

The design challenge is to preserve a fast research loop while making each assumption visible enough to test.

Approach

The proposed system uses an event clock as the spine of the simulation. Market-data events update the information set; strategy events may create intents; risk rules accept, resize, or reject them; execution events create simulated fills; and portfolio events update cash, positions, and exposures.

Research configuration is immutable for a run. Dataset versions, parameters, cost models, and code revisions are captured in a run manifest so an evaluation can be reproduced.

Architecture & proposed technologies

Python coordinates the domain components. Parquet provides columnar research datasets, PostgreSQL stores run metadata, and Polars supports analytical transforms. Containerized workers are a possible isolation boundary for parallel runs; the design does not require distributed infrastructure for small workloads.

• Data adapter: emits timestamped, point-in-time market events.
• Strategy interface: consumes state and produces intent without mutating the portfolio.
• Risk layer: applies position, exposure, and order constraints before execution.
• Execution model: makes latency, fees, spread, slippage, and partial fills explicit.
• Accounting ledger: derives cash, holdings, P&L, and exposure from immutable transactions.

Key technical decisions

A monotonic event sequence resolves ties when timestamps are equal. The accounting ledger is the source of truth rather than a mutable summary table. Execution assumptions are injected as policies, making a simple close-price fill model visibly different from a spread- and volume-aware model.

The design favors deterministic replay before horizontal scale. Concurrency is introduced at the run level, where separate simulations do not share mutable portfolio state.

Validation process

Validation would begin with unit tests for position accounting, fees, corporate actions, and event ordering. Golden scenarios with hand-calculated outcomes would check full runs. Property tests would assert ledger balance, cash reconciliation across fills, fees, and transfers, and the absence of position changes without corresponding transactions.

Any strategy result would be explicitly hypothetical. A proper evaluation would disclose the test period, benchmark, data source, fees, spread, slippage, latency, liquidity constraints, and all selection decisions. This case study presents no backtest result or performance metric.

Limitations & status

This representative architecture was prepared for this portfolio; it is not a claim of a deployed platform or client engagement. It does not include exchange-specific microstructure, tax treatment, borrow availability, survivorship-bias-free security masters, or a live broker adapter. Those requirements would materially change scope and validation.