[ftf-304] Adding pricing examples #3090
Conversation
Adds four worked pricing examples to help customers estimate costs for common use cases: - Livestream chat – high-concurrency event chat with batching (Chat) - Support chat – 1:1 customer support with consumption vs MAU comparison (Chat) - Data broadcast – one-to-many updates with conflation (Pub/Sub) - Realtime dashboard – many-to-few device monitoring (Pub/Sub) Each example includes assumptions, cost summary, message breakdown, and relevant optimisation notes (batching, conflation, etc).
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
m-hulbert
left a comment
m-hulbert
left a comment
There was a problem hiding this comment.
This is really great thanks, Jamie. I've dropped a few comments and suggestions throughout and they are mostly all relevant to all 4 examples rather than me repeating myself 4 times 🙂
| @@ -0,0 +1,68 @@ | |||
| --- | |||
| title: Data broadcast | |||
| meta_description: "Calculate Pub/Sub pricing for live sports betting platforms delivering real-time odds updates. Example shows how message conflation reduces costs from $1,800 to $360/month for 10K users across 50 matches." | |||
There was a problem hiding this comment.
This makes it seem like it's only relevant to sport betting platforms, and not data broadcast in general. We also use realtime throughout please.
| title: Data broadcast | ||
| meta_description: "Calculate Pub/Sub pricing for live sports betting platforms delivering real-time odds updates. Example shows how message conflation reduces costs from $1,800 to $360/month for 10K users across 50 matches." | ||
| meta_keywords: "sports betting, live odds, real-time odds updates, message conflation, Pub/Sub pricing, betting platform, live sports data, odds streaming, realtime data delivery, Ably Pub/Sub pricing" | ||
| intro: "This Pub/Sub example demonstrates consumption-based pricing for a realtime data broadcast – a single source publishing frequent updates to many subscribers." |
There was a problem hiding this comment.
| intro: "This Pub/Sub example demonstrates consumption-based pricing for a realtime data broadcast – a single source publishing frequent updates to many subscribers." | |
| intro: "This example uses consumption-based pricing for a realtime data broadcast use case, where a single source is publishing frequent updates to many subscribers using Ably Pub/Sub." |
| meta_keywords: "sports betting, live odds, real-time odds updates, message conflation, Pub/Sub pricing, betting platform, live sports data, odds streaming, realtime data delivery, Ably Pub/Sub pricing" | ||
| intro: "This Pub/Sub example demonstrates consumption-based pricing for a realtime data broadcast – a single source publishing frequent updates to many subscribers." | ||
| --- | ||
| For this example, we're using a sports betting scenario (odds updates → bettors), but the same pattern applies to any broadcast where only the latest value matters: stock tickers, live scores, auction platforms, transport arrivals, etc. |
There was a problem hiding this comment.
We use 2nd person pronouns throughout in docs please, so no "we" or "our".
I'd also suggest expanding out parenthesis so it's more like;
This example uses a sports betting scenario where odds are updated and fanned out to bettors. The same pattern applies to any broadcast where only the latest value matters, such as stock tickers, live scores, auction platforms and transport arrivals.
| --- | ||
| For this example, we're using a sports betting scenario (odds updates → bettors), but the same pattern applies to any broadcast where only the latest value matters: stock tickers, live scores, auction platforms, transport arrivals, etc. | ||
|
|
||
| ### Assumptions |
There was a problem hiding this comment.
All your headings should start at H2 (##).
| Conflation intervals are configurable from 100ms to 500ms – lower intervals reduce latency; higher intervals reduce message volume and costs. | ||
| </Aside> | ||
|
|
||
| ### Cost summary |
There was a problem hiding this comment.
It doesn't effect the output, but if could leave an empty line between headings, paragraphs and tables etc. it makes it a bit more readable for other editors.
|
|
||
| ### Further optimization: Delta compression | ||
|
|
||
| For richer payloads (full market depth, live statistics), delta compression can reduce bandwidth costs by sending only the difference between updates. |
There was a problem hiding this comment.
Suggest adding a link and not overusing parenthesis.
| For richer payloads (full market depth, live statistics), delta compression can reduce bandwidth costs by sending only the difference between updates. | |
| For richer payloads such as full market depth or live statistics, [delta compression](/docs/channels/options/deltas) can reduce bandwidth costs by sending only the difference between updates. |
| @@ -0,0 +1,68 @@ | |||
| --- | |||
| title: Data broadcast | |||
There was a problem hiding this comment.
I think we should include 'pricing example' in the title.
| | Full market (10+ selections) | 8 KiB | ~2 KiB | 75% | | ||
| | Live stats + odds bundle | 15 KiB | ~4 KiB | 73% | | ||
|
|
||
| <Aside data-type='further-reading'> |
There was a problem hiding this comment.
Unforunately these don't format well on their own. If you add a short intro line before the bullet list then they do.
| | Channel minutes | 250K conversations × 20 mins | 5,000,000 | $5.00 | | ||
|
|
||
| ### Consumption vs MAU comparison | ||
| Consumption-based pricing works better for support chat because customers connect briefly and infrequently, using far less than the MAU allowances (20K messages, 2K connection minutes). |
There was a problem hiding this comment.
| Consumption-based pricing works better for support chat because customers connect briefly and infrequently, using far less than the MAU allowances (20K messages, 2K connection minutes). | |
| Consumption-based pricing works better for support chat because customers connect briefly and infrequently, using far less than the Monthly Active User (MAU) allowances which are 20,000 messages and 2,000 connection minutes. |
|
|
||
|
|
||
| <Aside data-type='further-reading'> | ||
| - [Talk with our sales team](https://ably.com/contact) to get a personalised quote. |
There was a problem hiding this comment.
| - [Talk with our sales team](https://ably.com/contact) to get a personalised quote. | |
| - [Talk with our sales team](https://ably.com/contact) to get a personalized quote. |
paddybyers
left a comment
paddybyers
left a comment
There was a problem hiding this comment.
I really found these pages confusing when I first read them. The summary costs table at the top has numbers and calculations that have no obvious relationship to the assumptions. Obviously when you scroll down it's clear where the numbers come from, but some hint upfront would help.
| | Messages (with batching) | ~901M × $2.50/M | $2,252 | | ||
| | Room reactions (with batching) | ~70M × $2.50/M | ~$175 | | ||
| | Connection minutes | 1.5M mins × $1.00/M mins | $2 | | ||
| | Moderation (Ably) | ~360K msgs × 1 rule invocatio | $1 | |
There was a problem hiding this comment.
| | Moderation (Ably) | ~360K msgs × 1 rule invocatio | $1 | | |
| | Moderation (Ably) | ~360K msgs × 1 rule invocation | $1 | |
| ### Cost summary | ||
| The high-level cost breakdown for this scenario. Messages are billed for both inbound (published to Ably) and outbound (delivered to subscribers) – a single message to 100 subscribers generates 101 billable messages. | ||
|
|
||
| | Item | Calculation | Cost | |
There was a problem hiding this comment.
The dollar results in this table are rounded to integer dollars so they look wrong. Eg 1.5 x $1 = $2. They shouldn't be rounded
Description
Adds four worked pricing examples to help customers estimate costs for common use cases:
Each example includes assumptions, cost summary, message breakdown, and relevant optimisation notes (batching, conflation, etc).
Checklist