The short version

Unlike other pub/sub platforms, Ably is a stateful system which provides messaging with a high quality of service.  As such, there is a "cost" when creating new channels so the first publish on a channel where there are no subscribers can take longer than subsequent publishes.


However, this publish request latency has no material impact on performance for subscribers. If a client is subscribed to a channel, then that channel will be provisioned within the Ably platform already, and as such a publish to that channel can be done with very low latency.  If a channel however does not yet exist, because there is no one subscribed for messages, then a publish may take longer as we provision the channel within Ably. However, this time to provision a channel has no meaningful impact because no one is subscribed at the time i.e. no one cares that latency is high if no one is receiving the messages.


Note that our stateful design is what allows us to provide a higher quality of service than other platforms.  We only consider a message published once it has been stored in at least two data centers.  Typically other pub/sub systems will ACK the message once received, yet at that point it is not guaranteed to be delivered as it is typically only stored on the server that processed the request. So this low latency to receive a request is a red herring. The time to ACK a publish operation may sometimes take longer with Ably, but this means publishes are more reliable, and importantly it has no impact on the time it takes for a message to be delivered, which is what matters most.


The long version

Channels are not pre-configured or provisioned by Ably in advance; they are created on demand when clients attach to them. When you publish on a realtime channel that you weren't previously attached to, the client library will automatically initiate an attach, and messages are queued until the attach has succeeded. See our channel lifecycle documentation for more details.


If that channel was not previously active in the region where you're attaching to it, Ably must first create the channel in that region. This requires global cluster coordination -- a handshake with other regions in the cluster -- which adds significant latency. (If it was not previously active anywhere in the cluster, there is even more work to do). Only after this has been done will Ably tell the client that that channel has been successfully attached, and publishes can begin.


(A channel will be disposed automatically two minutes after the last realtime client has detached from it; see How does Ably count peak channels? for more information on when channels are active).


The upshot of that is that if you want the very first publish to be low-latency, consider attaching to the channel you'll be using explicitly, in advance of when the first publish will happen, using channel#attach, rather than relying on the publish implicitly attaching to the channel. (That function takes a callback or language equivalent, so you can be notified and take action once the channel has successfully attached).


For example, the following code will ensure that the first publish has low latency:


let client = new Ably.Realtime({ authUrl: '/example_auth_url' });
let channel = client.channels.get('foo');

/* Attach and provision the channel globally */
channel.attach(function(err) {
  if (err) { return console.error("Channel attach failed", err); }
  /* Channel is now created, so the publish can happen immediately as the channel is "ready" */
  channel.publish("name", "data", function(err) {
    if (err) { return console.error("Channel publish failed", err); }
    console.log("Publish on an already provisioned channel succeeded quickly");
  });
});



Further reading