Satori Docs

Your definitive guide to subscribing and publishing live data

Concepts Direct link

RTM Concepts and Highlights

Apps and Streambots™ communicate via channels on RTM. Publishers send messages to a channel and channel subscribers receive those messages.  RTM is constantly up: buffering, replicating, optionally evaluating and transforming, and forwarding the messages from publishers to subscribers. Developers can write complex production applications without deploying any servers. Communication with RTM uses JSON data, over a WebSocket connection using TLS.

In addition to the core messaging functionality, RTM already supports a number of advanced features (and more are coming with time). Below are the highlights of the RTM concepts and features.


RTM has a well-defined, minimalist and documented API. Advanced users can communicate with RTM using this wire protocol over any compliant websocket implementation. RTM SDKs implement and encapsulate RTM API details.


Big data and scaling

RTM has been designed to scale independently in data volume and in number of concurrent client connections. This includes everything from being able to handle very high connection rates, to very high message rates, to very large numbers of actively connected clients.


Channel is a named stream of messages. 

Channel creation

Channel instances are automatically created by RTM on demand: upon the first subscribe or publish request to a specified channel name, RTM creates a corresponding channel instance.

Channel creation should not be confused with channel configuration. Channel configurations can be optionally set up in Dev Portal for a specific channel name or a group of channels; otherwise, default authentication role and default settings are used by RTM.

Channel subscription

Subscription is a client’s interest in messages published to a channel. In the simplest case, subscription establishes a client’s interest in all messages as they arrive to a channel. A client may also request a subscription to include past messages from the channel history. Additionally, a client can establish a viewed subscription: to receive filtered or transformed messages data.

Channel history

In addition to forwarding published messages to all subscribers, RTM also stores them. By default, channel messages are stored for 1 min while the last message - for 6 hours. History settings can be changed in Dev Portal.

A client can subscribe to a channel starting at a historical message; similarly, a client can request a read operation to retrieve messages published in the past.

High fanout

RTM is optimized to deliver channel data to millions of endpoints in real time. Even with millions of concurrent users of the same channel, 95% of the published messages are delivered in under 1 second.

High number of channels

RTM has been designed from the ground up to support application workloads that have millions of unique channels. Such workloads may be very common when unique channels are used to communicate with individual users or devices.


Both RTM protocol itself and user payload (messages) are in the familiar json format using UTF-8 encoding. (Binary support is coming soon)

Key/value storage

An application design may require dictionary-like storage, in addition to streaming messages: key/value pattern allows to organize, store and retrieve data (values) by keys. The underlying storage for k/v is still channels, meaning there is the same history and permissions settings and all other channel mechanisms. RTM provides k/v specific API tuned for dictionary-like message access.

See Read and Write PDUs in RTM API and the corresponding calls in the RTM SDKs.


A mode of channel subscription using an SQL-like language to filter and transform messages before they are sent to the subscriber.

Subscribers set and update their individual views on-the-fly by adding the view field in the subscribe request, using the familiar SQL syntax.

See Views.

Privacy & security

All communication through RTM is via secure connections. Developers can protect their data with channel permissions: publish and subscribe (akin to read and write) roles on the specific channels or channel namespaces (group of channels unified by a common prefix).  

See Authentication and Dev Portal

Reliable data delivery

RTM allows an application to control reliability of data, managed independently from the perspective of publishers and subscribers. These guarantees allow for at least once and at most once delivery, with exactly once semantics available when used appropriately. Publishers can use acknowledgements to retransmit data, while maintaining correct ordering of events. Subscribers control how they read from a channel and how they resume the subscription in case of disconnects or other failures (using channel position).


RTM communication is done over WebSocket protocol. WebSocket is a de facto standard for general purpose persistent reliable bi-directional network communication because of its efficiency and simplicity.