Save Transaction Costs for Real-time Solutions with Signals
When building real-time applications, leveraging real-time platforms to handle the hard work of communicating your data in real time allows developers to focus on what matters most. However, understanding the cost structures of different providers is crucial, and how to optimize these costs allows you and your team to continue to depend on these real-time solutions without needing to build them in-house to save costs.
In the case of transaction-based models, one such method is to utilize a high-volume stream of payloads when sending data that may be smaller in size and contain other limitations but cost substantially less per transaction. This is the case for PubNub as well, through the use of Signal Transactions, which are generated by publishing Signals. Continue reading to learn more about the various types of pricing models of real-time infrastructures and how you can improve your costs by utilizing something akin to Signals.
Understanding Real-Time Infrastructure Costs
Although they may differ by name, there are effectively three different methods (or a combination of) real-time solutions utilize to charge for their services at a base level (not including other market conditions, incentives, bonuses, and other cost reductions offered by the service providers).
Per Device Model
Per-device pricing charges you for each device connected to your service. This model is straightforward and predictable, making it easier to estimate costs based on the number of users. It is especially helpful in IoT applications, where each device represents a unique connection. However, it can become expensive if your users connect with multiple devices and can spike in costs when the usage fluctuates.
PubNub also used to base part of our pricing model on the number of connected devices, which worked in the short term. However, our customers found that if they wanted to do something like putting PubNub on their homepage, it would be cost-prohibitive because the number of devices could unpredictably spike, along with their costs, causing a high volatility environment. Since then, we have shifted to monthly active users and transaction-based models.
Monthly Active Users (MAU) Model
The MAU model charges you based on the number of active users each month. This is perfect if your app has consistent user engagement. Charges are based on the number of users who connect to your service each month, regardless of how many devices they may have connected to your application. This pricing model is ideal for apps with a steady, predictable user base and is one of the reasons why PubNub chooses to utilize MAUs as one of our pricing models.
However, remember that this pricing model can get expensive if many users are inactive or the app has seasonal spikes. There are ways of improving these issues, especially for inactive users, but that will be covered in a future post.
Transaction-Based Pricing Model
The transaction-based model charges per message or API call. It’s ideal for apps with variable usage patterns, high-frequency interactions, or a high number of users (and low transaction costs). It scales with actual usage, potentially lowering costs for infrequent interactions.
The issue with transaction-based pricing models is that they can become quickly unpredictable during high usage periods, skyrocketing costs during peak seasons. Because of this reason, PubNub customers typically go with a custom pricing model based on both MAUs and transaction-based pricing to gain the benefits of both models.
Although there are negatives about the different pricing models, there are numerous ways of minimizing higher transaction costs when utilizing real-time solutions to help keep transaction fees down. This blog post focuses on improving costs through transaction-based pricing models when sending data.
Publishing Data: Message vs. Signals
At PubNub, you have two main methods for publishing/sending data: Message and Signals.
Messages
A PubNub Message allows you to send data of any size anywhere in the world in less than 100 ms. It’s flexible, as it can contain any kind of serializable data, like objects, numbers, and UTF-8 encoded strings, with a max size of 32 Kibibytes (KiB). Its format may be plain text, a URL-encoded object, or, most commonly, JavaScript Object Notation (JSON). Messages also have guaranteed message delivery, persist the message data via Message Persistence (storage), and can be used in conjunction with Mobile Push Notifications.
In-App Chat: Build direct, group, and large-scale chat. Manage users, store data, moderate profanity, and integrate with third-party apps on the edge.
Multiuser Collaboration: Build virtual whiteboards or classrooms to enable multiple users to collaborate simultaneously in documents, worksheets, and other digital workspaces.
Live Audience Engagement: Drive event-based engagement with mass chat, live polling, and programs for halftime and intermission. Enhance program content with stats, ads, offers, and live blogging.
Transport and Delivery: Optimize logistics, dispatch, and delivery with real-time proximity matching, location tracking, chat, time-sensitive alerts/notifications, and live dashboards.
Gaming: In-game chat, live leaderboards, friend lists, multiplayer synchronization, and more.
Player and Bullet Coordinates: Track player position and bullet coordinates from weapons.
Signals
Signals are designed for sending lightweight payloads, such as typing indicators, position coordinates, or simple status updates. They are best used for high-volume data streaming, as they have a 64-byte limit, can’t persist the payload in Message Persistence, and can’t invoke Mobile Push Notifications through our platform. Finally, while signals generally provide the same reliability and latency as published Messages, there is no guarantee of this delivery, unlike Messages.
Signals are typically used for the following reasons:
Typing Indicators: Many chat applications use typing indicators to show when a user is typing.
GPS Tracking: Applications that track the movement of assets or people can use Signals to send small, frequent updates on position.
Stock Price Alerts: Send rapid updates on stock price changes or market movements.
Home Automation Alerts: Notify when a door is opened or closed or the state of an alarm.
Queue Status: Provide real-time updates on queue positions or wait times, as well as when their turn is approaching.
Player and Bullet Coordinates: Track player position and bullet coordinates from weapons.
Matchmaking: Quickly communicate skill-based matchmaking rank to different clients.
Cost Efficiency and Transaction Classification
While Messages seem to be the better option, you need to consider your real-time solution’s method of classifying transactions. Here is a table consisting of the different transaction types and the cost per unit in the PubNub Platform from the transaction-based pricing documentation.
Note: Please keep in mind that while these costs are correct at the time of publishing, you should take a look at the documentation for the most up-to-date transaction prices. Furthermore, transaction pricing for contracts is heavily discounted and way less than these rates. Please feel free to contact our sales team for more information.
For PubNub, while they can contain up to 32KiB, message publishes are considered to be a part of Replicated Transactions (Message Publish, Access Tokens, Storage writes), which can generate high transaction costs after millions of transactions. Furthermore, each transaction can consist of up to a 2048-byte payload, which could be counted as multiple transactions to ensure guaranteed delivery.
Signals, on the other hand, while they are not 100% guaranteed for reliable Message delivery and have a much smaller payload, are significantly cheaper per transaction, as they are classified as a Signal Transaction in the PubNub pricing model. Signals are less than 1/10 the cost of a Message publish, whereas if your app has a lot of transactions, it can save you a lot of money as your app scales, making them the more cost-effective option.
Consider the following table to show as an example, starting with 1,000 transactions:
As you can see, the costs begin to accumulate dramatically, especially if you are strictly on the transaction-based model pricing and only use Messages. Signals begin to look like the more appealing option!
Although Signals are limited to 64 bytes, you can still make the most of them with smart strategies:
Optimization of Payload:
Essential Information Only: Send only the necessary information, removing any unnecessary components.
Encoding and Compression: Use techniques like base64 encoding or other forms of compression to reduce the size of your data.
Data Structuring:
JSON Minification: Remove unnecessary whitespace and use short keys in JSON objects.
Bitwise Operations: Use bitwise operations for numerical data to encode multiple small values into a single byte.
Binary Data: Use binary data formats which are often more compact than text formats.
Internal Identifiers: Use state identifiers or version numbers to indicate the relative state, reducing the need for full context
Efficient Parsing: Agree on predefined structures so that receiving clients can easily interpret the data or have lookup tables on the client side to decode the small payload codes.
Use Delimeters: Separate different pieces of data within the payload using delimiters, ensuring each part is small but collectively informative.
Frequency of Updates:
Batch Updates: Instead of sending multiple signals in quick succession, batch small updates into a single signal where possible.
Event Triggers: Send signals based on significant events or thresholds rather than continuous updates.
For scenarios where Signals alone aren’t sufficient due to their size limitations, you can effectively combine both Publish and Signals to optimize your messaging strategy. This way, you can utilize the different types of transactions to not only effectively power your application, but also save on costs.
Select the Price Model Best for You
By choosing the pricing model that best suits your application, as well as utilizing the appropriate transaction type (Signals vs Messages, or both), you can significantly reduce costs while maintaining the real-time experience your users need.
If you’ve determined that PubNub is the best real-time solution for you and are exploring our platform through our always-free account, be sure to explore our pricing options to see if either the MAUs or transaction-based pricing models are right for you. If the transaction-based pricing model is more of a fit for your application, be sure to check out the different transaction classifications and PubNub’s transactions pricing guide for more details.
Have any questions or feedback? Feel free to reach out to devrel@pubnub.com at any time.
