Limits

Ably can scale effortlessly as your business grows.

Limits exist in order to minimize the impact on service due to accidental or deliberate abuse of your applications. They also provide a level of protection to consumption rates if abuse does occur. If you're on the correct package for your applications and use case, then hitting a limit should be an infrequent occurrence.

Limit types

Some limits are tied to a package type. For example, the length of time that you can store messages for is dictated by which package you are on, from 1 day on a Free package up to 1 year on an Enterprise package.

Other limits are more technical in nature. For example, the number of channels that a single realtime connection can be attached to, or the rate at which a single connection can publish messages.

Others still are precautions against high message consumption. For example, the number of clients that can be present on a single channel. This is because clients can change state very rapidly and the number of messages generated can be high. An example of this would be 200 clients subscribed to presence events on a channel and all of them join and leave the presence set within a few minutes. This would result in the following messages:

• 200 presence messages published for the enter event.
• 200 x 200 (40,000) messages subscribed to for the enter events.
• 200 presence messages published for the leave event.
• 200 x 200 (40,000) presence messages subscribed to for the leave event.

This highlights the potential for 80,400 messages to be sent in a very short space of time on a single channel. There are options for mitigating this such as utilizing server-side batching. Contact Ably to discuss increasing this limit if you think it's necessary for your use case.

View limits

1. Log in to your account.
2. Select Limits from the Account menu.

To view any limits that you have previously hit, click view recent limits notifications.

Exceeding a limit

If you exceed the limits of your package then it likely means that your app is performing well, and Ably won't penalize your success by blocking usage for the majority of limits. Normal service will continue to function beyond the limit, up to a point, for certain limits. However, Ably will contact you to let you know that you need to upgrade your package to accommodate your increased usage.

Limits will come into force either because there isn't any buffer on them, or because you have exceeded the buffer. Exceeding the limit depends on the limit:

• Count-based limits: only a set amount of resources can be in use simultaneously. This means that any usage in excess of that limit will be restricted until existing resources are removed, such as the number of concurrent connections, or concurrent channels.
• Rate-based limits: the rate at which resources can be used, expressed as their frequency per second. Usage in excess of a rate limit can be rejected locally, such as a publisher trying to publish at a rate in excess of the publish rate per channel. The publisher will have any publish attempts in excess of this rate rejected and have an error code returned. Other rate limits apply rate suppression across your account when exceeded. For example, if the limit for publishing messages into a queue is exceeded by twice the rate, then each message will have a 50% chance of being rejected. The suppression probability is continuously updated based on the publishing rate.

Email notifications are sent out when you are nearing a limit, as well as when you have exceeded it. You will also see these notifications in your account dashboard and can view any limits that you have previously exceeded.

Application limits

Application limits relate to the quantity of resources that can be created per account.

Message limits

Message limits relate to the number, rate and bandwidth of messages consumed across you account. Message count limits and data transfer (bandwidth) limits are enforced separately - exceeding one does not affect the other.

Channel limits

Channel limits relate to the number, rate and membership of channels on your account.

Why concurrent channel limits exist

Unlike many other realtime platforms, Ably's architectural design ensures delivery of a high quality of service and continuity for clients across changing network conditions and datacenter conditions (such as scaling events, network disruption or hardware failures).

In order to achieve 99.999% uptime, guaranteed message delivery, and reliable message ordering, Ably's system design can be considered "stateful". Every channel in the system is maintained by at least two nodes 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 nodes in the system allows Ably to:

• Maintain message ordering for each client publishing messages by using regional (datacenter) serial numbers, ensuring all messages arrive globally in the order they were published
• Resume connection state recovery for clients that became disconnected by checking the serial numbers of the last received message by that client and retrieving all messages from RAM stored for that channel
• Handle channel failure or intentional migration of channels between nodes without any loss of continuity

The channel state that Ably maintains comes at a cost in terms of CPU and primarily RAM within the cluster. This is because every open channel is managed by at least two nodes and all messages published are stored in RAM on at least two nodes for a period of time. When clients connect to Ably using multiple datacenters and attach to shared channels, the number of server nodes managing these shared channels increases, with a corresponding increase in the number of copies of messages in RAM.

Therefore, to provide the realtime platform-as-a-service economically to all customers, Ably charges customers based on the number of peak concurrent channels they use and imposes limits for package types. The peak channel limit is not the total number of channels created over time, but instead is the total number of channels simultaneously active at any point in time. Channels that are no longer in use (no clients attached and no messages being published) are closed automatically by the Ably platform.

Connection limits

Connection limits relate to the realtime connections made to Ably from your account.

Integration limits

Integration limits relate to the rate and concurrency of webhooks, queues and Firehose.

API limits

API request limits are the maximum number of REST API requests, Control API requests and token requests that can be made to Ably.