Merge pull request #3059 from ably/FTF-450-write-usp-copy-for-live-sync

Adds USPs to livesync docs

Author: GregHolmes

src/pages/docs/livesync/index.mdx

@@ -29,6 +29,12 @@ Ably provides hosted connectors for:
 
 LiveSync can benefit a wide range of applications where it's important to broadcast database changes in realtime to keep clients in sync, including: Customer Relationship Management (CRM) applications, customer support applications, productivity or task management applications, online auctions, collaborative form editing, e-commerce systems, chat conversations, multiplayer turn-based games and realtime newsfeeds.
 
+<Aside data-type='usp'>
+No missed updates
+
+LiveSync clients benefit from Ably's [connection recovery and exactly-once delivery](/docs/platform/architecture/idempotency#connection-recovery-and-exactly-once-delivery), so if a subscriber briefly disconnects, they automatically catch up on any database changes they missed without duplicates or gaps.
+</Aside>
+
 ## Pricing <a id="pricing"/>
 
 LiveSync [pricing](https://ably.com/pricing) is mainly based on message consumption (alongside concurrent connections and concurrent channels). This means that each update published from the database connector to Ably channels is counted as a single message. The message is received by every client subscribed to that channel, each of which counts as one additional message. If, for example, one update is published by the database connector and there are three clients subscribed, that one update will result in four messages in total.

src/pages/docs/livesync/mongodb/index.mdx

@@ -153,7 +153,6 @@ For the schema and fields available on a change event, see the [MongoDB Change E
 You must set the `_ablyChannel` field on the root of the change event. This allows the MongoDB database connector to know where to route the change event.
 </Aside>
 
-
 ### Dynamically route change events <a id="channel-routing"/>
 
 You can route change events to Ably Pub/Sub channels dynamically based on the content of the change event received from the MongoDB Change Stream.
@@ -257,6 +256,12 @@ The MongoDB database connector makes use of a [Resume Token](https://www.mongodb
 
 To reduce the number of writes against your database, the connector will update the resume token on a timer interval. [Idempotent publishing](/docs/pub-sub/advanced#idempotency) means that the connector does not need to update the token on every change event. Ably can use a slightly older Resume Token and still guarantee that we will not send duplicate messages to subscribers, because duplicate messages are filtered out by our idempotent publish checks.
 
+<Aside data-type='usp'>
+Zero duplicate deliveries
+
+The MongoDB database connector uses [idempotent publishing](/docs/pub-sub/advanced#idempotency) to filter out duplicates, so subscribers receive each change event exactly once — even when the connector resumes from a slightly older token.
+</Aside>
+
 ## Database Permissions <a id="permissions"/>
 
 The MongoDB database connector needs [certain permissions](https://www.mongodb.com/docs/v8.0/changeStreams/#access-control) to open and manage the Change Stream.

src/pages/docs/livesync/postgres/index.mdx

@@ -24,6 +24,12 @@ The Postgres database connector automatically retries failed publishes while mai
 
 The database connector can be [self-hosted](#self-host).
 
+<Aside data-type='usp'>
+Transactional delivery guarantee
+
+By writing change events to the outbox table within the same database transaction as your data changes, you get [exactly-once, in-order delivery](/docs/platform/architecture/idempotency) over Ably without the complexity of coordinating two separate systems.
+</Aside>
+
 ## Integration rule <a id="integration-rule"/>
 
 ### Creating the rule <a id="create"/>

src/pages/docs/livesync/postgres/models.mdx

@@ -301,6 +301,12 @@ model.subscribe((err, post) => { /* ... */ }, { optimistic: false });
 ```
 </Code>
 
+<Aside data-type='usp'>
+Seamless state recovery
+
+If a client briefly disconnects, the Models SDK automatically replays missed change events from the [sequenceId](#sequence-id) checkpoint and re-merges them, so the local model state catches up without a full resync from your backend.
+</Aside>
+
 ## Model lifecycle <a id="model-lifecycle"/>
 
 A model instance can be in one of the following lifecycle states: