The best pub/sub services: 5 pub/sub solutions compared

Publish/subscribe (pub/sub) is an asynchronous messaging pattern that decouples message producers from message consumers. That flexibility makes it a great choice for creating event-driven application architectures, integrating with external services, and other scenarios where you need to manage potentially complex flows of data between independent services.

The core components of pub/sub are:

• Publishers: Services that emit messages with no need for any integration work directly with the services that will read those messages. For example, a financial data service pushing stock price updates to users of a trading app.

• Channels or topics: Similarly themed messages get grouped together in channels and each message is published to one or more of these channels. In our trading app example, each stock could have its own channel, allowing users to receive only the stock data they’re interested in. However, there might also be channels that send summaries for each stock exchange, such as the FTSE 100 or Dow Jones index.

• Subscribers: Services that subscribe to particular channels and ingest the messages on those channels, without having any direct contact with the services publishing those messages. In our financial data example, that could be mobile apps on end-user devices, automated trading systems, or a news aggregation platform.

The pub/sub pattern

This approach makes it easier to write code that publishes and consumes data across disparate systems because there's just one integration point: the pub/sub service. However, this also means putting a lot of faith in that one part of your infrastructure. 

If the pub/sub service can't scale to handle the volume of data you're sending, or if it does a bad job of ensuring message delivery, it could degrade your end-user experience or even lead to downtime.

Take a look at our pub/sub guide to learn more about this architecture pattern.

If you choose the pub/sub route, it's essential that you can rely on the tooling you choose. For most teams, that means using a managed pub/sub platform rather than building a solution in-house.

In our own research, we've found that in-house realtime infrastructure projects have a strong tendency to run over budget and over time. And even after all that, they often cost more overall.

So, if you decide to use a managed pub/sub service, how do you choose the right one for your needs? As we noted in the introduction, at first glance it can be hard to differentiate between the different offerings available. 

Let's expand on the criteria we'll use to compare some of the most popular options:

The way platforms handle scalability affects both your costs and the user experience. Some platforms adjust automatically as demand changes, while others can't respond quickly enough or without manual intervention. If a platform can't scale automatically, you'll need to over-provision resources to prepare for peak times. This can result in idle resources during slower periods, leading to higher costs without any real benefit.

Here are some things to look out for when it comes to evaluating a pub/sub platform's scalability:

• Scale on demand: Can the platform handle spikes in demand?

• Automatic scaling: Do you need to plan for and manually enable scaling or does the platform respond automatically in a serverless manner?

• Scaling architecture: Does it scale out horizontally to multiple instances or scale up on a single instance?

• Multi-region scaling: Can the platform run across multiple cloud regions or datacenters?

Reliability is the other side of the coin from scalability. That's because the architectural choices that help a platform scale also make it more resilient. This is especially true for scale out architectures, because their ability to operate across multiple instances, availability zones, or geographic regions also improves their ability to work around failure.

When comparing pub/sub services, you should look to see if they offer the following:

• Automatic failover: Can the platform maintain availability, even if one instance becomes unavailable?

• Message persistence: What happens if a subscriber temporarily disconnects? Can the platform hold onto the messages they miss, and replay them when they reconnect, or are they lost?

• Geographic redundancy: Can the platform boost fault tolerance by distributing load across multiple locations to work around broader cloud or internet issues?

Latency can mean the difference between delivering an end-user experience that keeps people productive and one that leaves them frustrated. As virtually all your application's data will pass through the managed pub/sub service you choose, it has a key role in whether you can provide a smooth, responsive service.

The architectural factors that determine whether your chosen pub/sub service can deliver low latency communication include:

• Datacenter locations: Does the provider have a presence near to your end users and the other parts of your application infrastructure? That could be in the form of core routing datacenters or edge points of presence that minimize the round-trip time from clients to the pub/sub platform.

• Protocol efficiency: The protocol the platform uses to connect publishers and subscribers can have a big impact both on the efficiency of handling messages and on the way you integrate the platform into your application. For example, Google Pub/Sub favors gRPC, which can be efficient but lacks support in browsers. PubNub relies on HTTP long polling, which is widely available but inefficient. Ably, on the other hand, offers WebSocket and several other protocols, to maximize the types of clients you can connect. Learn more about why we at Ably favor WebSocket, and alternative protocols for realtime experiences.

• Network robustness: How reliable is the underlying network infrastructure in handling high traffic volumes and ensuring consistent low latency performance?

If you can't trust that your messages will reliably reach their destination, you might question the value of using a pub/sub service at all. Surprisingly, many managed pub/sub platforms provide only basic guarantees, forcing you to add extra application logic to track and resend messages.

When comparing pub/sub services, guarantees typically fall into the following two categories:

• Delivery guarantees: You'll encounter three main types: at most once, at least once, and exactly once.

  • At most once means the platform only ensures that a message won’t be delivered multiple times. However, it could fail to deliver it altogether, and that would still satisfy this guarantee.

  • At least once ensures the message will be delivered, but it might show up more than once, requiring you to handle deduplication on your end. Most platforms offer this type of delivery guarantee.

  • Exactly once is the rarest and most difficult guarantee to achieve. It promises that each message will be delivered one time—no more, no less.

• Ordering: Some platforms promise to deliver your messages in the order you send them, whereas others leave it to you to manage message sequencing on your own. This means that if order is critical for your application—such as in financial transactions or event-driven architectures—you'll need to implement additional logic to ensure that messages are processed in the correct sequence. Most platforms don't promise to deliver messages in the order you send them.

You should also consider how easy a pub/sub service is to work with. Is it easy to learn? How quickly can you use it to deliver new features? What demands will it put on your DevOps team?

So, alongside the platform's functionality, make sure to check out how well it does in the following areas:

• Developer experience: Are SDKs available for your preferred languages, frameworks, and platforms? 

• Integrations: Does it integrate easily with other parts of your infrastructure?

• Monitoring: Can you observe the performance and status of your pub/sub platform?

As with many managed services, pricing tables don't always tell the full story when it comes to cost of ownership. There are three areas you should consider when thinking about which platform will give you the best return on your investment:

• Platform efficiency: Does the platform provide features to optimize message delivery? For instance, does it support batching messages to prevent traffic from growing exponentially as you add more clients? Or does it offer techniques like binary delta compression, which only sends the specific updates each client needs, reducing bandwidth usage and improving performance?

• Additional infrastructure costs: If the pub/sub platform doesn't offer some of the functionality that your application requires, such as exactly once delivery, you'll need to factor in the cost of running your own additional code to fill the gaps.

• Cost of development and operation: This includes the fees charged by the platform but also how much development effort it takes to integrate with the platform and the ongoing costs of keeping it running.

As a messaging pattern pub/sub is only concerned with publishing messages to a topic or channel, and subscribers receiving messages from that topic. However most of the managed pub/sub services provide additional features that are easy to integrate and enable higher performing, feature rich applications to be created.  

Some of the features that providers offer include:

• Push notifications direct to iOS and Android devices, as well as browsers.

• Message persistence, so clients can catch-up on following a disconnect.

• Message filtering, so that subscribers can choose which messages to receive from a particular channel.

• Presence enabling the automatic detection of a user’s connection status (offline/online).

• Connection state and recovery ensures you automatically re-establish failed connections and replay missed messages.

• Message batching enables the optimization of costs and enhances performance in large-scale, high-throughput applications.

• Subscription filters for selectively subscribing to messages on a channel using filter expressions.

• Dynamic channel groups enable automatic subscription to multiple active channels simultaneously that match your specified criteria.

• Create consumer groups that cooperate to consume data from certain channels.

• Significant bandwidth reduction when broadcasting changes using binary Delta compression.

• Support for multiple protocols, such as WebSocket, MQTT, and Server Sent Events, thereby expanding the number of clients that can connect to the pub/sub platform.

• In most pub/sub services, messages are consumed by application components. Where an end-user needs to receive a message, or a system cannot integrate directly with the pub/sub service, some platforms offer SMS and email delivery.

• SMS messaging as an alternative method of delivery messages to end-users. This is similar to how some platforms offer push notifications and email delivery.

• File sharing is a complementary aspect of many of the use cases enabled by pub/sub. For example, sending images in chat, sharing a spreadsheet with colleagues in a collaborative work environment, adding context to stock information with company press releases.

• Similarly, the ability to persist small amounts of data can make pub/sub platforms more robust and help enable other functionality, such as file sharing. That's why some pub/sub services offer lightweight storage.

Now that we have the criteria, let's use them to look at some of the more popular pub/sub platforms.

Google Pub/Sub is a managed publish/subscribe messaging service that is deeply integrated with the Google Cloud ecosystem. However, it also offers server-side libraries for integration with your application code. Perhaps the biggest benefit of Google Pub/Sub is that it distributes your topics across the global Google Cloud network. Another thing to note is that it mostly uses the gRPC protocol, which could make it harder to integrate with browser-based applications. 

Here’s how Google Cloud Pub/Sub performs on each of the key evaluation criteria:

PubNub is a realtime messaging platform that uses the pub/sub pattern to deliver messages across its global network. It also offers functionality such as cloud functions, message persistence, and mobile push notifications. However, its reliance on HTTP long polling instead of more modern techniques can result in longer latencies than some alternatives. It also falls short when it comes to message delivery: rather than providing guaranteed message delivery, PubNub asks you to write your own functionality to take care of that.

Here’s how PubNub performs on each of the key evaluation criteria:

Pusher is a lightweight pub/sub messaging platform that also lets you send native mobile notifications. What sets Pusher apart from other managed pub/sub services is that it offers a relatively basic solution. That means you'll need to write and maintain a lot more of your own code to make sure your messages reach their destinations. Things to look out for include operating in a single cloud region, making Pusher more fragile than alternatives, and no delivery guarantees.

Here’s how Pusher performs on each of the key evaluation criteria:

Amazon's Simple Notification Service (SNS) is a managed pub/sub service that also offers SMS and mobile push notifications. As you might expect, it favors the Amazon ecosystem when it comes to integrations but it has a REST API and several SDKs. While it's designed for scale, individual topics exist only in a single region, which could limit scalability, resilience, and the ability to offer low latencies to end-users further from that cloud region.

Here’s how AWS SNS performs on each of the key evaluation criteria:

Ably is a realtime experience platform, serving more WebSocket connections than any other pub/sub platform. Originally just a pub/sub service, they now offer a suite of products to accommodate different developer needs and use cases, including: Ably Pub/Sub, Ably Chat, Ably LiveSync and Ably Spaces. Accessed via simple APIs, use case specific SDKs and pre-built integrations, this product set enables the creation of a host of live experiences - including data broadcasts, live updates, chat, collaboration, notifications, and fan engagement.

Underpinned by a globally-distributed network of datacenters and edge acceleration points of presence, all products benefit from <50ms global median latency, with guaranteed message ordering and exactly once delivery. Capable of scaling to handle millions of concurrent clients, with redundancy built in at a regional and global level.

Out of all the options available for adding pub/sub functionality to your application, for most teams a managed pub/sub service offers the best trade-offs when it comes to cost, development effort, maintenance, reliability, and functionality. 

But not all managed pub/sub platforms are alike. As we've seen in our comparison, most pub/sub platforms ask you to compromise on at least one important factor. That could be delivery guarantees, latency, scalability, or developer experience.

Ably is different. Our managed WebSocket infrastructure is built to serve the world’s most demanding realtime workloads, and is trusted by leading brands to power their critical applications. Coupled with the rich feature set offered through our Ably Pub/Sub product, we enable developers to rapidly develop any live and interactive experience with confidence. Sign up for a free account to start experimenting and building with Ably's managed pub/sub service.