
Ultimate access to all questions.
Deep dive into the quiz with AI chat providers.
We prepare a focused prompt with your quiz and certificate details so each AI can offer a more tailored, in-depth explanation.
A company has a legacy data processing application that runs on Amazon EC2 instances. Data is processed sequentially, but the order of results does not matter. The application uses a monolithic architecture. The only way that the company can scale the application to meet increased demand is to increase the size of the instances.
The company's developers have decided to rewrite the application to use a microservices architecture on Amazon Elastic Container Service (Amazon ECS).
What should a solutions architect recommend for communication between the microservices?
A
Create an Amazon Simple Queue Service (Amazon SQS) queue. Add code to the data producers, and send data to the queue. Add code to the data consumers to process data from the queue.
B
Create an Amazon Simple Notification Service (Amazon SNS) topic. Add code to the data producers, and publish notifications to the topic. Add code to the data consumers to subscribe to the topic.
C
Create an AWS Lambda function to pass messages. Add code to the data producers to call the Lambda function with a data object. Add code to the data consumers to receive a data object that is passed from the Lambda function.
D
Create an Amazon DynamoDB table. Enable DynamoDB Streams. Add code to the data producers to insert data into the table. Add code to the data consumers to use the DynamoDB Streams API to detect new table entries and retrieve the data.
Explanation:
Correct Answer: A (Amazon SQS)
Why SQS is the best choice:
Decoupled Communication: SQS provides a fully managed message queuing service that enables decoupled communication between microservices. This is ideal for microservices architecture where services should not be tightly coupled.
Asynchronous Processing: The scenario states that "data is processed sequentially, but the order of results does not matter." SQS supports asynchronous processing where producers can send messages to the queue and consumers can process them independently.
Scalability: SQS automatically scales to handle any volume of messages, which aligns with the company's need to scale the application to meet increased demand.
Reliability: SQS ensures message delivery and provides at-least-once delivery semantics, making it reliable for data processing applications.
Load Leveling: SQS helps in load leveling by buffering requests between producers and consumers, preventing consumers from being overwhelmed during traffic spikes.
Why other options are not optimal:
Option B (SNS): SNS is a pub/sub messaging service that broadcasts messages to multiple subscribers. While it could work, it's better for fan-out scenarios where the same message needs to be processed by multiple consumers. The question doesn't indicate multiple consumers need the same data.
Option C (Lambda): Using Lambda as a message broker adds unnecessary complexity. Lambda is better for event-driven computing, not as a message passing service between microservices. This would create tight coupling and potential bottlenecks.
Option D (DynamoDB with Streams): While DynamoDB Streams can be used for event-driven architectures, it's not the primary tool for microservices communication. This approach adds database overhead and complexity compared to a dedicated messaging service like SQS.
Key AWS Concepts:
This solution provides a robust, scalable, and decoupled communication mechanism that aligns with microservices best practices on AWS.