Unlike many other realtime platforms, Ably's architectural design ensures we can deliver a high quality of service and continuity for clients across not only changing network conditions for clients, but also changing conditions within our datacenters (such as scaling events, network or hardware failures).
In order to achieve our goal of 100% uptime, guaranteed message delivery (high QoS), and reliable message ordering, our system design can be considered "stateful" in that every channel in the system is maintained by at least two nodes in the system at any point in time, and in most cases many more nodes when clients connect through multiple datacenters (Ably ensures that a channel is maintained in each datacenter a client attached to that channel is active for performance reasons and to avoid single point of failure design issues). This active management of each channel by a node in our system allows us to, amongst other things, maintain serial numbering in a datacenter for all published messages on a channel and store messages in RAM for a period of time. This in turn allows us to:
- Maintain message ordering for each client that is publishing messages i.e. as we have a regional (datacenter) serial number, we can ensure that all messages arrive globally in the order they were published. Find out more about reliable ordering.
- Resume continuity for clients that became disconnected by simply checking the serial numbers of the last received message by that client and retrieving all messages from RAM that are stored for that channel. This means that clients that become disconnected for short periods (up to two minutes by default) can resume their connection and have everything they missed replayed to them. Find out more about connection state recovery.
- Handle channel failure or intentional migration of channels between nodes without any loss of continuity
Unfortunately the channel state that we maintain comes at a cost, both in terms of CPU and RAM within our cluster. This is because every channel that is open is managed by at least two nodes in the system and all messages published are stored in RAM on at least three nodes for a period of time. When clients connect to Ably using lots of different datacenters and attach to shared channels, the number of server nodes managing these shared channels, and in turn the number of copies of message in RAM increases significantly.
Therefore, in order for Ably to provide our realtime platform-as-a-service economically to all customers, we currently impost a default limit on the number of peak concurrent channels an account can have open. Please note that the peak channel limit is not the total number of channels created, but instead the total number of channels open and in use at any point in time. Channels that are no longer in use (there are no clients attached and no messages are being published) are closed automatically by the Ably platform.
Find out what default channel limits apply to each account type.
Increasing your channel limits
If your applications needs to have a higher number of concurrent channels than available by default on your account, then please get in touch to request a channel limit increase.
In most cases we do not charge to increase channel limits, unless we feel the ratio of channels needed versus the number of connections and messages purchased is excessive. For example, if a customer was purchasing the lowest number of messages available and 500 connections, yet required a 5,000 active channels, we would either charge separately for the channel use or suggest an upgrade of the number of connections to correct the channel to connection ratio imbalance.