Disaster recovery mechanism in FIX gateway

Imported from previous forum

I need to know what should be the ideal scenario to handle the disaster recovery mechanism in exchange side FIX engine?

Say for a connection, 1000 New Order Single were confirmed (I am not counting the Order Cancel-Replace Requests). Now say FIX gateway goes down due to hardware failure and restarted. Should a connection receive 1000 Execution Reports on reconnection with ExecTransType=3(Status)?

I need to know what should be the ideal scenario to handle the disaster recovery mechanism in exchange side FIX engine?

Say for a connection, 1000 New Order Single were confirmed (I am not counting the Order Cancel-Replace Requests). Now say FIX gateway goes down due to hardware failure and restarted. Should a connection receive 1000 Execution Reports on reconnection with ExecTransType=3(Status)?

You should offer your members the option of having all their orders pulled from the market in the event of disconnection, in which case you should send a bunch of unsolicited cancels when the session is restored.
None of the exchange facing systems I have built or worked on will deduce fills that have occurred during an outage from a status message, I would want to see an exec rpt for each fill.

If you say confirmed, then those 1000 ER were already sent. Why send them again? A gateway going down and being restarted hardly qualifies for an exchange side disaster. For that, you need to lose a complete data center which does NOT come back up and you have to switch to the backup data center.

The FIX gateway is typically just a hop to the core system and should reconcile with the latter to make sure it has everything it had before its crash and any updates (core system might have continued to operate). If it does not know whether it has sent out the 1000 confirmations to the member firm (or has further updates), it can use ExecType D=Restated, similar to a restatement of open orders in the morning or at the end of the day.

I need to know what should be the ideal scenario to handle the disaster recovery mechanism in exchange side FIX engine?

Say for a connection, 1000 New Order Single were confirmed (I am not counting the Order Cancel-Replace Requests). Now say FIX gateway goes down due to hardware failure and restarted. Should a connection receive 1000 Execution Reports on reconnection with ExecTransType=3(Status)?