Source: https://databento.com/docs/api-live/basics/recovering-after-a-disconnection


### Recovering after a disconnection

When reconnecting to the gateway, clients should [resubscribe](https://databento.com/docs/api-live/client/subscribe.md) to all desired symbols.
In order to avoid missing data after a reconnection, there are three main approaches to recovery:
- Natural refresh
- Intraday replay
- Snapshot (MBO only)

The best approach to recovery will depend on the client's use case and specific needs.

#### Natural refresh

To recover via natural refresh, clients can resubscribe to all desired symbols without the `start` or `snapshot` parameters.
This means no data will be replayed, and the client will immediately receive the newest messages upon subscribing.

This recovery approach is the fastest (since there's no data replay), and is recommended for stateless schemas such as MBP-10, in cases where the client only requires the current state of each instrument.

#### Intraday replay

To recover via intraday replay, clients should store the last `ts_event` and the number of records received with that last timestamp, per schema and instrument.
The `ts_event` and record count should be continuously updated when processing incoming records.

When reconnecting, clients should set the `start` parameter of the resubscription to the lowest stored `ts_event` across all instruments for that schema.
The gateway will then send all records starting from that timestamp (including records with the exact same `ts_event`).

The resubscription may lead to duplicated data being sent to the client.
Clients who require that each message is delivered exactly once are instructed to:
- Discard all records with a lower `ts_event` than the stored one for the corresponding instrument
- Discard the first N records with the same `ts_event` as the stored one for the corresponding instrument, where N is the number of records already seen with that `ts_event` prior to the disconnection.
  This is important in case there are multiple events with the same `ts_event` and the client is disconnected halfway through processing those events

This recovery approach is recommended when clients require the uninterrupted history of records for the desired schema (for example, when using the Trades schema to construct a ticker tape).
However, this approach can take a longer time to synchronize with the live stream, depending on how long the client was disconnected.

For the CBBO and BBO schemas where filtering is based on `ts_recv`, clients should store the last `ts_recv` per instrument.
When reconnecting, clients should set the `start` parameter of the resubscription to the lowest stored `ts_recv` across all instruments.
The gateway will then send all records starting from that timestamp (including records with the same `ts_recv`).
Since CBBO and BBO are stateless schemas, you should always refer to the most recent record per instrument.

#### Snapshot (MBO only)

When resubscribing to the MBO schema, clients can request a [snapshot](https://databento.com/docs/conventions/mbo-snapshot.md) to receive the current state of the book after a disconnection.
This eliminates the need to replay the missed messages and leads to faster synchronization with the live stream.
This recovery approach is generally recommended over intraday replay when using the MBO schema.