Hi Jorge as previously advised your use case seems to be a job queue, with a publisher(the chatbot) and multiple subscribers(workers) that actually process data coming from the chatbot in a delayed manner, where each worker picks a job from the queue and processes it. Kafka, Kinesis could fit but are more streaming oriented and provide you with less control over job retry and workers scaling as the client library often handles most of the sharding, so less loosely bound. RabbitMQ and SQS instead are born for this job. I'd suggest SQS or any similar managed queue service as you don't have to worry about all the scaling issues relateed with a message broker (obviously you can find RabbitMQ as a service but tends to cost more and is billed depending on tier (CPU,RAM) where SQS is billed only on message count and number of read requests). With SQS you can simply create a queue where your chatbot sends all the messages (it could be FIFO to preserve ordering or not), on the other side you have N workers that poll the queue and pick jobs to execute. The worker then has to acknowledge the message was processed ok by deleting it. You can define a visibility window for the messages, this prevents multiple workers from reading the same messageduring the window thus granting the message is processed only once. For robustness you can define how many times a message can be read (so the associated failed job retried) and eventually forward messages that fail too many times to another queue (maybe for later analysis).
PS: SQS is the first serice AWS ever developed so it's quite robust to day :D