Merge pull request #3234 from ably/DX-883-message-billing

[DX-883] Addresses message billing docs gap

Author: umair-ably

src/data/nav/chat.ts

@@ -228,6 +228,10 @@ export default {
         },
       ],
     },
+    {
+      name: 'Chat pricing',
+      link: '/docs/chat/pricing',
+    },
     {
       name: 'Guides',
       pages: [

src/data/nav/liveobjects.ts

@@ -60,11 +60,6 @@ export default {
           link: '/docs/liveobjects/concepts/synchronization',
           languages: ['javascript', 'swift', 'java'],
         },
-        {
-          name: 'Billing',
-          link: '/docs/liveobjects/concepts/billing',
-          languages: ['javascript', 'swift', 'java'],
-        },
       ],
     },
     {
@@ -113,6 +108,10 @@ export default {
         },
       ],
     },
+    {
+      name: 'LiveObjects pricing',
+      link: '/docs/liveobjects/pricing',
+    },
   ],
   api: [
     {

src/data/nav/livesync.ts

@@ -48,6 +48,10 @@ export default {
         },
       ],
     },
+    {
+      name: 'LiveSync pricing',
+      link: '/docs/livesync/pricing',
+    },
   ],
   api: [
     {

src/data/nav/platform.ts

@@ -130,6 +130,10 @@ export default {
           link: '/docs/platform/pricing/billing',
           name: 'Billing',
         },
+        {
+          link: '/docs/platform/pricing/message-counting',
+          name: 'Message counting',
+        },
         {
           link: '/docs/platform/pricing/limits',
           name: 'Limits',

src/data/nav/pubsub.ts

@@ -365,6 +365,10 @@ export default {
         },
       ],
     },
+    {
+      name: 'Pub/Sub pricing',
+      link: '/docs/pub-sub/pricing',
+    },
     {
       name: 'Guides',
       pages: [

src/data/nav/spaces.ts

@@ -62,6 +62,10 @@ export default {
         },
       ],
     },
+    {
+      name: 'Spaces pricing',
+      link: '/docs/spaces/pricing',
+    },
   ],
   api: [
     {

src/pages/docs/chat/pricing.mdx

@@ -0,0 +1,69 @@
+---
+title: "Chat pricing"
+meta_description: "Understand how Chat SDK features contribute to your message count, including messages, typing indicators, reactions, and cost optimization strategies."
+meta_keywords: "chat pricing, message counting, typing indicators, reactions, cost optimization"
+intro: "How Chat SDK features contribute to your message count and strategies to optimize costs."
+---
+
+The [Chat SDK](/docs/chat) is built on top of [Pub/Sub](/docs/pub-sub). All Chat operations generate Pub/Sub messages that follow the same counting rules.
+
+## Chat operations <a id="operations"/>
+
+The following table shows how Chat operations contribute to your message count:
+
+| Operation | Messages counted |
+| --- | --- |
+| [Messages](/docs/chat/rooms/messages) ||
+| Send message | 1 inbound message |
+| Message delivery | 1 outbound message per subscriber |
+| Update message | 1 inbound message |
+| Message update delivery | 1 outbound message per subscriber |
+| Delete message | 1 inbound message |
+| Message deletion delivery | 1 outbound message per subscriber |
+| [History](/docs/chat/rooms/history) ||
+| History retrieval | 1 outbound message per retrieved message |
+| [Typing indicators](/docs/chat/rooms/typing) ||
+| Typing keystroke | 1 inbound message; repeats every heartbeat interval (default 10s) |
+| Typing keystroke delivery | 1 outbound message per subscriber per heartbeat |
+| Typing stop | 1 inbound message |
+| Typing stop delivery | 1 outbound message per subscriber |
+| [Room reactions](/docs/chat/rooms/reactions) ||
+| Room reaction | 1 inbound message |
+| Room reaction delivery | 1 outbound message per subscriber |
+| [Message reactions](/docs/chat/rooms/message-reactions) ||
+| Message reaction send | 1 inbound message |
+| Message reaction delete | 1 inbound message |
+| Message reaction summary delivery | 1 outbound message per subscriber; multiple reactions may be rolled up into a single summary |
+| [Presence](/docs/chat/rooms/presence) ||
+| Presence enter | 1 inbound message |
+| Presence leave | 1 inbound message |
+| Presence update | 1 inbound message |
+| Presence event delivery | 1 outbound message per presence subscriber |
+| [Occupancy](/docs/chat/rooms/occupancy) ||
+| Occupancy event | 1 outbound message per subscriber (generated on membership changes, debounced up to 15s) |
+| [Moderation](/docs/chat/moderation) ||
+| Moderation rule invocation (before or after publish) | 1 outbound webhook event per moderated message |
+
+## Rooms and channels <a id="channels"/>
+
+Each Chat [room](/docs/chat/rooms) is backed by a single Ably Pub/Sub channel. All room features, such as messages, typing, reactions, presence, and occupancy, share that one channel.
+
+Channels contribute to your [channel count](/docs/platform/pricing#channels). The more rooms a client is attached to, the more channels are consumed. [Detach](/docs/chat/rooms#detach) from rooms when they are no longer needed, and [release](/docs/chat/rooms#release) rooms that are no longer in use to reduce your channel count.
+
+## Connections <a id="connections"/>
+
+Ably bills each connected client for [connection minutes](/docs/platform/pricing#connections). A connection-minute is counted for every minute a client maintains an open connection, regardless of activity. Clients that remain connected but idle still accrue connection minutes. Close connections when the client is done to stop accruing connection minutes.
+
+## Cost optimization <a id="optimization"/>
+
+### Reduce typing indicator frequency
+
+Increase the `heartbeatThrottleMs` [room option](/docs/chat/rooms#typing) to reduce typing indicator event frequency. The default is 10 seconds. Increase this value in rooms that tolerate delayed typing feedback.
+
+### Use server-side batching
+
+[Server-side batching](/docs/messages/batch#server-side) groups messages into single deliveries. Use this for high-throughput rooms where slight delay is acceptable.
+
+### Use occupancy instead of presence
+
+Use [occupancy](/docs/chat/rooms/occupancy) instead of [presence](/docs/chat/rooms/presence) when you only need member counts, not individual identities.

src/pages/docs/liveobjects/concepts/billing.mdx

@@ -94,7 +94,7 @@ LiveObjects [durably stores](/docs/liveobjects/storage) all objects on a channel
 
 LiveObjects usage is billed based on [Ably's standard pricing model](/docs/platform/pricing). Since LiveObjects is powered by Ably's channel messages, any interaction with LiveObjects - whether sending or receiving operations, maintaining active channels, or keeping connections open through the Realtime LiveObjects API - translates into billable usage. Storage of objects themselves does not incur additional costs; however, there is a [limit](/docs/liveobjects/storage) on the size of the channel object.
 
-For details on how using LiveObjects contributes to your billable usage, see [Billing](/docs/liveobjects/concepts/billing).
+For details on how using LiveObjects contributes to your billable usage, see [LiveObjects pricing](/docs/liveobjects/pricing).
 
 ### Realtime API <a id="pricing-realtime"/>
 

src/pages/docs/liveobjects/index.mdx

@@ -0,0 +1,65 @@
+---
+title: "LiveObjects pricing"
+meta_description: "Understand how LiveObjects operations contribute to your message count, including LiveMap, LiveCounter, synchronization, and REST API usage."
+meta_keywords: "LiveObjects pricing, message counting, LiveMap, LiveCounter, ObjectMessages"
+intro: "How LiveObjects operations contribute to your message count and strategies to optimize costs."
+redirect_from:
+  - /docs/liveobjects/concepts/billing
+---
+
+Ably bills LiveObjects operations using ObjectMessages. An ObjectMessage is the unit of change in LiveObjects. Each state mutation, such as setting a key, incrementing a counter, or creating an object, generates one or more ObjectMessages. Each ObjectMessage follows the standard inbound/outbound counting pattern.
+
+## LiveObjects operations <a id="operations"/>
+
+The following table shows how LiveObjects operations contribute to your message count:
+
+| Operation | Messages counted |
+| --- | --- |
+| [LiveMap](/docs/liveobjects/map) ||
+| LiveMap set or remove | 1 inbound message per operation |
+| LiveMap create (shallow) | 2 inbound messages (create + assign) |
+| [LiveCounter](/docs/liveobjects/counter) ||
+| LiveCounter increment or decrement | 1 inbound message |
+| LiveCounter create | 2 inbound messages (create + assign) |
+| ObjectMessage delivery | 1 outbound message per connected client |
+| [Synchronization](#synchronization) | 1 outbound message per object synchronized |
+| [REST API](#rest-api) fetch | 1 outbound message per object in response |
+| [Batch](/docs/liveobjects/batch) operation | 1 inbound message per operation in the batch |
+
+Nested object creation generates additional messages for each nested object.
+
+## Channels <a id="channels"/>
+
+Each LiveObjects channel contributes to your [channel count](/docs/platform/pricing#channels). Subscribing to updates does not affect the number of messages received by a client. Any client attached to a channel with the `object-subscribe` capability automatically receives all object messages for that channel. Subscribing to updates on an object adds a listener that is called whenever the client receives updates for that object.
+
+## Connections <a id="connections"/>
+
+Ably bills each connected client for [connection minutes](/docs/platform/pricing#connections). A connection-minute is counted for every minute a client maintains an open connection, regardless of activity. Clients that remain connected but idle still accrue connection minutes.
+
+## Cost optimization <a id="optimization"/>
+
+### Prefer flat data structures
+
+Setting a primitive value on a LiveMap costs one message. Creating a nested LiveMap costs two or more messages (one to create the object, one to assign it), plus additional messages for each level of nesting. Flatten your data model where possible to reduce the number of messages per update.
+
+### Minimize objects per channel
+
+Each object on a channel is synchronized when a client attaches or resynchronizes. Fewer objects per channel reduces the cost of synchronization. Distribute objects across channels based on which clients need access to them.
+
+## Synchronization <a id="synchronization"/>
+
+During initial synchronization and resynchronization, Ably sends each object on the channel as a message.
+
+For example, if a channel contains 10 objects (such as `LiveMap` and `LiveCounter` instances), a client attaching to the channel receives 10 messages during synchronization.
+
+Similarly, if a client becomes disconnected and needs to resynchronize, it receives messages for each object that needs to be synchronized.
+
+Only [reachable](/docs/liveobjects/concepts/objects#reachability) objects are counted. Ably may send [tombstone](/docs/liveobjects/concepts/objects#tombstones) objects to the client, but these will not count towards your usage.
+
+## REST API <a id="rest-api"/>
+
+The [LiveObjects REST API](/docs/liveobjects/rest-api-usage) also counts messages for operations performed.
+
+When fetching objects via the REST API, each instance of an [object type](/docs/liveobjects/concepts/objects#object-types) included in the response is counted as one message.
+
+Each operation published via the REST API counts as one message. When creating objects using the `path` field, the server constructs two messages (a create operation and a `MAP_SET` operation to assign it).