Ably architecture design
      Back to home
      1. Ably FAQs
      2. Ably architecture, transports, and security
      3. Ably architecture design

      Why does Ably have concurrent channel limits?

      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 disruption or hardware failures).

       

      In order to achieve our goal of 99.999% 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 active in each regional datacenter that has attached clients, 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

       

      Naturally the channel state that we maintain comes at a cost, in terms of CPU and primarily 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 two 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 there is a corresponding increase in the number of copies of messages in RAM.

       

      Therefore, in order for Ably to provide our realtime platform-as-a-service economically to all customers, we charge customers based on the number of peak concurrent channels they use, and impose hard limits for free packages.  Please note that the peak channel limit is not the total number of channels created or used over time, but instead is the total number of channels simultaneously active 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.  

       

      Next steps: