We’ve got a custom app listening to Genesys Cloud events via EventBridge, specifically targeting the genesyscloud:conversation:status event type. The issue is that during peak hours, we’re seeing significant duplicate events hitting our consumer endpoint. The EventBridge rules seem to be firing correctly, but the downstream Lambda is processing the same conversation state change multiple times within a 5-second window.
I’ve tried using the eventId from the EventBridge payload as a unique key for a DynamoDB table to filter duplicates, but the latency between the duplicate arrivals is so low that the conditional writes are failing with ConditionalCheckFailedException. Here’s the relevant part of the handler:
def handle_event(event, context):
event_id = event['id']
# ... processing logic ...
# Deduplication check
response = table.put_item(
Item={'eventId': event_id, 'processed': True},
ConditionExpression='attribute_not_exists(eventId)'
)
if 'UnprocessedItems' in response:
return {'statusCode': 200, 'body': 'Duplicate skipped'}
The eventId is unique per EventBridge invocation, but it seems like Genesys is sending the same logical event multiple times, perhaps due to internal retries or fan-out. I need a strategy to deduplicate based on the actual conversation state change, not just the EventBridge message ID. Has anyone tackled this with a sliding window approach or a different IDempotency key? The conversation object doesn’t have a simple incrementing ID that’s easy to track across state changes.