Designing Trading Software for Restart Recovery

A trading application does not stop being responsible for its state just because the process stopped running. Crashes, server restarts, deployments, network failures and unexpected shutdowns can all interrupt an automated system while an order is pending or a position is open.

Restart recovery is therefore a core part of trading software architecture. A reliable application should not simply start the strategy again and assume everything is normal. It should first discover what happened while it was offline, compare that information with its stored state and only then resume trading.

Why Restart Recovery Matters

A running trading system usually keeps information about signals, orders, positions, risk limits and strategy state. Some of that information may be stored in memory, while important information should also be persisted.

A restart can create a mismatch between what the software remembers and what actually exists at the broker or execution venue.

For example, the application may have sent a Buy order immediately before a crash. If the process stopped before recording the broker response, the application cannot safely assume that the order failed.

The Main Recovery Problem

The central question after restart is:

What is the actual trading state right now?

The answer may require checking:

• Open positions
• Pending orders
• Recently completed orders
• Order statuses
• Strategy state
• Risk and trade counters
• Last processed market event
• Unresolved signals
• Application errors

Only after this information is reconciled should normal strategy processing resume.

Separate Internal State from External State

Trading software usually has two important sources of truth.

Internal state is what the application has recorded. This can include strategy variables, signal records and order mappings.

External state is what the broker or execution system reports about actual orders and positions.

These two states can temporarily disagree.

For example, the application may record `ORDER_PENDING`, while the broker reports that the order was filled. Recovery logic should detect the difference and update the internal state.

Why Memory Alone Is Not Enough

Variables held only in application memory disappear when the process stops.

Important information should therefore be persisted in a suitable database or storage system, depending on the application's requirements.

Useful persistent records can include:

• Strategy identifier
• Symbol and timeframe
• Signal identifier
• Order identifier
• Position identifier where available
• Order status
• Quantity or lot size
• Entry and exit details
• Processing timestamps
• Error or retry status

Persistence does not remove every failure risk, but it gives the application information from which recovery can be performed.

Startup Reconciliation

Startup reconciliation is the process of comparing the application's stored state with current external trading state when the system starts.

A practical sequence can be:

1. Start the application in recovery mode.
2. Load persisted strategy and order state.
3. Connect to the relevant broker or execution service.
4. Retrieve available open orders and positions.
5. Retrieve relevant recent order history.
6. Match external records with internal records.
7. Resolve differences.
8. Rebuild required strategy state.
9. Check risk and operational conditions.
10. Resume normal market processing.

This is more reliable than immediately enabling order placement after the application starts.

Reconciling Orders

Orders need careful treatment because a restart can happen at any stage of their lifecycle.

An order might be:

• Pending
• Accepted
• Rejected
• Partially filled
• Filled
• Cancelled
• Expired, depending on the venue and order type

The application should use the execution system's available identifiers and statuses to determine what actually happened.

The Timeout Problem

Consider this sequence:

1. Strategy generates a Buy signal.
2. Application submits the order.
3. Broker receives the request.
4. Network connection fails.
5. Application does not receive the response.
6. Application restarts.

The system must not interpret the missing response as proof that the order failed.

During recovery, it should check the broker's current and relevant recent order information before attempting another order.

This principle is important because uncertainty should trigger reconciliation, not blind retrying.

Reconciling Open Positions

Positions are another critical part of recovery.

Suppose the internal state says:

`position_open = false`

but the broker reports an open position.

If the application resumes trading using the incorrect internal state, it could create an unintended second entry.

The recovery process should therefore compare relevant positions by symbol, account and strategy context where the execution architecture supports that mapping.

Position Ownership

Multi-strategy systems need additional care.

If several strategies trade the same account or symbol, the application needs a reliable way to identify which position or order belongs to which strategy.

Possible approaches include:

• Strategy-specific identifiers where supported
• Internal order mappings
• Separate accounts
• Strategy-level position records
• Clearly defined allocation rules

The correct approach depends on the execution environment and platform capabilities.

Recovering Strategy State

Strategy state goes beyond orders and positions.

A strategy may track:

• Current trading mode
• Number of trades taken
• Daily limits
• Last processed candle
• Current setup
• Entry stage
• Exit stage
• Averaging level
• Cooldown status
• Risk status

If this state is lost during restart, the strategy may behave differently after recovery.

For example, a strategy that allows one trade per completed candle should know which candle it already processed. Otherwise, the first market update after restart could be mistaken for a new event.

Persist Important State

Not every temporary variable needs permanent storage.

The design should identify which state is required to reproduce correct behaviour after a restart.

A useful rule is:

If losing a value could cause a duplicate order, incorrect position handling or a different strategy decision, that value deserves explicit recovery consideration.

Handling Missed Market Events

A system that was offline may have missed market-data events.

The correct recovery behaviour depends on the strategy.

For candle-based strategies, the application may be able to retrieve historical candles and determine which completed candles were missed.

For event-driven strategies, recovery may require an event log, broker history or another reliable source.

For some strategies, missed events should not be replayed at all. For others, they may be essential.

Define Replay Behaviour

The strategy specification should clearly state:

• Which events can be replayed
• Which events must be ignored after downtime
• How far back recovery should look
• Whether signals are valid after a restart
• Whether a missed exit condition needs special handling

There is no universal recovery rule. It must match the strategy's intended behaviour.

Safe Resume Sequence

A useful design is to separate recovery from normal trading.

During recovery:

1. Disable new order submission temporarily.
2. Load persisted state.
3. Connect to external systems.
4. Reconcile orders and positions.
5. Resolve pending states.
6. Rebuild strategy state.
7. Process required missed events.
8. Run risk and safety checks.
9. Mark recovery as complete.
10. Enable normal strategy execution.

This reduces the chance that the application starts placing new orders before it understands its existing state.

Common Restart-Recovery Mistakes

Starting Trading Immediately

Enabling the strategy before reconciliation can produce decisions based on stale state.

Treating Local State as the Only Truth

The broker's current order and position state must be considered when determining actual execution state.

Blindly Retrying Failed Requests

A timeout does not necessarily mean the request failed.

Ignoring Partial Fills

Partial execution can require different position and risk handling from a complete rejection or fill.

Losing Strategy Counters

Trade limits, cooldowns and processed-event identifiers can affect future decisions and should be recoverable when required.

No Recovery Testing

Restart logic should be tested deliberately, not only discovered during a production incident.

How to Test Restart Recovery

Useful test cases include:

• Restart before order submission
• Restart immediately after submission
• Network failure during order processing
• Restart with an open position
• Restart with a pending order
• Partial-fill scenario
• Rejected order scenario
• Missed candle events
• Multiple strategy instances
• Database unavailable during startup
• Broker connection unavailable during startup

The objective is to verify that the application reaches a known and safe state before normal execution resumes.

How Suyotech Approaches Trading Software

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

For systems that must run continuously, recovery design can be included in the architecture through persistent state, startup reconciliation, order tracking and controlled resume logic.

Conclusion

Restart recovery is not simply a server-management feature. It is part of the trading application's correctness.

A robust system should know what it was doing before the interruption, what happened externally while it was unavailable and what actions are safe after it reconnects.

Persistent state, order reconciliation, position checks, missed-event handling and a controlled startup sequence can make automated trading software more predictable after failures.

These techniques do not make a trading strategy profitable and cannot guarantee future trading results. They help the software continue operating according to its defined rules instead of making assumptions after an interruption.

If you are building trading software that needs reliable restart and recovery behaviour, contact Suyotech Solutions to discuss the required architecture and software workflow.