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:
While increasing the instance size of the EC2 instance may help with performance, subscribing the database endpoint to an SNS topic is not a reliable way to write orders to the database. SNS is designed for pub/sub messaging, not direct database writes. This setup could lead to data loss or delays in order processing.
Writing orders to an SQS queue allows for reliable message storage and decouples order submission from processing. Using EC2 instances in an Auto Scaling group to process messages from the SQS queue ensures that the system can scale up during high traffic, allowing for efficient and reliable order processing into the Aurora database.
SNS is not suitable for directly processing orders into the database. While it can handle notifications, it does not provide message durability like SQS. Subscribing the database endpoint to an SNS topic does not ensure reliable writing of orders, as messages could be lost if not properly handled.
While writing to SQS when CPU limits are reached is a good idea, relying on scheduled scaling rather than real-time scaling can lead to delays in processing. Additionally, triggering order processing only when CPU usage is high does not ensure continuous order handling and could lead to bottlenecks.