How should the solutions architect design the solution?
Create a single SQS queue and publish order events to it. The Email, OrderProcessing, and OrderCancellation microservices can then consume messages off the queue.
Create three SNS topics for each microservice. Publish order events to the three topics. Subscribe each of the Email, OrderProcessing, and OrderCancellation microservices to its own topic.
Create an SNS topic and publish order events to it. Create three SQS queues for the Email, OrderProcessing, and OrderCancellation microservices. Subscribe all SQS queues to the SNS topic with message filtering.
Create two SQS queues and publish order events to both queues simultaneously. One queue is for the Email and OrderProcessing microservices. The second queue is for the Email and OrderCancellation microservices.
Explanations:
Using a single SQS queue for all microservices means that both Email and OrderProcessing would receive all messages, which does not allow for simultaneous handling of different events (like cancellation). Additionally, it creates a coupling that goes against the microservices architecture.
Creating three separate SNS topics for each microservice does not allow for simultaneous handling of related events. For instance, when an order is placed, both the Email and OrderProcessing services need to act on the same event, which won’t work with separate topics.
This option allows for a single SNS topic to which order events are published. Each microservice has its own SQS queue, which enables them to process events independently and simultaneously. Message filtering can further refine which events each microservice receives based on the type of event (order submission or cancellation).
This option complicates the architecture by requiring the duplication of the Email microservice’s logic across two SQS queues. It does not effectively utilize SNS and would still create a coupling between services, failing to enable a clean microservices design.