Session Failover And Warm Standby Gateways

A single order-entry gateway is, eventually, going to fail — a hardware fault, a software crash, a network outage between the firm and the exchange. For most firms, the response is manual: notice the outage, restart the gateway, log back on, and reconcile any orders that were resting at the time. That process can take minutes, and minutes with resting orders unmonitored and unmanageable is an unacceptable risk for anyone running significant size or trading at speed.

Cold, warm, and hot standby

A cold standby gateway is one that's built and ready but not running — bringing it up still takes real time, just less than building one from scratch. A warm standby gateway is already running, already logged on (or ready to log on instantly), and already receiving the same market data and, critically, kept synchronized on FIX sequence numbers and order state via drop copies or direct replication from the primary — so that when it takes over, it isn't starting from zero. A hot standby goes further still, processing everything the primary does in real time so the two are essentially interchangeable at the moment of failover, at the cost of running (and paying for) two fully active systems continuously.

Warm standby is the common middle ground: it costs less to run than a hot standby, but the sequence-number and order-state synchronization means that when it takes over, it can resume the session close to where the primary left off rather than needing a full reconnection and reconciliation cycle from scratch.

What failover actually requires

Failover only works cleanly if the standby has an accurate picture of what was resting and what sequence number the session was on — this is exactly why session state (via drop copies or shared session logs) has to be kept current on the standby continuously, not synced only after a failure is detected. A standby that's "up" but out of sync on sequence numbers will simply trigger a resend cascade at the worst possible moment, adding delay rather than removing it.

Firms also have to decide, and test, how failover is triggered: automatically on a missed heartbeat, or only after a human confirms the primary is actually down, since an automatic failover that fires on a brief network blip can itself cause more disruption than the outage it was meant to protect against.