High-End Auctioning Site Application

Correct Answers: D and E.

Option A is INCORRECT because in the Standard queue the order is not preserved.

Option B is INCORRECT because SNS is mainly used to fan out the messages to multiple consumers.

It delivers the same message to multiple consumers and does not guarantee unique message delivery.

Option C is INCORRECT because SNS does not have a FIFO queue.

After all, it is a notification service (not a queueing service).

Option D is CORRECT because AWS Lambda can be configured to process the messages from the SQS FIFO queue.

Lambda is serverless and cost-efficient.

See more info here: https://aws.amazon.com/blogs/compute/new-for-aws-lambda-sqs-fifo-as-an-event-source/

Option E is CORRECT because, for an SQS FIFO queue, all the messages with the same Message Group Identifier will be delivered in order.

Messages with different message group ID values might be sent and received out of order.

The scenario described involves an auctioning site built using NodeJS and MongoDB. Redis is being used for caching current auctioning data, while pub/sub is used to distribute auction-related events such as bidding count and price fluctuations. The question asks about the best option for managing message queues.

A. Use the Simple Queue Service (SQS) standard queue. The standard queue of the Simple Queue Service (SQS) provides a reliable, highly scalable message queuing service that enables decoupling and scaling of microservices, distributed systems, and serverless applications. However, it does not guarantee the order in which messages are received, which may not be appropriate for an auctioning site where the order of messages is critical.

B. Use the Simple Notification Service (SNS), which is similar to the Redis pub/sub, but automatically supports unlimited messages and scales. The Simple Notification Service (SNS) is a fully managed pub/sub messaging service that enables the distribution of messages to multiple recipients, such as email, SMS, and HTTP endpoints. SNS is a suitable option for an auctioning site because it is similar to Redis pub/sub but scales automatically and supports an unlimited number of messages.

C. Create and use the Simple Notification Service (SNS) FIFO queue. The Simple Notification Service (SNS) FIFO queue guarantees the order in which messages are sent and received. However, SNS FIFO queues do not support deduplication of messages, which can cause problems in some scenarios.

D. Use the Simple Queue Service (SQS) FIFO queue and migrate the bid processing module to the Lambda. The Simple Queue Service (SQS) FIFO queue is similar to the standard queue, but it guarantees that messages are received in the order they were sent. This option is appropriate for an auctioning site because the order of messages is critical. The use of AWS Lambda for processing bids can help reduce the load on the application servers.

E. Configure a message group identifier to represent a distinct ordered message group within the FIFO queue. The Simple Queue Service (SQS) FIFO queue supports the use of a message group identifier to represent a distinct ordered message group within the queue. This feature can be used to group related messages together, which can help ensure that messages are processed in the correct order.

In conclusion, the best option for managing message queues for an auctioning site built using NodeJS and MongoDB is option D: Use the Simple Queue Service (SQS) FIFO queue and migrate the bid processing module to the Lambda. This option guarantees the order of messages while reducing the load on application servers by processing bids using AWS Lambda.