Ably — what it is, a real-time Pub/Sub platform and how it works

What is Ably?

Ably is a cloud real-time platform founded in 2014 that provides infrastructure for real-time messaging. Unlike simple pub-services, Ably offers enterprise-grade delivery guarantees, a global network of points of presence (POP), and built-in state synchronization for millions of concurrent clients.

The platform is used in projects where delivery reliability is critical: financial tickers, logistics trackers, medical monitoring systems, and multiplayer games. Ably is built on its own distributed message broker technology, which replicates data across a global network of 15+ data centers.

According to the official Ably website (2025), the platform processes over 200 billion messages per month for 50,000+ active applications. Clients include Fortune 500 companies: Toyota (automotive telematics), HubSpot (CRM synchronization), Designity (collaborative editing).

Ably Architecture

Ably architecture is built on a distributed network of message brokers (routers) connected via high-speed channels. Each broker serves a subset of channels and replicates state using the Ably Protocol — a binary protocol over WebSocket optimized for minimal overhead. Clients connect to the nearest broker via DNS load balancing.

A key differentiator of Ably from competitors is the built-in global log, which stores message history for each channel. This allows new subscribers to receive not only new messages but also previous ones (replay), which is critical for auditing and state recovery after reconnection.

How Ably works

Ably interaction model follows the Publisher-Subscriber pattern with additional capabilities. The publisher sends a message to a channel via the Ably REST API or SDK. The message enters the global distributed log of the channel and is distributed to all subscribers through their active connections.

Transport layer — Ably supports multiple protocols: WebSocket (primary, with binary Ably Protocol), Server-Sent Events (for one-way reception), HTTP streaming (for constrained environments), and MQTT (for IoT devices). The client automatically selects the available transport with the lowest latency.

Each message goes through validation on the Ably side — API key signature verification, channel quota check, access rights. Validation occurs in 1–5 ms on the edge router, after which the message is replicated to the global log. According to the Ably technical blog (2024), end-to-end latency is under 65 ms for 95% of messages during intercontinental transmission.

Channels and subscriptions

Ably channels are named topics for message exchange. Each channel can have an unlimited number of subscribers, but for stable performance it is recommended not to exceed 10,000 per channel within one zone. Channels can be unidirectional (publishing from server only) or full-duplex (clients publish messages).

Ably channels and Pub/Sub model

Pub/Sub model in Ably extends the classic pattern with additional capabilities: subscriber presence, message history, channel state, and namespaces. Each channel belongs to a namespace that defines quotas and access rights.

Presence — automatic tracking of channel participants. Each client subscribed to a channel registers in the presence map with clientId, status (online, away, offline), and arbitrary data. When a client disconnects (by timeout or explicitly), the presence is automatically updated.

Message history — each channel stores message history by default (up to 2 minutes or 100 messages on the free plan). On paid plans, history can be extended up to 72 hours with arbitrary retrospective access. History is stored in a distributed log with immutability guarantees (append-only).

Ably delivery guarantees

Delivery guarantees are a key differentiator of Ably from most real-time services. The platform supports several delivery modes, selectable when publishing a message. The mode determines how many times a message will be delivered and how connection failures are handled.

At-least-once — the message is delivered at least once, duplicates are possible. This mode is used for notifications and non-critical data where duplicates do no harm. Exactly-once — the message is delivered exactly once through deduplication on the client and server side. This mode is mandatory for financial transactions and device management.

Last-value cache — a special mode where the channel stores the last value of each named message. A new subscriber instantly receives the current state without waiting for the next event. This is implemented through a global key-value store on each router. According to the Ably documentation (2025), last-value cache reduces state recovery time after reconnection from 2–5 seconds to 50–100 ms.

How to use Ably in a project

Getting started with Ably requires registration, creating an application, and obtaining an API key. Libraries are available for all major platforms. Let's look at an example of publishing and subscribing using the JavaScript SDK. The client connects with an API key, subscribes to a channel, and attaches an event handler.

According to the Ably documentation (2025), it is recommended to use different API keys for server-side and client-side with minimal permissions (principle of least privilege). The server key can publish to any channels, while the client key can only subscribe to specific namespaces.

Subscribing to an Ably channel

import * as Ably from 'ably';

const client = new Ably.Realtime({
    key: 'YOUR_API_KEY',
    clientId: 'user-123'
});

const channel = client.channels.get('test-channel');

channel.subscribe('update', (message) => {
    console.log('Received:', message.data);
});

channel.publish('update', {
    text: 'Hello from Ably',
    priority: 1
});

Publishing from the server

const Ably = require('ably');

const rest = new Ably.Rest({ key: 'SERVER_API_KEY' });

const channel = rest.channels.get('test-channel');

channel.publish('server-event', {
    type: 'notification',
    payload: { userId: 100, text: 'Server message' }
}).then(() => {
    console.log('Message published via REST');
});

Ably vs Pusher: comparison

Choosing between Ably and Pusher depends on project requirements. Both platforms provide hosted real-time infrastructure, but differ in architecture, guarantees, and pricing. Ably is focused on enterprise with high reliability demands, while Pusher is geared toward quick start and simplicity.

Ably uses a global distributed log for each channel, ensuring exactly-once delivery and retrospective access to history. Pusher uses a broker architecture with at-least-once guarantees. For most applications, the difference is unnoticeable, but for financial and medical systems, exactly-once is critical.

According to a comparative test of Ably vs Pusher (2024), Ably demonstrates 20–30% lower latency for intercontinental transmission due to a larger number of data centers. Pusher wins in integration speed — basic setup takes 10–15 minutes versus 20–30 minutes for Ably due to more configuration options.

Ably mobile integration

Ably SDK for mobile platforms supports iOS (Swift), Android (Kotlin/Java), Flutter, and React Native. Mobile clients are fully compatible with the Ably server side and support all features: pub/sub, presence, history, push notifications. For Android, integration with Firebase Cloud Messaging is available for offline push notification delivery.

Optimization for mobile networks — Ably SDK uses adaptive heartbeat: on Wi-Fi, the interval is 15 seconds, on mobile networks — up to 60 seconds to save traffic. Upon connection loss, the SDK switches to a backup transport (HTTP streaming) with no visible delay for the user. Average traffic consumption is 0.5–1 KB per minute in standby mode.

Push notifications — Ably supports sending push via APNs (Apple) and FCM (Firebase). Push can be directed to a specific channel or clientId. If the client is active (WebSocket connected), the message is delivered via the channel. If the client is disconnected, the message is delivered as a push notification. This ensures the user never misses an important message.