A weather-data solution receives telemetry from thousands of stations via an API Gateway REST API integrated with a Lambda function. The Lambda calls a third-party service for preprocessing; when that third party becomes overloaded, preprocessing fails and data is lost. The architect must ensure no data is lost and enable processing to occur later if failures happen. What should the architect implement?

The correct solution uses Amazon SQS as an intermediary buffer to decouple the API Gateway from the Lambda function, preventing data loss during third-party service overloads. The API Gateway sends messages to the primary SQS queue. The Lambda function is then configured to process messages from this primary queue. If the Lambda encounters an error (e.g., due to the overloaded third-party service), the message is not lost but instead moved to the secondary SQS queue, which acts as a Dead-Letter Queue (DLQ) for the primary queue. This ensures data persistence and allows for later reprocessing. Option 1 is incorrect because configuring an SQS DLQ for the API Gateway itself doesn't provide the necessary buffering before the Lambda invocation. Option 3 and 4 are incorrect because EventBridge is primarily an event router, not a message queue designed for reliable buffering and retry mechanisms in the same way SQS is for this scenario. While EventBridge can handle failures, SQS with a DLQ is a more direct and robust solution for ensuring message persistence and retry logic when a downstream service is unavailable.