What should the solutions architect do to meet these requirements?
Push score updates to Amazon Kinesis Data Streams. Process the updates in Kinesis Data Streams with AWS Lambda. Store the processed updates in Amazon DynamoDB.
Push score updates to Amazon Kinesis Data Streams. Process the updates with a fleet of Amazon EC2 instances set up for Auto Scaling. Store the processed updates in Amazon Redshift.
Push score updates to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe an AWS Lambda function to the SNS topic to process the updates. Store the processed updates in a SQL database running on Amazon EC2.
Push score updates to an Amazon Simple Queue Service (Amazon SQS) queue. Use a fleet of Amazon EC2 instances with Auto Scaling to process the updates in the SQS queue. Store the processed updates in an Amazon RDS Multi-AZ DB instance.
Explanations:
Amazon Kinesis Data Streams is designed to handle large traffic spikes with high throughput and ordering guarantees. AWS Lambda integrates well with Kinesis for processing updates in real-time without managing infrastructure. DynamoDB is highly available and scalable for storing processed updates, and it requires minimal management overhead.
Although Kinesis Data Streams and Auto Scaling EC2 instances can process updates, using EC2 instances requires significant management overhead for scaling and maintenance. Additionally, Redshift is a data warehouse, not a transactional database, and is not suitable for low-latency, real-time updates like leaderboard scores.
SNS is useful for pub/sub messaging but lacks the built-in processing or state management capabilities needed for ordered processing of updates. Using Lambda with SNS does not guarantee the order of updates. Additionally, a SQL database on EC2 would require extensive management overhead, which contradicts the goal of minimizing maintenance.
Using SQS with EC2 instances requires manual management of scaling and EC2 infrastructure. Although SQS can queue the messages, processing updates with EC2 and storing them in RDS requires manual setup and scaling, which adds unnecessary complexity compared to the fully managed solution in Option A.