Appearance
Comparable SDKs
Integrators arriving from peer real-time market-data SDKs find the same concepts under different names. This page is the one place in the documentation where peer products are named explicitly — the rest of the site describes the Kairos API on its own terms.
Client + session vocabulary
| Kairos | databento-rs | Bloomberg BLPAPI | Refinitiv RTSDK |
|---|---|---|---|
Client::connect((email, password)) | historical::Client::builder() / live::Client::builder() | Session::open | OmmConsumer::create |
client.live() (live namespace) | live::Client | Session::subscribe(...) | OmmConsumer::registerClient |
client.historical(start, end) (preview) | historical::Client | Session::sendRequest(...) | OmmConsumer::sendRequest |
client.replay() (preview) | — (no first-class replay) | recorded-feed playback | recorded-feed playback |
databento-rs splits the client; Kairos keeps a single Client and namespaces the bounded historical / replay paths via the historical(start, end) and replay() accessors with one shared engine link behind them. See the historical surface for the rationale.
Subscribe / query vocabulary
| Kairos | databento-rs | BLPAPI | RTSDK |
|---|---|---|---|
client.live().<analytic>([...]).on_event(cb) | live::Client::subscribe(...) | Session::subscribe(SubscriptionList) | OmmConsumer::registerClient(ReqMsg) |
client.historical(start, end).<analytic>([...]).on_event(cb) | historical::timeseries::get_range(...) | Session::sendRequest(HistoricalDataRequest) | OmmConsumer::sendRequest(HistoricalRequest) |
client.replay().<analytic>([...]).on_event(cb) | — | recorded-feed playback | recorded-feed playback |
.on_event is the terminal verb in every mode — it registers a typed callback that fires per emission and returns an EventSubscription handle. The distinction between the modes is lifetime, not the verb: a live subscription runs until unsubscribe(); a bounded historical / replay subscription ends after the last row. See the bounded-termination contract.
Output channel vocabulary
| Kairos | databento-rs | BLPAPI | RTSDK |
|---|---|---|---|
.on_event(cb) typed callback | dbn::Stream<dbn::RecordRef> | EventQueue / Event::Iterator<Message> | OmmConsumerClient::onRefreshMsg / onUpdateMsg callbacks |
| Live overflow ends the subscription; the handle goes inactive | dbn::Lag | SubscriptionFailure | OmmState::Suspect |
Every analytic delivers its output through .on_event. Where the peer frameworks split between a poll queue and a callback interface, Kairos surfaces one path — the typed callback fires per emission, closest in shape to the RTSDK onUpdateMsg consumer callback.
Backpressure semantics
| Framework | Live | Historical / Replay |
|---|---|---|
| Kairos | Drop-oldest on the live feed; a consumer that overflows the buffer ends its subscription. | Block the producer. |
| databento-rs | Drop with dbn::Lag notification. | Stream-paced; no producer blocking exposed. |
| BLPAPI | SubscriptionFailure event on slow consumer. | Request / response — no streaming backpressure. |
| RTSDK | OmmState::Suspect on slow consumer. | Snapshot mode is non-streaming. |
See the backpressure contract.
Recorded-replay vocabulary
| Kairos | databento-rs | BLPAPI | RTSDK |
|---|---|---|---|
Engine-staged dataset, driven through client.replay() (preview) | dbn::Decoder::from_path(...) | recorded-feed playback | recorded-feed playback |
| Parquet schema documented under tick parquet schema | dbn::Decoder::from_file(...) (compressed) | proprietary recording format | proprietary recording format |
The Kairos Parquet schema is defined in the tick parquet schema — Apache Arrow / Parquet (the canonical institutional file format), with the upstream-supported Rust implementations.
Concepts that have no direct peer
- Replay parity. Every analytic emits bit-identical output across live, historical, and replay modes. databento-rs records and replays raw wire data; the typed-analytic equivalent does not exist in the peer products.
- Deterministic ordering across live, historical, and replay modes. Every analytic sees ticks in source-data event-time order on every mode; replay over a captured dataset reproduces live-mode output byte-for-byte. BLPAPI's library-managed I/O thread is the institutional precedent for the single-ownership runtime that enables this guarantee.