Right now a user can send several messages at once (flooding/spamming) and the bot will try to answer them all and end up crashing or making countless requests to external services. One solution would be to hardcode a limit for the amount of messages the bot can queue to process, 3 sounds fine. So let's suppose the limit is in place and the user sends the following messages in a row: Hi What can you do When is the store open What can I buy The bot would answer to just the first three messages and ignore the last, which doesn't sound like bad UX to me - it's an edge case. Users usually wait to get a reply before continuing, but imagine the bot is very slow, or the user is a troller - that's the problem. Later we could be able to define a custom limit, but a hardcoded one is enough for now.

Hi, I was going to mention this, however the approach I had in mind was a bit different. Spamming would come in the form most times scripts, so at the infrastructure layer , you can look use user agent details and other key signals

Bumping this up. Could be done by IP address, or perhaps a layer that requires a user sign-in of some sort. Would allow for selling bots on a B2C basis.