A smart wearable device company is designing a system to process user workout telemetry events (such as activity started, heart rate milestone, activity paused, and activity completed) from fitness trackers. The events must be processed in the exact chronological sequence they are generated for each individual user workout. The backend processing application is deployed on Amazon EC2 instances. During peak hours, the backend database occasionally experiences lock contention, causing temporary processing failures. If a telemetry event fails to process, the system must retry it. If it fails 5 times, it must be isolated for analysis without blocking subsequent events for that user's workout or other users' workouts.
Which solution meets these requirements with the least operational overhead?
- Publish the workout events to an Amazon SQS FIFO queue, using the workout ID as the message group ID. Configure the backend EC2 instances to consume messages from the queue. Set up a dead-letter queue (DLQ) with a redrive policy on the primary SQS FIFO queue to capture failed messages after a maximum receive count of 5.Answer
- BPublish the workout events to a standard Amazon SQS queue. Configure the backend EC2 instances to consume messages from the queue. Set up a dead-letter queue (DLQ) with a redrive policy on the primary standard SQS queue to capture failed messages after a maximum receive count of 5.
- CIngest the workout telemetry events using an Amazon Kinesis Data Stream configured with a single shard to guarantee strict sequential ordering. Use AWS Lambda to process the stream events and write failed records to an Amazon S3 bucket for auditing.
- DDeploy an AWS Lambda function that runs continuously in a loop to poll the database for new telemetry events. Process the events, and write any failures to an Amazon SQS standard dead-letter queue after 5 retries.