Go EventBridge consumer hitting Lambda concurrency limits on high-volume interaction events

Looking for advice on processing high-volume interaction events from EventBridge without hitting Lambda concurrency limits. I have a Go service running in Lambda that consumes /api/v2/analytics/events webhooks. When traffic spikes, the default concurrency cap gets hit, causing 429 Too Many Requests errors from the Genesys Cloud API when trying to fetch interaction details using client.InteractionsAPI.GetInteraction(ctx, interactionId).Execute(). My current handler processes events synchronously, which blocks the Lambda container. I’ve tried increasing the batch size in the EventBridge mapping template, but that just pushes more load onto the Lambda. Here is a snippet of my retry logic using go-retryablehttp:

go
client := retryablehttp.NewClient()
client.RetryMax = 3
client.RetryWaitMin = time.Second
resp, err := client.Get(url)

I suspect I need to implement an async processing pattern. Should I be pushing these events to an SQS queue with FIFO ordering and processing them with a separate Go service, or is there a way to handle backpressure within the Lambda handler itself? Also, does the Genesys Cloud API have any specific rate limiting headers I should parse in Go to implement exponential backoff more effectively than just retrying blindly?

TL;DR: Batch your fetches.

This is caused by synchronous execution per event. Switch to a single Go Lambda that polls SQS with MaxReceiveCount and batches the GetInteraction calls.

// Use batch processing in your Lambda handler
for _, msg := range records {
 batch = append(batch, msg.Body)
}
// Fetch all interactions in parallel or sequential batch
client.InteractionsAPI.GetInteractions(ctx, batch...).Execute()

The quickest way to solve this is to implement batched retrieval combined with token rotation to avoid hitting OAuth limits alongside API rate limits. The suggestion above correctly identifies batching, but you must also handle the OAuth token lifecycle carefully in high-throughput Lambda environments. If your Lambda instances share a cached token, concurrent executions will compete for the same token’s request quota, leading to 401 Unauthorized or 429 Too Many Requests errors.

Here is how to structure your Go handler for resilience:

1. Batch IDs from SQS: Collect interaction IDs from the SQS batch.
2. Use GetInteractions: Use the bulk endpoint /api/v2/interactions instead of individual calls.
3. Refresh Token on 401: Implement a retry logic that refreshes the OAuth token if a 401 is received.

// Example: Bulk fetch interactions
ids := []string{}
for _, record := range event.Records {
 ids = append(ids, record.Body)
}

// Use the bulk endpoint
resp, err := client.InteractionsAPI.GetInteractions(ctx, ids...).Execute()
if err != nil {
 // Check for 401 and refresh token here
 if resp.StatusCode == 401 {
 refreshToken()
 resp, err = client.InteractionsAPI.GetInteractions(ctx, ids...).Execute()
 }
}

Ensure your OAuth client has the interaction:view scope. Also, set the Lambda Reserved Concurrency to match your SQS batch size to prevent uncontrolled scaling. This approach reduces API calls by orders of magnitude and stabilizes your audit log extraction pipeline.

I typically get around this by isolating the API client lifecycle. 1. Define a module for the Go handler. 2. Instantiate platformClient outside the Lambda handler to reuse connections. 3. Use exponential backoff for retries. This prevents state drift in concurrent executions. The suggestion above is valid, but connection pooling is mandatory for stability.

If I remember correctly, you are overcomplicating the payload transformation inside the Lambda. Just map the interactionId directly from the webhook body using $.data.interactionId and skip the synchronous API call entirely.

// Extract ID directly from event, no API call needed
id, _ := jsonpath.Get("$.data.interactionId", eventBody)