Greetings! I am developing a ServiceNow integration that relies on Amazon EventBridge to trigger ticket updates. We are starting to see significant event volume as we scale our digital channels. My current webhook consumer is running on a single EC2 instance and it is starting to drop events during peak intervals. How should I architect a scalable consumer for these EventBridge streams to ensure we never miss a conversation update?
Hello. We had this exact problem with our callback notification system. You should never point EventBridge directly at a single web server. Instead, you should route your EventBridge rule to an Amazon SQS queue.
Your EC2 instances can then poll the SQS queue at their own pace. If you have a massive spike, the events just sit safely in the queue until your servers can catch up.
It is a much more resilient pattern for high-volume integrations.
I agree with the SQS approach. We use it for our Salesforce sync. To make it even more scalable, you can use AWS Lambda as the consumer for the SQS queue.
Lambda will automatically scale up the number of concurrent executions based on the number of messages in the queue. This way, you do not have to manage EC2 instances at all, and you only pay for the processing time you actually use.
It is the gold standard for EventBridge consumers.
Hey. Just a quick tip from a SIP guy. Make sure your webhook consumer is idempotent! EventBridge and SQS both guarantee ‘at least once’ delivery, which means you will occasionally get the same event twice.
If your logic just blindly updates ServiceNow, you will end up with duplicate comments on your tickets. Always check the eventID before you process the update.