During open enrollment, API clients receive HTTP 429 responses while a Lambda function’s reserved concurrency is set far below actual demand. Code errors are not appearing in logs. What is the likely diagnosis and fix direction?
Select an answer to reveal the explanation.
Short Explanation
429s with quiet error logs often mean the bouncer—reserved concurrency—turned people away, not that the code crashed. Lift the concurrency cap carefully for open enrollment instead of deleting logs or faking success in the browser.
Full Explanation
During open enrollment, API clients receiving HTTP 429 while a Lambda function’s reserved concurrency is set far below demand—and without application exceptions in logs—points to concurrency throttling rather than code bugs. Raise reserved concurrency thoughtfully (or adjust account limits) to match expected load. Throttles manifest as 429/availability symptoms upstream even when the handler never runs, which is why logs look “clean” while citizens cannot enroll.
Treating 429 responses as successful enrollment submissions corrupts records and citizen trust. Deleting the function’s log group to hide throttle-related noise removes evidence operators need. Wrapping every API request in a 15-minute synchronous wait before invoking Lambda worsens UX and does not fix concurrency budgets.
Exam caveat: reserved concurrency both reserves and caps—raising it helps only within account concurrency limits. Distinguish function throttles from API Gateway usage-plan throttles. Burst spikes may still need queueing patterns in front of Lambda for fairness.
Operational check: confirm Throttles metrics and concurrent executions vs reserved limit; raise reserved concurrency with a documented ceiling; consider queue buffering for peak leveling; load-test enrollment; and watch 429 rates at API Gateway separately from 5xx handler errors.