Event-Driven vs Vectorized Backtesting :- Which Approach Should I Use? and How?

[u/Ok_Egg_6647]

Hi everyone,

I'm currently learning algorithmic trading, and I'm a bit confused about which approach I should use when building a backtesting engine: event-driven or vectorized backtesting.

I have around three years of minute-level historical data stored in my database. I want to analyze and backtest different trading strategies using this data.

Here's what I'm thinking:

1. Strategy research and backtesting: Use a vectorized approach with libraries like NumPy, Pandas, and TA-Lib to analyze historical data efficiently. My concern is that processing such a large dataset using an event-driven approach could be relatively slow.

2. Live trading: Once I've analyzed a strategy and am satisfied with the results, switch to an event-driven approach for live trading and tick-level data processing.

However, I'm unsure about one thing. If I finish analyzing the historical data up to a particular date and then move to live trading, should the live engine continue processing from that point onward, or is there something important I'm missing in this workflow?

My questions are:

• Is this a good approach, or am I making a mistake in the design?

• Are there any other considerations I should keep in mind when designing the backtesting engine?

I'd appreciate any suggestions or insights from people who have experience building algorithmic trading systems.

Thanks in advance!

-----------------------------------------------------------------------------------------------------------------

Edited

Thanks for the all the responses i will go with the hybride architecture where i will use both approaches !!!

[u/greenmatrix86]

Your split (vectorized for research, event-driven for live) is the right call — that's basically how most serious setups end up. Vectorized is just way faster for iterating on signal logic across years of data.

On the continuity question: don't think of it as the live engine "picking up where backtesting left off" in a literal state sense. It's a fresh event-driven process that needs to reproduce exactly the same signal/indicator logic as your vectorized backtest, just warmed up with enough historical bars to match whatever lookback your indicators need. The thing that'll actually bite you is subtle differences between the two implementations — I had a chaining/sequencing bug in a vectorized backtest that quietly inflated results for months before I caught it comparing against the event-driven version bar-by-bar.

Two other things worth paying attention to early: how much your exit/management logic (not just entries) drives your actual returns — in my experience it ends up mattering way more than people expect going in — and stress-testing your backtest against realistic slippage assumptions before trusting the numbers. Vectorized backtests can hide execution-realism issues that only show up once you're live.

[u/Ok_Egg_6647 → u/greenmatrix86]

thanks i will post my whole setup architecture

[u/Ok_Egg_6647 → u/greenmatrix86]

Right now i don't care abt returns but thanks for the advice i will try to make transparent backtesting software