USPs for Pub/Sub

src/pages/docs/channels/options/deltas.mdx

@@ -33,6 +33,12 @@ There is no constraint on how many publishers or subscribers there are. If there
 
 If a delta is generated and it results in a difference that is not appreciably smaller than the original message, or is larger than the original message, for example if successive messages are completely different, then the delta will not be sent. Clients will receive the original, unprocessed message.
 
+<Aside data-type='usp'>
+Consistent message ordering for deltas.
+
+Deltas rely on consistent message ordering. Messages published using Realtime from a single publisher are delivered to all subscribers in the [same order](/docs/platform/architecture/message-ordering#message-ordering-guarantees), with each message assigned a unique serial number.
+</Aside>
+
 <If lang="javascript,nodejs">
 ## Install vcdiff decoder <a id="vcdiff"/>
 

src/pages/docs/connect/index.mdx

@@ -222,6 +222,12 @@ By default, the Ably Pub/Sub JavaScript SDK adds a listener for the `beforeunloa
 
 If a connection to Ably is not explicitly closed when there is a page unload event, then the connection state is preserved by Ably for 2 minutes. Preserving connection state for 2 minutes when there is an unexpectedly dropped connection provides the opportunity for the client to reconnect and resume the connection without losing any messages.
 
+<Aside data-type='usp'>
+Transparent edge network failover.
+
+Ably's SDKs automatically resolve [edge network failures](/docs/platform/architecture/edge-network) within 30 seconds, keeping your users connected even during datacenter outages.
+</Aside>
+
 ### Reliability considerations
 The `beforeunload` event can be unreliable and is not guaranteed to fire under certain circumstances:
 * The event may fire but the page is subsequently not disposed of (navigation can be cancelled).

src/pages/docs/connect/states.mdx

@@ -15,6 +15,12 @@ An Ably SDK is responsible for managing a connection. This includes:
 
 When an SDK is instantiated it will establish a connection immediately, and if the connection drops at any time it will attempt to re-establish it by making repeated connection attempts every 15 seconds for up to two minutes.
 
+<Aside data-type='usp'>
+Automatic fallback to alternative endpoints.
+
+Failed connections automatically try up to 5 [alternative endpoints](/docs/platform/architecture/edge-network#protocol-level-resilience) worldwide, maximizing reconnection success.
+</Aside>
+
 ## Available connection states <a id="connection-states"/>
 
 The different connection states are:

src/pages/docs/messages/index.mdx

@@ -44,6 +44,12 @@ Ensure a message was successfully published by checking the [history](/docs/stor
 
 Ably does not store per-message delivery logs, nor logs of who is subscribed to a channel at any point in time. This means it is not possible to check which users have received messages retroactively.
 
+<Aside data-type='usp'>
+Message continuity during disruptions.
+
+Applications maintain their state during brief disruptions. If a client reconnects within two minutes, all messages are received in the correct order with [no message loss](/docs/platform/architecture/connection-recovery#message-identification-with-timeserial).
+</Aside>
+
 ## Message conflation <a id="conflation"/>
 
 Use message conflation to ensure that clients only ever receive the most up-to-date message, by removing redundant and outdated messages. Message conflation will aggregate published messages for a set period of time and evaluate all messages against a [conflation key](#routing). All but the latest message for each conflation key value will be discarded, and the resulting message, or messages, will be delivered to subscribers as a single batch once the period of time elapses.

src/pages/docs/metadata-stats/metadata/subscribe.mdx

@@ -149,6 +149,12 @@ channel.subscribe("channel.closed", new Channel.MessageListener() {
 ```
 </Code>
 
+<Aside data-type='usp'>
+Metadata events scale with your traffic.
+
+Auto Scaling Groups in each region [scale independently](/docs/platform/architecture/infrastructure-operations#multi-region-deployment) according to demand, ensuring metachannels remain responsive and deliver operational insights reliably during traffic peaks.
+</Aside>
+
 ## Log events <a id="log"/>
 
 The `[meta]log` and [`[meta]log:push`](/docs/push#Error) metachannels publish events that aren't otherwise available to clients.

src/pages/docs/metadata-stats/stats.mdx

@@ -23,6 +23,12 @@ Statistics are available as:
 * [Account statistics](#account) covering all applications in your account
 * [App statistics](#app) for each individual application
 
+<Aside data-type='usp'>
+Over 500 billion messages delivered monthly.
+
+Ably delivers over 500 billion messages monthly, demonstrating [large-scale throughput capability](/docs/platform/architecture/platform-scalability#monitoring-and-auto-scaling).
+</Aside>
+
 ## Account statistics <a id="account"/>
 
 Account statistics aggregate metrics from all applications in your account with additional [account-only metrics](#account-only) relating to peak rates monitored and enforced at an account level.

src/pages/docs/presence-occupancy/presence.mdx

@@ -35,6 +35,12 @@ The following presence events are emitted:
 | Update | An already present member has updated their [member data](#member-data). Being notified of member data updates can be useful, for example, it can be used to update the status of a user when they are typing a message |
 | Present | When subscribing to presence events on a channel that already has members present, this event is emitted for every member already present on the channel before the subscribe listener was registered |
 
+<Aside data-type='usp'>
+Presence state preserved during disconnections.
+
+When a client briefly disconnects, Ably [preserves their connection state](/docs/platform/architecture/connection-recovery), including presence membership, for up to two minutes. This prevents false leave and re-enter events during temporary network issues.
+</Aside>
+
 ### Member data <a id="member-data"/>
 
 In addition to the [`clientId`](/docs/api/realtime-sdk#client-id) for members on a channel, it is also possible to include data when entering a channel. Clients can [update](/docs/api/realtime-sdk/presence#update) their data at any point which will be broadcasted to all presence subscribers as an `update` event.

src/pages/docs/protocols/mqtt.mdx

@@ -35,6 +35,12 @@ Our MQTT adapter only supports features supported by both the MQTT protocol and
 * Doesn't support any MQTT features that aren't normally supported by Ably, such as `WILL` messages, the `RETAIN` flag or [wildcard channel subscriptions](/docs/channels)
 * Doesn't support Ably features that aren't supported by the MQTT protocol, such as presence, history and push notifications, though you can use the Ably REST API in conjunction with the adapter to access features available over REST
 
+<Aside data-type='usp'>
+Consistent regional message ordering.
+
+Within a single region, all MQTT subscribers will observe messages in the [same order](/docs/platform/architecture/message-ordering#practical-implications-of-dual-ordering), ensuring consistent experiences for users in that region.
+</Aside>
+
 ## Configuration <a id="config"/>
 
 To use the Ably MQTT protocol adapter, you'll need to ensure you correctly configure your MQTT client as follows:

src/pages/docs/protocols/pubnub.mdx

@@ -16,6 +16,12 @@ You can use PuBNub and and an Ably SDK side-by-side as they are interoperable, w
 
 For a detailed comparison of Ably and PubNub features, see [Ably vs PubNub](https://ably.com/compare/ably-vs-pubnub).
 
+<Aside data-type='usp'>
+Automatic connection recovery and message continuity.
+
+Ably automatically [recovers connections](/docs/platform/architecture/connection-recovery) and delivers all missed messages when clients reconnect within two minutes, ensuring no data is lost during brief disconnections.
+</Aside>
+
 ## Migration process <a id="migration-process"/>
 
 A typical migration from PubNub to Ably follows these steps:

src/pages/docs/protocols/pusher.mdx

@@ -11,6 +11,12 @@ Using an adapter introduces some latency and is slower than using an Ably SDK, h
 
 The Pusher Adapter provides some of the advantages of Ably, such as inter-regional message federation, however others, such as [continuity guarantees](https://ably.com/four-pillars-of-dependability), fallback host support, and [message history](/docs/storage-history/history) are only available when using an Ably SDK. If an [Ably SDK](/docs/sdks) is available in your chosen platform, it is recommended you use that, or plan to transition to it eventually.
 
+<Aside data-type='usp'>
+Automatic routing to the closest datacenter.
+
+Ably automatically connects clients to the closest datacenter using [latency-based DNS routing](/docs/platform/architecture/edge-network#dns-organization-and-latency-based-routing), compensating for any protocol adapter overhead with optimal network proximity.
+</Aside>
+
 ## Supported features <a id="features"/>
 
 The following Pusher features are supported using the adapter:

src/pages/docs/protocols/sse.mdx

@@ -42,6 +42,12 @@ SSE is an excellent alternative to Ably SDK in memory-limited environments.
 If you are streaming LLM responses to users, [AI Transport](/docs/ai-transport) provides purpose-built token streaming with resumable sessions and multi-device continuity, addressing the limitations of HTTP-based streaming.
 </Aside>
 
+<Aside data-type='usp'>
+Resilient connections with DNS failover.
+
+Ably's DNS uses a [60-second TTL](/docs/platform/architecture/edge-network#dns-organization-and-latency-based-routing), allowing traffic to be rerouted away from unhealthy datacenters within minutes when issues are detected.
+</Aside>
+
 ## Configuration <a id="config"/>
 
 The following code sample provides an example of how to use SSE with Ably:

src/pages/docs/pub-sub/advanced.mdx

@@ -388,6 +388,12 @@ Subscribing to events server-side using the pub-sub pattern can be disadvantageo
 
 [Message queues](/docs/platform/integrations/queues) are more appropriate to use in this instance, as multiple worker servers enable Ably to distribute the load of messages received. This ensures that each message is only processed once, by any one of your worker servers.
 
+<Aside data-type='usp'>
+Even load distribution with consistent hashing.
+
+Ably's message queues use [consistent hashing](/docs/platform/architecture/platform-scalability#consistent-hashing-for-workload-distribution) to distribute messages across worker servers, ensuring even load distribution and exactly-once processing.
+</Aside>
+
 ### Subscription filters <a id="subscription-filters"/>
 
 Subscription filters enable you to subscribe to a channel and only receive messages that satisfy a filter expression.

src/pages/docs/push/index.mdx

@@ -17,6 +17,12 @@ redirect_from:
 
 Push notifications notify user devices or browsers regardless of whether an application is open and running. They deliver information, such as app updates, social media alerts, or promotional offers, directly to the user's screen. Ably sends push notifications to devices using [Firebase Cloud Messaging](https://firebase.google.com/docs/cloud-messaging) or [Apple Push Notification Service](https://developer.apple.com/notifications/), and to browsers using [Web Push](https://developer.mozilla.org/en-US/docs/Web/API/Push_API). Push notifications don't require a device or browser to stay connected to Ably. Instead, a device's or browser's operating system or web browser maintains its own battery-efficient transport to receive notifications.
 
+<Aside data-type='usp'>
+Enterprise-scale push notification delivery.
+
+Ably's infrastructure serves billions of devices each month, handling [enterprise-scale traffic](/docs/platform/architecture/platform-scalability) reliably and quickly.
+</Aside>
+
 You can publish push notifications to user devices or browsers [directly](/docs/push/publish/#direct-publishing) or [via channels](#via-channels).
 
 Publishing directly sends push notifications to specific devices or browsers identified by unique identifiers, such as a `deviceId` or a `clientId`. This approach is akin to sending a personal message or alerts directly to an individual user's device or browser, bypassing the need for channel subscriptions. It excels in targeted and personalized communications, such as alerts specific to a user's actions, account notifications, or customized updates.
@@ -37,7 +43,7 @@ The following diagram demonstrates the push notification process:
 
 ### Configure
 
-Configuring push notifications sets your [device's](/docs/push/configure/device) or [browser's](/docs/push/configure/web) push notification service to operate with the Ably [platform](https://ably.com/docs/). This process includes inputting the necessary credentials into your Ably [dashboard](https://ably.com/accounts).
+Configuring push notifications sets your [device's](/docs/push/configure/device) or [browser's](/docs/push/configure/web) push notification service to operate with the Ably [platform](/docs/). This process includes inputting the necessary credentials into your Ably [dashboard](https://ably.com/accounts).
 
 ### Activate
 
@@ -97,7 +103,7 @@ Each push target device or browser is associated with a unique `deviceId` and au
 
 * By employing a standard [Ably key](/docs/auth/basic) or [Token](/docs/auth/token), with a `deviceIdentityToken`, a credential generated during registration to assert the device's or browser's identity, included in the request header.
 
-The service credential management is handled by the [Ably SDK](https://ably.com/docs/sdks), removing the need for the client application to manage device credentials unless accessing the [push admin API](/docs/api/realtime-sdk/push-admin) directly via HTTP.
+The service credential management is handled by the [Ably SDK](/docs/sdks), removing the need for the client application to manage device credentials unless accessing the [push admin API](/docs/api/realtime-sdk/push-admin) directly via HTTP.
 
 #### Error handling <a id="Error"/>
 

src/pages/docs/push/publish.mdx

@@ -26,6 +26,12 @@ Publish push notifications directly or via channels:
   - **Description:** Messages are sent to multiple devices or browsers through specified channels.
   - **Requirement:** Devices or browsers must be [subscribed](#sub-channels) to these channels to receive notifications.
 
+<Aside data-type='usp'>
+Proactive capacity management.
+
+Proactive [capacity management](/docs/platform/architecture/performance#capacity-management-and-quality-of-service) with headroom maintenance ensures performance isn't degraded by capacity limitations, regardless of demand levels.
+</Aside>
+
 ## Push notification payload structure <a id="payload"/>
 
 Ably adapts message fields for seamless compatibility with each push notification platform:
@@ -130,7 +136,7 @@ The following example shows a background notification:
 
 ## Publish directly <a id="direct-publishing"/>
 
-Direct publishing sends push notifications directly to individual devices via the [Ably SDK](https://ably.com/docs/sdks), bypassing the intermediary of channels. This approach delivers personalized or precise notifications customized for individual users. Direct publishing proves beneficial during the transition phase to Ably's platform and when the objective is to engage existing push notification devices.
+Direct publishing sends push notifications directly to individual devices via the [Ably SDK](/docs/sdks), bypassing the intermediary of channels. This approach delivers personalized or precise notifications customized for individual users. Direct publishing proves beneficial during the transition phase to Ably's platform and when the objective is to engage existing push notification devices.
 
 Direct publishing is also available in [batch mode](#via-batch-push-api), enabling you to publish to a large number of devices in one request.
 

src/pages/docs/storage-history/history.mdx

@@ -28,6 +28,11 @@ For any application needing complex queries or long-term data persistence, you m
 
 You can also learn more about [connection states](/docs/connect/states) and the broader [platform architecture](/docs/platform/architecture).
 
+<Aside data-type='usp'>
+Two-minute message continuity.
+
+Ably maintains message continuity for up to 2 minutes during disconnections. The SDKs automatically handle [reconnection](/docs/platform/architecture/connection-recovery) and deliver all missed messages.
+</Aside>
 
 ## History versus rewind <a id="history-rewind"/>
 

src/pages/docs/storage-history/storage.mdx

@@ -27,6 +27,12 @@ The time that messages will be stored for depends on your account package:
 
 There is a cost associated with storing messages for longer than the minimum time period. [Contact us](https://ably.com/support) to discuss enabling long term storage.
 
+<Aside data-type='usp'>
+Redundant multi-datacenter storage.
+
+Every message is redundantly stored across [multiple isolated datacenters](/docs/platform/architecture/fault-tolerance#core-layer) within your region before acknowledgment, preventing data loss.
+</Aside>
+
 ### Message deletion <a id="message-deletion"/>
 
 Ably does not currently provide an API to delete persisted messages from the history. Once messages are stored with persisted history enabled, they remain for the entire configured storage period. If you need to delete specific messages from history, [contact us](https://ably.com/support) to discuss requirements.