What should a solutions architect do to write the orders reliably to the database as quickly as possible?
Increase the instance size of the EC2 instance when traffic is high. Write orders to Amazon Simple Notification Service (Amazon SNS). Subscribe the database endpoint to the SNS topic.
Write orders to an Amazon Simple Queue Service (Amazon SQS) queue. Use EC2 instances in an Auto Scaling group behind an Application Load Balancer to read from the SQS queue and process orders into the database.
Write orders to Amazon Simple Notification Service (Amazon SNS). Subscribe the database endpoint to the SNS topic. Use EC2 instances in an Auto Scaling group behind an Application Load Balancer to read from the SNS topic.
Write orders to an Amazon Simple Queue Service (Amazon SQS) queue when the EC2 instance reaches CPU threshold limits. Use scheduled scaling of EC2 instances in an Auto Scaling group behind an Application Load Balancer to read from the SQS queue and process orders into the database.
Explanations:
Increasing the instance size of the EC2 instance may temporarily improve performance, but it does not provide a reliable way to handle spikes in order processing. Writing to Amazon SNS does not guarantee that orders will be processed in the correct order or at a sufficient rate for high traffic situations. The database cannot directly subscribe to SNS topics for reliable order processing, as SNS is designed for pub/sub messaging and not for direct data writes to databases.
Writing orders to an Amazon SQS queue allows for decoupling of order submission from processing, ensuring that all orders are queued reliably even during high traffic. Using EC2 instances in an Auto Scaling group allows for automatic scaling based on demand, with an Application Load Balancer distributing the workload evenly across instances. This setup provides resilience and ensures orders can be processed as resources become available.
While using Amazon SNS to notify about orders may seem beneficial, SNS is not designed for reliably storing and processing messages as orders in a queue. Subscribing the database endpoint to the SNS topic is not a viable solution since SNS does not support guaranteed delivery and processing in the order required for database transactions. Also, EC2 instances behind an Auto Scaling group would not be able to reliably process messages directly from SNS.
This option suggests writing orders to SQS only when CPU threshold limits are reached, which could lead to lost orders if traffic spikes suddenly before the threshold is hit. Scheduled scaling of EC2 instances is not as responsive as demand-based scaling, potentially delaying processing during high traffic. The reliance on CPU thresholds for queuing orders adds unnecessary complexity and risks to reliable order processing.
It seems to me that the answer is:
Write orders to an Amazon Simple Queue Service (Amazon SQS) queue. Use EC2 instances in an Auto Scaling group behind an Application Load Balancer to read from the SQS queue and process orders into the database.