Optimizing Lambda Concurrency for Genesys Cloud EventBridge Interaction Events

What is the standard approach to process high-volume interaction events from EventBridge without hitting Lambda concurrency limits?

• We are currently ingesting interaction lifecycle events from Genesys Cloud via AWS EventBridge and routing them to an AWS Lambda function for real-time metric calculation in New Relic.
• During peak call center hours, our Lambda function consistently hits the account-level concurrency limit, resulting in dropped events and data gaps in our NRQL dashboards.
• The current implementation processes each event individually, which is inefficient given the bursty nature of Genesys Cloud webhooks.
• The error observed in CloudWatch logs is: 2023-10-27T14:35:12.456Z ERROR: Unhandled rejection. Error: Lambda concurrency limit exceeded.
• We have attempted to increase the reserved concurrency, but this only delays the issue rather than solving the root cause of inefficient processing.
• The current Lambda handler code is as follows:

def lambda_handler(event, context):
for record in event['Records']:
payload = json.loads(record['body'])
interaction_id = payload['interactionId']
# Heavy processing logic here
calculate_metrics(interaction_id)
send_to_new_relic(interaction_id)

• We suspect that batching the events or using a queue-based architecture (such as SQS) might help, but we are unsure of the best practice for maintaining event order and ensuring at-least-once delivery.
• Specifically, we need to know if we should implement a batch window in the EventBridge rule to aggregate events before sending them to Lambda.
• Alternatively, should we offload the heavy processing to an SQS queue and have the Lambda function poll the queue with a larger batch size?
• We are looking for a code-level solution that balances throughput with cost efficiency, while ensuring no interaction events are lost during peak loads.

My usual workaround is to abandoning the idea that a single Lambda should handle raw EventBridge fan-out for high-volume telephony data. The JS SDK is designed for browser clients with specific lifecycle hooks that clash with Node… wait, wrong thread. My bad.

The real issue isn’t just concurrency limits; it’s the cold start overhead and the payload size. Genesys Cloud interaction events are heavy. If you’re parsing the full JSON in the Lambda, you’re burning compute time before you even hit New Relic.

You need to decouple the ingestion. Put an SQS queue in front of your Lambda. EventBridge → SQS → Lambda. This buffers the burst and lets you control the batch size. But here’s the kicker: don’t send the full interaction object. Use a Genesys Cloud Webhook to send a minimal payload to a lightweight API Gateway endpoint that pushes to SQS.

Here’s the payload structure I use to keep things lean. You’ll need to map this in your Architect flow or use a webhook transformation:

{
 "interactionId": "12345-abcde",
 "type": "call",
 "timestamp": "2023-10-27T10:00:00Z",
 "queueId": "67890",
 "durationMs": 12000,
 "outcome": "answered"
}

In PowerShell, I validate the webhook config like this:

$Headers = @{
 Authorization = "Bearer $Token"
 ContentType = "application/json"
}
Invoke-RestMethod -Uri "https://api.mypurecloud.com/api/v2/integrations/webhooks/$WebhookId" -Headers $Headers -Method Get

Make sure your Lambda handler processes the batch from SQS, not individual records. Set the BatchSize to 100. It cuts your invocation count by 100x. You’ll still hit concurrency limits if your logic is slow, but at least you’re not dropping events. Check your New Relic ingestion rate limits too. They’re stricter than you think.