Event-Driven vs Time-Driven Trading Systems

The way a trading system checks market conditions can affect how the strategy behaves, how much processing it performs and how accurately it matches the trader's intended workflow.

Two common approaches are event-driven and time-driven processing. An event-driven system reacts when something happens, such as a new price update or an order-status change. A time-driven system evaluates its rules at scheduled intervals, such as every second, every minute or whenever a new candle is completed.

Neither architecture is automatically better. The appropriate choice depends on the strategy, required timing, market data, platform and execution requirements.

What Is an Event-Driven Trading System?

An event-driven trading system reacts to events generated by the market, trading platform or connected application.

An event can be something such as:

• A new market price update
• A new tick
• A completed candle
• An order being filled
• A position being modified
• A connection status change
• A message received through an API

When the relevant event occurs, the system runs the logic associated with that event.

For example, a strategy may be designed to check a price condition whenever new market data arrives. If the condition becomes true and all risk rules are satisfied, the system can generate a signal or submit an order.

Simple Event-Driven Example

Imagine a strategy with this rule:

"Buy when price crosses above a specified resistance level."

An event-driven system can monitor incoming price updates and evaluate the crossing condition as the relevant market data changes.

The system does not need to wait for a fixed schedule if the strategy is designed to react to incoming events.

What Is a Time-Driven Trading System?

A time-driven trading system evaluates its rules according to a defined schedule or time interval.

For example, the system could run its strategy:

• Every second
• Every five seconds
• Every minute
• At the start of each candle
• At the close of each candle
• At specific times of the trading session

Instead of reacting directly to every market event, the system waits until its next scheduled evaluation.

Simple Time-Driven Example

Suppose a strategy only makes decisions at the close of every 15-minute candle.

There is little reason for the main strategy logic to evaluate every price update if the rules depend only on the completed 15-minute candle.

The system can wait for the scheduled evaluation point, calculate the required indicators and decide whether a trade should be taken.

Event-Driven vs Time-Driven: The Main Difference

The simplest way to understand the difference is:

Event-driven: "Run the logic when this event happens."

Time-driven: "Run the logic at this scheduled time."

The distinction may look small, but it can significantly affect the implementation of a trading strategy.

An event-driven architecture can be useful when the exact occurrence of an event matters. A time-driven architecture can be useful when the strategy only needs periodic evaluation.

How Event-Driven Systems Process Market Events

A typical event-driven workflow may look like this:

1. Market data or another relevant event arrives.
2. The system identifies the event type.
3. The relevant strategy logic is triggered.
4. Current conditions are checked.
5. Risk rules are evaluated.
6. A signal is generated if conditions are satisfied.
7. An order may be submitted.
8. The system receives an execution response.
9. Position-management logic continues to respond to relevant events.

This architecture can involve many events, so the system needs clear rules about which events should trigger which actions.

Example: New Tick Event

For a strategy that reacts to live price changes, each incoming tick may cause the system to evaluate a price condition.

However, not every strategy needs to process every tick. If the strategy is based on completed candles, evaluating every tick may add unnecessary processing and create behaviour that does not match the intended rules.

How Time-Driven Systems Process Strategy Rules

A time-driven workflow is more schedule-oriented.

For example:

1. Wait until the scheduled evaluation time.
2. Retrieve the required market data.
3. Calculate indicators.
4. Check entry conditions.
5. Check risk rules.
6. Generate a signal if conditions are satisfied.
7. Execute or report the signal.
8. Wait for the next scheduled evaluation.

This approach can be easier to reason about when the strategy has a clearly defined evaluation interval.

Which Strategies Suit Event-Driven Architecture?

Event-driven processing can be suitable when the strategy depends on a specific event or a change that should be detected as it happens.

Examples may include:

Price-Level Strategies

A strategy that reacts when price reaches or crosses a defined level may benefit from event-based processing.

Order and Position Management

Some systems need to react when an order is filled, rejected or modified.

For example, after an order is executed, the system may need to update position-management logic.

Real-Time Signal Processing

Strategies that depend on incoming market events may require event-driven processing to evaluate conditions as relevant data arrives.

External API Events

A custom trading application may need to react when an external system sends a message, signal or status update.

The exact implementation depends on the platform and integration being used.

Which Strategies Suit Time-Driven Architecture?

Time-driven processing can be suitable when the strategy's decisions are intentionally tied to scheduled evaluations.

Candle-Based Strategies

If a strategy only makes decisions after a candle closes, scheduled or candle-based evaluation can be appropriate.

For example:

"At the close of every 15-minute candle, calculate RSI and moving averages and check for an entry."

The strategy does not need to make a new decision on every tick.

Periodic Portfolio Checks

A portfolio-management system may need to review positions or account information at a defined interval rather than reacting to every market update.

Scheduled Trading Rules

Some systems have rules that are explicitly time-based.

Examples include:

• Do not open new trades after a specific session time.
• Check the portfolio at a scheduled interval.
• Generate a report at the end of the trading session.

Hybrid Systems: Using Both Approaches

In many practical applications, the choice does not have to be strictly event-driven or time-driven.

A hybrid architecture can combine both.

For example:

• Use market events to detect price or order changes.
• Use candle-close events for indicator-based strategy decisions.
• Use scheduled checks for risk monitoring.
• Use order events to update position status.

This can provide a better match for systems containing several different types of logic.

The important part is to define which event or schedule should trigger each piece of functionality.

Example: Same Strategy, Different Architectures

Consider a simple moving-average strategy.

The rule is:

"Generate a signal when the 20 EMA crosses the 50 EMA on a 15-minute chart."

An event-driven implementation might receive market updates and monitor whether the conditions for a completed or developing crossover have occurred.

A time-driven or candle-driven implementation might wait until each 15-minute candle closes, calculate the indicators and then evaluate the crossover.

These implementations can produce different timing behaviour if the strategy does not clearly define whether the signal should be based on an intrabar condition or confirmed candle close.

This is why architecture should follow the strategy requirements rather than being selected simply because one approach sounds more advanced.

Advantages of Event-Driven Systems

Event-driven systems can offer several practical advantages.

Responsive to Relevant Events

The system can react when a defined event occurs rather than waiting for a fixed interval.

Suitable for Real-Time Workflows

They can be useful for applications where order updates, price changes or external messages need immediate processing.

Efficient Triggering for Specific Events

When designed correctly, the system can run particular logic only when the relevant event occurs.

However, the actual performance depends on the platform, implementation and event frequency.

Advantages of Time-Driven Systems

Time-driven systems also have practical benefits.

Predictable Evaluation Schedule

The strategy runs according to a known schedule.

Simple for Candle-Based Strategies

Strategies based on completed candles can be easier to structure around fixed evaluation points.

Controlled Processing

If the strategy does not require continuous evaluation, scheduled processing can avoid unnecessary checks.

Again, the appropriate interval depends on the strategy requirements.

Limitations and Risks

Neither architecture removes trading risk.

Event-Driven Risks

Event-driven systems can receive a high number of events, especially when processing frequent market updates.

The developer needs to prevent unnecessary processing, duplicate actions and unintended repeated signals.

Time-Driven Risks

A scheduled system may miss an intrainterval condition if the strategy requires immediate event detection.

For example, if a system checks price only once every minute, it may not capture a price movement that occurs and reverses between scheduled checks.

Timing Assumptions

The strategy must clearly define whether a condition is evaluated continuously, at a specific time, on candle close or after a particular event.

Ambiguous timing requirements can produce unexpected results.

Technical Failures

Both architectures can be affected by:

• Connectivity problems
• Platform interruptions
• API failures
• Server or VPS issues
• Programming errors
• Delayed or missing market data

Monitoring and error handling should therefore be considered during development.

Common Mistakes When Choosing the Architecture

Choosing Based on Technology Instead of Strategy

The architecture should support the strategy's requirements. A more complex architecture is not automatically better.

Ignoring Candle Confirmation Rules

If the trader wants signals only after candle close, the system should not treat an intrabar condition as a confirmed signal unless that behaviour is explicitly intended.

Checking Too Frequently

A strategy that only needs one evaluation per candle may not benefit from processing every market update.

Checking Too Infrequently

A strategy requiring event-level response can behave differently if it is evaluated only on a fixed schedule.

Failing to Define Trigger Conditions

Every major action should have a clear trigger.

For example:

• What event starts the evaluation?
• What event confirms the signal?
• What event closes the position?
• What event updates risk controls?

How to Choose Between Event-Driven and Time-Driven Processing

A simple decision process is:

1. Does the strategy need to react to a specific market or system event?

• If yes, event-driven processing may be appropriate.

1. Does the strategy make decisions only at fixed intervals or candle closes?

• If yes, time-driven processing may be appropriate.

1. Does the system contain both types of requirements?

• Consider a hybrid architecture.

1. Does execution timing materially affect the strategy?

• Define the timing requirements before development.

1. Can the strategy be clearly tested using the selected trigger model?

• Confirm this before implementation.

The goal is not to choose the most technically impressive architecture. It is to choose the architecture that accurately represents the trading workflow.

How Suyotech Supports Trading Software Development

Suyotech Solutions provides software engineering services for custom trading automation, including MT5 EA development, TradingView strategy development, broker API integrations and custom trading applications.

For each project, the architecture should be selected according to the strategy rules, execution requirements and technical environment rather than applying the same design to every trading system.

Conclusion

Event-driven and time-driven trading systems solve different processing problems.

Event-driven systems are useful when actions need to respond to defined market, order or application events. Time-driven systems are useful when strategy evaluation is intentionally scheduled around intervals or candle-based timing.

Some projects benefit from a hybrid approach that combines event-based reactions with scheduled evaluations.

The most important step is to define exactly when the strategy should evaluate its rules and what should trigger each action. Automation, regardless of architecture, does not guarantee profitable trading results. Proper requirements, testing, risk controls and monitoring remain essential.

If you are planning to automate a trading strategy, contact Suyotech Solutions to discuss the required workflow and software architecture.