Standby Push¶

Standby Push is a resilience pattern where a standby push path is prepared next to the main publish direction. While the primary path is healthy, the backup stays idle and only activates on primary failure or severe degradation.

How Standby Push works¶

In this scenario an origin or other publishing node has two egress directions:

• primary push;
• standby push.

The common combination is Standby Push with Twincast: primary and backup ingest already exist, and Standby Push lets you move onward publication between them quickly.

Typical diagram:

flowchart LR
    primaryStreamer["Primary streamer"] --> multicast["multicast"]
    multicast --> backupStreamer["Backup streamer"]
    primaryStreamer --> primary["Primary push"]
    primary --> edge["edge servers"]
    backupStreamer --> standby["Standby push"]
    standby --> reserve["backup edge path"]

While the primary push is healthy, the backup path is not actively delivering (or stays passive). On primary failure the standby path activates.

Handover time is often under a second. Twincast + Standby Push is the fastest switching option but needs a LAN with reliably low latency.

For Standby Push, the backup streamer must receive multicast from the primary streamer.

When to use it¶

Standby Push fits when:

• you need a backup publication path without constant double load;
• resilience is required on outgoing push;
• you want less traffic than Double Publish;
• the backup must be pre-provisioned but used only on failure;
• you pair with Twincast for fastest switchover;
• legacy gear should remain backup without reconfiguration.

What this scenario provides¶

Benefits of Standby Push:

• backup publish path without always sending on both;
• more bandwidth-efficient than Double Publish;
• fast activation of the backup path;
• stronger delivery resilience if the primary egress fails;
• legacy equipment can serve as backup without changing its role.

Limitations and requirements¶

For a correct Standby Push design, define:

• criteria to move from primary to backup push;
• standby activation time;
• rules to return to primary after recovery;
• monitoring of primary and backup publish paths;
• a low-latency LAN between primary and backup;
• multicast delivery from the primary streamer to the backup.