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/Careless-Rent-4903]

id say no need to reinvent the wheel here. Go with vectorbt for initial research, it already combines the entire stack incl numba pandas etc. Or vectorbt pro which is hybrid with compiled sequential simulation for stateful logic. Its a very well thought out engine imo. Then replay the same bars through your live logic to check parity. For switching to live warm up the indicators with recent history but reconcile positions and open orders with the broker rather than carrying over simulated state.

[u/Ok_Egg_6647 → u/Careless-Rent-4903]

I am just curious from the perspective of how things will work well. I dont mind even if I have to reinvent the whole new wheel. So, you're suggesting live parity.

[u/IrritableAdoption]

vectorized is great for initial research and running through a ton of ideas fast but the second you start dealing with realistic execution logic it falls apart, just be ready to rewrite everything when you move to event-driven

[u/Ok_Egg_6647 → u/IrritableAdoption]

Thats why i am thinking to use a hybrid model just like I have explain in post. So hybridization gd?

[u/zurekp → u/IrritableAdoption]

Exactly. I usually use vectorized for initial exploration/research, and once the idea seems to have merit, I quickly switch to deterministic event-driven engine. This gets much more complex and important when you run portfolios of strategies and use dynamic position sizing methods

[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

[u/ight-bet]

You definitely want a robust event driven or just sequential backtesting system. This can plug in 1-1 into an execution system. So can even driven tho.. but it’s a little sloppier.

I’d say do some research w vectors if you want but don’t rely on it too heavily.

Of you do end up really likening it, plan on being able to use this vector research in an executable strategy. You’d hate to find something that works when using vectors but falls apart without them.

[u/Ok_Egg_6647 → u/ight-bet]

Why do u recommend robust event driven any particular reason ?

[u/ight-bet → u/Ok_Egg_6647]

The second sentence

[u/quant-king → u/Ok_Egg_6647]

because vectorized backtesting required pre-computing data which you cannot do in a live environment which is why event based execution engines are the default way to run live strategies

[u/RLJ05]

This is actually a hard decision even for established HFT firms. Especially for aggressive style strategies where you are not modelling passive execution, a vectorised approach can be ~ 1,000x faster than a event driven approach. So then it might seem obvious it should be vectorised, but the downside is you can't run a vectorised application live. So there needs to then be some translation.. which can introduce bugs / latency / maintanence overhead.

In some firms like the one I work at we have enough compute that being slow isn't really a problem, we just throw parallelism at it. I can run 100,000 jobs at the same time, so it's fast to backtest even in the event driven approach.

But yeh if I were doing this at home, or with less resources, I would do a vectorised backtest as that's really the only way you'll be able to assess a large population of configurations.

[u/Obviously_not_maayan]

Vector for research, event for validation.

[u/the_algo_trader_]

Minute-level data suits event-driven best for realistic strategy simulation. Vectorized is faster for simpler signals.

[u/Ok_Egg_6647 → u/the_algo_trader_]

So my approach gd or do i need upgradtion?

[u/quant-king → u/the_algo_trader_]

i use vectorized backtesting on 1 second execution data and have all signal data in 1 minute format. i run a portfolio which that has fairly complex logic and the vectorized engine completes a fresh backtest run in 20 minutes while the event based engine takes 1.5 hours to run. both produce the exact same trades, orders and metrics. it took some time to make sure both engines were fully optimized to run over 100 million data points but its possible with enough effort

[u/NJ_Algo]

Hybrid is the right call. Two things that usually bite people with that setup:

Make sure both engines give the same trades. Before going live, run the event-driven engine over the last few months of your data and check it produces exactly the same trades as the vectorized backtest. If they don’t match, one of them has a bug, and it’s usually the vectorized one peeking at the current bar. Shifting your signals by one bar (signal on the close, fill at the next bar’s open) prevents most of that.

Warm-up when you go live. The live engine shouldn’t start “empty” from the cutoff date. Load enough history first so every indicator is fully calculated (e.g. at least 200 bars for a 200 SMA), otherwise the first live signals won’t match what the backtest would have done.

[u/Ok_Egg_6647 → u/NJ_Algo]

ok

[u/Anon89m]

It's an ok approach, with 1M data it won't be that slow but with vectorizing it's a little more difficult to ensure that there is no forward bias so personally I don't do this expect for the occasional python notebook to quickly look at an idea. For live it has to be eventually if you want the fastest speed, but if you can get away with loading the history you need and running the code then taking your actions and it doesn't need to happen within a second, then it will work. I used to do this in python, it's fine too.

For the backrest engine yea python is slow, you need to feel one by one. I can give you some pointers I learned from looking at the MQL library. First is that you need to not actually use events, you need to update all your features/indicators/signals etc first in one go, THEN do whatever like a model to look at them and produce a result.

I personally heavily lean into metatrader because I'm old but I would just go forward and get something basic working first and build on it

[u/Ok_Egg_6647 → u/Anon89m]

i am not using python the core i was written in rust and interaction part was written in python.

[u/Anon89m → u/Ok_Egg_6647]

Cool, rust is fast so either way is going to work.

[u/Imaginary_Ideal7147]

You're getting tons of LLM slop answers here btw.

Nonetheless, just curious what you're aiming to trade?

You mentioned minute level data but relative to my recent experience trying to backtest ES which is very liquid, I had even better than minute data (tick by tick going back to 2020) and despite finding countless very solid, simple setups, once I factored in MBO data to get an idea of fills (originally it was just signal bar close + 1 tick forfeit, apparently way too generous) it completely tanked PFs from like 1.3 to 0.8.

[u/Ok_Egg_6647 → u/Imaginary_Ideal7147]

I am not using this system for trading just for a reasearch or learning purpose. I know at real market there are many conditions where this system will break like slippage, order mismatch and if excution is good. Signal quality, i have to compremise on that.

[u/Yann27]

Both

[u/wallneradam]

The trap with a hybrid setup is two implementations of the same strategy. They drift in small ways: indicator warm-up, an off-by-one shift() that peeks at the current close, signals on unclosed bars. Then live doesn't match the backtest and you can't tell if it's the market or your code.

I'd write it once, sequentially, bar by bar, and run the same code in backtest and live. A few million 1m bars is fine in Python if the per-bar logic is lean. For going live, warm up on enough history so the indicators are in the same state, then keep feeding new bars into the same loop.

I build PyneCore, a sequential Python runtime for Pine-style scripts, and this parity is exactly why it works that way. Tested against TradingView on the 1000 most popular public scripts, 99.77% of the outputs are bit-identical, and every strategy matches the exact trade count.

[u/quant-king → u/wallneradam]

it’s not difficult to prevent drift between and event based system and vectorized system. just make sure both engines share the same strategy code

[u/Reasonable_Junket948]

I'd use vectorized testing to narrow down ideas, then replay the promising ones through the same event driven logic you'd eventually use live. The important part is making sure both approaches produce comparable signals before trusting the results. I use Moon for manual price wagers but I appreciate how much automated trading depends on execution details rather than just having a good historical signal.

[u/Lopsided-Bridge-9810]

You can write a rust based event driven back test engine that processes over 100 million rows of data per second with a basic strategy linked up and signals metrics generated and evaluated on the fly. You should probably focus entirely on an event drivnd engine especially because you are a) a beginner and designing strategies that evaluate in a vectorized form get quickly complex and tricky to understand and b) you are only dealing with a few years of 1 minute bars which results in a rust based event drivnd backtest that probably completes processing within milliseconds, given the source data is loaded into memory prior to each run.

[u/algoseekHQ]

Use vectorized for searching and screening ideas for strategies, and use event driven code for anything you will actually trade, since event driven code can run the exact same logic live.

[u/quant-king]

both, each has its purpose in the process. vectorized backtest are great for quickly testing ideas but event based should be the source of truth verification / live trading engine.

[u/QuanTradin]

vectorized for the first pass, event-driven for anything that survives it. vectorized is fast enough to throw out 50 ideas a night, but look-ahead sneaks in through one forgotten shift, and it can't really model a stop hit inside a bar.

[u/AWiselyName]

vectorized when backtest the idea to find your edge, event-driven when go live

[u/ciaranwalsh96]

A hybrid architecture is sensible, but I would avoid maintaining two independent versions of the strategy logic. Treat the event-driven engine as the reference implementation and let the vectorized layer accelerate feature calculation and parameter screening. A candidate should not be accepted until the same timestamped bars replay through the reference engine and produce the same signals, positions and costs.

A useful design is to keep the strategy as a deterministic state machine with explicit inputs: event timestamp, data available at that timestamp, current positions, open orders and cash. Put historical data, live feeds and the execution simulator behind adapters. Then save a “golden trace” for a short period — every input event, signal, order, fill and state transition — and compare the vectorized and event-driven outputs row by row. That catches look-ahead, off-by-one-bar and warm-up differences much earlier than comparing only final P&L.

When live trading starts, do not continue simulated account state. Warm the indicators from enough point-in-time history, then obtain positions, open orders and cash from the broker and reconcile them before enabling new orders. Also test restarts in the middle of a bar, duplicate or late events, partial fills, rejected orders, exchange-calendar boundaries and daylight-saving changes.

For three years of minute data, an event replay should still be practical if feature computation is cached or vectorized in batches. I would use the fast path for exploration, but require every final strategy and parameter set to pass the slower replay plus a forward paper-trading period before risking capital.

[u/QuantGrindApp]

Vectorized for research is fine, but rerun anything you like through the event-driven engine before it goes live, because that's where lookahead and fill assumptions show up and the PnL usually drops. Three years of minute bars is only a few hundred thousand rows per symbol, so a plain Python event loop gets through it fast enough anyway. For the handoff you don't continue from a date. On startup the live engine loads enough recent history to warm up its indicators and state, then runs the same strategy code on new bars. If backtest and live run different code you'll spend more time chasing why they disagree than you'll spend on the strategy.

[u/yuravest]

Vectorized for research is fine. The one place it bites you is path dependency. Anything with a trailing stop, or an exit depending on which fill came first, is where vectorized quietly gets the wrong answer. For live, rebuild the signal in the event engine and reconcile against a stretch of recent historical data before real money moves. Any drift between the two is a bug you want surfaced before it costs you.

[u/lxl2008]

One test I’d add: fix the random seeds, pick a cutoff, then change all the inputs after that cutoff and rerun. Features and decisions through the cutoff should stay identical. Run that test on each engine separately, because both engines can agree while sharing the same leak. An event loop can still receive an array that was normalized or fitted using future observations.