-
Notifications
You must be signed in to change notification settings - Fork 46
[DX-883] Addresses message billing docs gap #3234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
4a0cdaa
8740f05
5e125be
5e025c1
a3095e9
77a4251
3119aa2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -57,6 +57,10 @@ export default { | |
| }, | ||
| ], | ||
| }, | ||
| { | ||
| name: 'Spaces pricing', | ||
| link: '/docs/spaces/pricing', | ||
| }, | ||
| ], | ||
| api: [ | ||
| { | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -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." | ||||||
| redirect_from: | ||||||
| - /docs/chat/message-billing | ||||||
| --- | ||||||
|
|
||||||
| 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. | ||||||
|
|
||||||
| <Aside data-type="further-reading"> | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd suggest putting this after the table on message counting and dropping the second sentence about package comparisons. |
||||||
| For how all Ably products count messages, see [message counting](/docs/platform/pricing/message-counting). For package comparison and volume discounts, see the [pricing](https://ably.com/pricing) page. | ||||||
| </Aside> | ||||||
|
|
||||||
| ## Chat operations <a id="operations"/> | ||||||
|
|
||||||
| The following table shows how Chat operations contribute to your message count: | ||||||
|
|
||||||
| | Operation | Messages counted | | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd suggest something like this format, to make the tables more readable and have fewer repeated links: | Operation | Messages counted |
| --- | --- |
| [Pub/Sub](/docs/pub-sub) ||
| Publish | 1 inbound message |
| Message delivery | 1 outbound message per subscriber |
| [Presence](/docs/presence-occupancy/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 |
| [Message persistence](/docs/storage-history/storage) ||
| Persistence storage | 1 additional message per stored message |
| History retrieval | 1 message per retrieved message | |
||||||
| | --- | --- | | ||||||
| | [Send message](/docs/chat/rooms/messages) | 1 inbound message | | ||||||
| | Message delivery | 1 outbound message per subscriber | | ||||||
| | [Update message](/docs/chat/rooms/messages#update) | 1 inbound message | | ||||||
| | Message update delivery | 1 outbound message per subscriber | | ||||||
| | [Delete message](/docs/chat/rooms/messages#delete) | 1 inbound message | | ||||||
| | Message deletion delivery | 1 outbound message per subscriber | | ||||||
| | [History](/docs/chat/rooms/history) retrieval | 1 message per retrieved message | | ||||||
| | [Typing indicator](/docs/chat/rooms/typing) keystroke | 1 inbound message; repeats every heartbeat interval (default 10s) | | ||||||
| | Typing indicator delivery | 1 outbound message per subscriber per heartbeat | | ||||||
| | [Typing indicator](/docs/chat/rooms/typing) stop | 1 inbound message | | ||||||
| | Typing stop delivery | 1 outbound message per subscriber | | ||||||
| | [Room reaction](/docs/chat/rooms/reactions) | 1 inbound message | | ||||||
| | Room reaction delivery | 1 outbound message per subscriber | | ||||||
| | [Message reaction](/docs/chat/rooms/message-reactions) send | 1 inbound message | | ||||||
| | [Message reaction](/docs/chat/rooms/message-reactions) delete | 1 inbound message | | ||||||
| | Message reaction summary delivery | 1 outbound message per subscriber; multiple reactions may be rolled up into a single summary | | ||||||
| | [Presence enter](/docs/chat/rooms/presence) | 1 inbound message | | ||||||
| | [Presence leave](/docs/chat/rooms/presence) | 1 inbound message | | ||||||
| | [Presence update](/docs/chat/rooms/presence) | 1 inbound message | | ||||||
| | Presence event delivery | 1 outbound message per presence subscriber | | ||||||
| | [Occupancy](/docs/chat/rooms/occupancy) event | 1 outbound message per subscriber (generated on membership changes, debounced up to 15s) | | ||||||
| | [Moderation](/docs/chat/moderation) action | 1 inbound message; triggers a message update or delete which follows standard delivery | | ||||||
|
|
||||||
| ## Rooms, channels, and connections <a id="rooms-connections"/> | ||||||
|
|
||||||
| Each Chat room maps to underlying Pub/Sub channels. Each room feature (messages, typing, reactions, presence, occupancy) uses its own channel, contributing to your [channel count](/docs/platform/pricing#channels). Ably bills each connected client for [connection minutes](/docs/platform/pricing#connections) in the same way as Pub/Sub. | ||||||
|
Comment on lines
+45
to
+47
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should separate these out considering we charge for them independently. I also think it's worth having the explanations here rather than pushing people back to Pub/Sub to understand them. |
||||||
|
|
||||||
| ## Cost optimization <a id="optimization"/> | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is it worth adding some quick info on detaching from rooms and closing connections? |
||||||
|
|
||||||
| ### 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. | ||||||
|
|
||||||
| ### Disable typing indicators | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure this needs to be stated, since they'd only be enabled if someone set them up. |
||||||
|
|
||||||
| Disable typing indicators entirely in rooms where they are not needed. This eliminates a significant source of messages, especially in rooms with many participants. | ||||||
|
|
||||||
| ### Use server-side batching | ||||||
|
|
||||||
| [Server-side batching](/docs/guides/pub-sub/data-streaming#solution-server-side-batching) groups messages into single deliveries. Use this for high-throughput rooms where slight delay is acceptable. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is odd to link to a Pub/Sub guide rather than the SSB page. |
||||||
|
|
||||||
| ### 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. This avoids the n-squared presence event fan-out. For example, 200 members joining and leaving generates approximately **80,400 messages**. See [large-scale presence sets](/docs/presence-occupancy/presence#large-presence) for details. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
|
||||||
| ### Enable server-side presence batching | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure this needs a separate callout since we have SSB above. |
||||||
|
|
||||||
| Enable [server-side batching](/docs/presence-occupancy/presence#large-presence) to group presence events. Subscribe to presence updates only on rooms where you need member-level detail. | ||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,15 @@ | ||
| --- | ||
| title: Billing | ||
| meta_description: "Understand how LiveObjects operations contribute to your Ably usage and billing." | ||
| 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." | ||
| redirect_from: | ||
| - /docs/liveobjects/concepts/billing | ||
| --- | ||
|
|
||
| <If lang="javascript"> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's released now, so we can drop this whole aside. |
||
| <Aside data-type='public-preview'> | ||
| LiveObjects JavaScript is in Public Preview. We are committed to supporting the LiveObjects Javascript API and welcome adoption and feedback. | ||
| LiveObjects JavaScript is in Public Preview. Ably is committed to supporting the LiveObjects JavaScript API and welcomes adoption and feedback. | ||
|
|
||
| **Building with LiveObjects?** Help shape its future by [sharing your use case](https://44qpp.share.hsforms.com/2fZobHQA1ToyRfB9xqZYQmQ). | ||
| </Aside> | ||
|
|
@@ -25,26 +29,38 @@ meta_description: "Understand how LiveObjects operations contribute to your Ably | |
| </Aside> | ||
| </If> | ||
|
|
||
| LiveObjects operations are billed as messages. This page explains how different LiveObjects operations contribute to your Ably usage. | ||
| LiveObjects operations are billed using ObjectMessages. Each ObjectMessage follows the standard inbound/outbound counting pattern. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should explain what that is again briefly, as this is assuming someone read the main/original page. |
||
|
|
||
| <Aside data-type="further-reading"> | ||
| For general information about Ably pricing and billing, see [Pricing](/docs/platform/pricing). | ||
| For how all Ably products count messages, see [message counting](/docs/platform/pricing/message-counting). For package comparison and volume discounts, see the [pricing](https://ably.com/pricing) page. | ||
| </Aside> | ||
|
|
||
| ## Message counting <a id="message-counting"/> | ||
| ## LiveObjects operations <a id="operations"/> | ||
|
|
||
| Each operation is sent as an [`ObjectMessage`](/docs/liveobjects/concepts/operations#properties). Ably bills for each outbound message sent from a client, and for each inbound message delivered to each client. | ||
| The following table shows how LiveObjects operations contribute to your message count: | ||
|
|
||
| When a client performs an operation (such as setting a value on a `LiveMap` or incrementing a `LiveCounter`), this generates an outbound message. When that operation is broadcast to other connected clients, each client receives an inbound message. | ||
| | Operation | Messages counted | | ||
| | --- | --- | | ||
| | [LiveMap](#livemap-operations) set or remove | 1 inbound message per operation | | ||
| | [LiveMap](#livemap-operations) create (shallow) | 2 inbound messages (create + assign) | | ||
| | [LiveCounter](#livecounter-operations) increment or decrement | 1 inbound message | | ||
| | [LiveCounter](#livecounter-operations) create | 2 inbound messages (create + assign) | | ||
| | ObjectMessage delivery | 1 outbound message per connected client | | ||
| | [Synchronization](#synchronization) | 1 message per object synchronized | | ||
| | [REST API](#rest-api) fetch | 1 message per object in response | | ||
| | [Batch](#livemap-operations) operation | 1 message per operation in the batch | | ||
|
|
||
| For example, if 5 clients are connected to a channel and one client increments a counter: | ||
| Nested object creation generates additional messages for each nested object. See the [examples below](#livemap-operations) for details. | ||
|
|
||
| - 1 outbound message (from the client performing the increment) | ||
| - 5 inbound messages (one delivered to each of the 5 connected clients, including the client that sent it) | ||
| ## Channels and connections <a id="channels-connections"/> | ||
|
|
||
| Each LiveObjects channel contributes to your [channel count](/docs/platform/pricing#channels). Ably bills [connection minutes](/docs/platform/pricing#connections) per minute of connection time for each connected client. | ||
|
|
||
| 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. | ||
|
|
||
| <If lang="javascript"> | ||
|
|
||
| ## LiveMap operations <a id="livemap-operations"/> | ||
| ## LiveMap operation examples <a id="livemap-operations"/> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Aware these were here already, but do you think they're required? As in, we're linking out to the feature pages themselves for other products, but here we're adding code samples (arguably out of context). What do you think? |
||
|
|
||
| Removing a key and setting a primitive value always sends one message: | ||
|
|
||
|
|
@@ -100,7 +116,7 @@ await myObject.get('settings').batch((ctx) => { | |
| ``` | ||
| </Code> | ||
|
|
||
| ## LiveCounter operations <a id="livecounter-operations"/> | ||
| ## LiveCounter operation examples <a id="livecounter-operations"/> | ||
|
|
||
| Incrementing and decrementing a counter always sends one message: | ||
|
|
||
|
|
@@ -165,10 +181,6 @@ Similarly, if a client becomes disconnected and needs to resynchronize, it will | |
|
|
||
| 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. | ||
|
|
||
| ## Subscriptions <a id="subscriptions"/> | ||
|
|
||
| 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. | ||
|
|
||
| ## REST API <a id="rest-api"/> | ||
|
|
||
| The [LiveObjects REST API](/docs/liveobjects/rest-api-usage) also counts messages for operations performed. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't need this as that page never existed.