This document explains how you can best prepare to handle high message volume to your webhook. The Business Messages platform is production-ready for many different scenarios. Our support team can also help you prepare if you are anticipating a specific event. You can take a few simple steps to make your webhook more robust.
User-to-webhook traffic
For user-to-webhook traffic, consider what kind of traffic pattern you expect for your business. Do you expect any "bursty" patterns or sudden changes in message volume? For example, a restaurant that serves only dinner may expect many messages in the evening and few messages for the rest of the day. In another example, a store that is running a special promotion can expect abnormally large message volume when the promotion is announced.
In general, Google infrastructure is prepared to handle sudden bursts of traffic. Business Messages uses the same server resources as large products like Gmail and Google Cloud. It's unlikely that message volume to your webhook will be so high that Business Messages will be the point of failure. Additionally, Business Messages queues each agent's messages separately. If one of your agent's message queues becomes congested, it will not affect your other agents, even if they share the same webhook.
However, this only applies to the message queue in the Business Messages infrastructure. Once the message is delivered to your webhook, it's a different story. You should ensure your webhook can scale as needed by implementing queues, handling requests in parallel, and so on. If your webhook responds to a message with an HTTP 500, or fails to respond at all, Business Messages will exponentially back off message delivery rate to your webhook. Messages remain in the queue for 7 days. If your webhook does not respond with an HTTP 200 in that time, Business Messages will drop the message.
Webhook-to-user traffic
Messages sent from your webhook should follow a 60 messages per minute per conversation quota. Legitimate message flows are unlikely to reach this quota, but you should be prepared to handle HTTP 429 errors from Business Messages which indicate you are exceeding the quota.
Generally speaking, if your webhook receives an HTTP 429 or an HTTP 500 from Business Messages, this indicates a transient error which may be related to your messaging rate. You should retry these messages with an exponential backoff strategy. However, if your webhook receives an HTTP 503 or an HTTP 4xx (other than HTTP 429), you should stop retrying and notify our support team right away. These error codes could indicate a difficulty with Business Messages infrastructure, like a DOS incident, and sending more messages would only exacerbate the problem.
While there's no specific suspension criteria related to exceeding messaging quotas, Business Messages may suspend agents which are behaving irregularly or sending far too many messages. Please review the suspension criteria to ensure your agent is following required standards.
How to get help
It's best to reach out as soon as you anticipate a problem. If you let us know you're expecting an extremely high-traffic situation, like a highly advertised promotional campaign, we can spin up additional serving resources to be as prepared as possible. However, in most cases, measures like this aren't necessary.
You can also contact us if you are already experiencing a messaging load problem, and we'll do our best to help you resolve it.