We are thrilled to announce that MessagingService now has significantly higher limits, which gives you more flexibility to build features like global announcements and cross-server messaging exchanges!
We have heard your feedback that the MessagingService was too limited to achieve some of the features you envisioned. In recent months, our team has been diligently working to enhance both the reliability and scalability of MessagingService. As a result, we are able to increase the service limits for almost every category. Here are the updated limits:
Limit
Before
After
Messages sent per game server
150 + 60 * (number of players in this game server) per minute
600 + 240 * (number of players in this game server) per minute
Messages received per topic
(10 + 20 * number of servers) per minute
(40 + 80 * number of servers) per minute
Messages received for entire game
(100 + 50 * number of servers) per minute
(400 + 200 * number of servers) per minute
Subscriptions allowed per game server
5 + 2 * (number of players in this game server)
20 + 8 * (number of players in this game server)
Subscribe requests per game server
60 requests per minute
240 requests per minute
Size of message
1 KB
1 KB
These enhancements pave the way for more dynamic and instantaneous cross-server communication, aiming to enrich your experiences with deeper engagement and interactivity. This is just the beginning! We’re committed to continuously improving our systems, with plans for even more flexible rate limits and more reliable message delivery.
Please share your feedback by replying to the post. To get started, check out our latest documentation for Messaging Service.
This does NOT include the open cloud messaging API. Based on the metrics for OpenCloud we don’t see the need to increase the limit yet, but we can revisit it and work on increasing the limit as well in the future.
Great change, though what about the size of messages? While 1kb of data can be enough for quite a lot of standard uses cases i believe there may still be situations in which you would need to send multiple messages at once. Would it not technically be faster to just send a single bigger message rather than 2-3 smaller ones?
Let’s gooo! Now, all we need is messagingservice subscriptions via external APIs. This is amazing, thank y’all! This just proves that different departments have different people, which different leadership, so it’s not all of the same people and we thank each one of y’all of doing this work!
