Question

Difficulty: MediumDecoupling Architectures and Event-Driven Messaging

A digital ticketing platform is designing a system to process flash sale ticket purchases. The application must handle sudden surges in transaction volume and process purchase requests asynchronously. To prevent double-booking, the requests for each specific event must be processed in the exact order they were submitted. If a transaction fails to process due to downstream database timeouts, it must be isolated for manual inspection without halting the processing of other purchases.

Which solution meets these requirements with the least operational overhead?

  1. A
    Send the purchase requests to an Amazon Simple Queue Service (Amazon SQS) Standard queue. Configure the consumer application to sort the transactions chronologically. Set up another SQS Standard queue as a dead-letter queue to capture failed messages.
  2. B
    Publish the purchase requests to an Amazon Simple Notification Service (Amazon SNS) Standard topic. Subscribe multiple Amazon SQS FIFO queues to the topic to buffer and process the messages, and configure a redrive policy on the queues to route failed messages to a dead-letter queue.
  3. Send the purchase requests to an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Configure the event ID as the message group ID. Set up another SQS FIFO queue as a dead-letter queue to capture failed messages after a specified number of retries.Answer
  4. D
    Stream the purchase requests to an Amazon Kinesis Data Stream. Configure a single shard to guarantee ordering, and use AWS Lambda to process the records. Configure an AWS Lambda destination to send failed records to an Amazon Simple Storage Service (Amazon S3) bucket.

Answer

Send the purchase requests to an Amazon Simple Queue Service (Amazon SQS) FIFO queue, configure the event ID as the message group ID, and set up an Amazon SQS FIFO queue as a dead-letter queue (DLQ).
The correct solution uses an Amazon SQS FIFO queue. Specifying the event ID as the message group ID ensures that purchases for a specific ticket event are processed sequentially, avoiding concurrent modifications or out-of-order processing that could cause double-booking. Configuring an SQS FIFO dead-letter queue (DLQ) allows failed messages to be redirected after a set number of attempts, preventing head-of-line blocking for other events and allowing administrators to inspect the failure without halting the system.

Step-by-Step Solution

1
Select the messaging service that supports FIFO ordering.
Amazon SQS FIFO queue is chosen to ensure messages within the same message group (defined by the event ID) are processed in the exact order they are received.
Standard SQS queues and Standard SNS topics do not guarantee message ordering.
2
Configure the message grouping strategy.
Set the event ID as the Message Group ID.
This ensures that transactions for the same event are processed sequentially by a single consumer, preventing double-booking, while transactions for different events can be processed in parallel.
3
Establish a mechanism to handle message processing failures without blocking the queue.
Create a secondary SQS FIFO queue as a dead-letter queue (DLQ) and configure a redrive policy on the main SQS FIFO queue.
If a transaction repeatedly fails, the redrive policy routes the message to the DLQ after a max receive count is reached. This unblocks the queue for subsequent messages in the same group, allowing manual analysis of the failed transaction.

Key Concept

Decoupling message processing using SQS FIFO queues with Message Group IDs and SQS FIFO dead-letter queues to maintain ordering and handle errors.
Rate this question