Which design preserves first-order seat priority in serverless app
Short answer
A An SNS FIFO topic fanned out to two SQS FIFO queues keeps order IDs in arrival order so the first order wins the seat while inventory and payment run in parallel.
Question
The application must provide seats to customers according to the following requirements. If a seat is accidently sold more than once, the first order that the application received must get the seat. In these cases, the application must process the payment for only the first order. However, if the first order is rejected during payment processing, the second order must get the seat. In these cases, the application must process the payment for the second order.
Which solution will meet these requirements?
Key Takeaways
The question tests FIFO ordering guarantees combined with parallel fan-out; the trap is picking a plain SNS/SQS design that lets both functions run but silently loses the first-order-wins rule.
This DVA-C02 scenario tests ordering and parallel fan-out in a serverless ticketing pipeline built on API Gateway, Lambda and DynamoDB. An SNS FIFO topic delivering to two separate SQS FIFO queues is the only option that preserves first-come ordering for inventory and payment while still letting both Lambda functions run in parallel.
Common mistake: Option D is the tempting wrong pick because configuring both Lambda functions on one SQS queue looks like parallelism, but competing consumers deliver each order to only one function and a standard queue guarantees no ordering. Option C fails for the same ordering reason on the SNS side.
Expert Analysis
Why the Answer Is Correct
An Amazon SNS FIFO topic preserves the exact arrival order of order IDs and fans each message out to two SQS FIFO queues, so inventory management and payment processing still run in parallel as the architecture requires. Because each SQS FIFO queue preserves order, the inventory Lambda evaluates order #1 before order #2, so the first order received claims the seat when a seat is double-sold. Payment is driven from the same ordered stream, so only the order that actually holds the seat is charged, and when order #1's payment is rejected its message completes/retries into the dead-letter path while order #2 proceeds to take the seat and be paid. FIFO queues with message groups plus the standard redrive/dead-letter behaviour give the durability and retry semantics that a direct Lambda-to-Lambda handoff does not.
Why the Other Options Are Wrong
Option B chains the functions with synchronous Lambda invocations, which serialises the flow, removes queue-based buffering and retries, and hard-couples payment to a single success path with no durable mechanism to hand the seat to order #2 when order #1's payment is declined. Option C uses a standard (non-FIFO) SNS topic, so delivery ordering is not guaranteed and neither is exactly-once fan-out, meaning order #2 could be processed ahead of order #1 and steal the seat. Option D places a single queue in front of two consumers, so the two Lambdas become competing consumers — each order is delivered to only one of them, killing the required fan-out, and a standard queue again offers no ordering. None of B, C or D simultaneously satisfies ordering, parallel processing and the payment-failure fallback.
Community Comment Notes
MarkTpTTT55 summarised the consensus with "A. The only viable solution", and nder added that "FIFO is the only option that maintains ordering", which is exactly the deciding requirement here. SerialiDr gave the fullest technical case, noting that the SNS FIFO topic "ensures that messages are delivered in the exact order they are sent" while two FIFO queues keep inventory and payment parallel. BrainFried pushed back that "None of these answers are correct" because nothing stops payment for order #1 if inventory fails, and cerepx argued instead for option B on the grounds that "inventory management must decide the winner before payment processing runs"; both objections are real design gaps, but among the four given choices only A delivers the ordering plus parallel fan-out the scenario demands. Claire_KMT selected D, which overlooks that two functions polling one queue compete for messages rather than both receiving them.
Official Reference
- https://docs.aws.amazon.com/sns/latest/dg/sns-fifo-topics.html
- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/fifo-queues.html
These links open the official vendor documentation in a new tab.
Exam Strategy
When a question demands both strict ordering and parallel processing, immediately filter for FIFO components — a standard SNS topic or standard SQS queue can never enforce first-come-first-served. Then check that the topology fans out (topic → multiple queues) instead of converging (one queue, many consumers), since competing consumers drop messages for some handlers.
Frequently Asked Questions
Why does a single SQS queue with two Lambda functions (option D) fail?
Could option B work by running inventory before payment?
Discussion 7 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 7
-
MarkTpTTT55 👍 10 Answered AA. The only viable solution
-
SerialiDr 👍 5 Answered AHere's why this solution is most appropriate: SNS FIFO Topic: A First-In-First-Out (FIFO) SNS topic ensures that messages are delivered in the exact order they are sent. This is critical for maintaining the order of ticket requests. SQS FIFO Queues: By having two separate FIFO queues for inventory management and payment processing, the application can process these aspects in parallel while still maintaining the order integrity. The FIFO nature of the queues ensures that if a seat is sold more than once, the first order received is processed first. Order Processing Logic: With this setup, if the first order is rejected during payment processing, the second order can be processed next. The sequential processing inherent in FIFO queues ensures that this logic can be correctly implemented.
-
BrainFried 👍 4None of these answers are correct. People say it is A - well then what prevents payment processing for order #1 if the inventory lambda failed to allocate a seat for order #1? The correct answer should be for the order processing lambda to place orders into a queue (e.g. FIFO SQS) and then seat allocation lambda should poll this queue, check if seating is available and if so it should then invoke the payment processing lambda. This option isn't available. The next best option would be Option B. Better than A, since you won't be charged for an order where seating isn't available. If I am wrong, please explain it. Would love to hear. Thanks
-
nder 👍 2 Answered AFIFO is the only option that maintains ordering.
-
cerepx 👍 1 Answered BThe core requirement is a strict sequencing dependency: inventory management must decide the winner before payment processing runs for that order, with fallback to the second order if payment fails for the first.
Show 2 more comments
-
Claire_KMT 👍 1 Answered DD. Deliver the order ID to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the Lambda functions for inventory management and payment processing to poll the queue.
-
65703c1 👍 1 Answered AA is the correct answer.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →