Which design preserves first-order seat priority in serverless app
A developer is designing a serverless application that customers use to select seats for a concert venue. Customers send the ticket requests to an Amazon API Gateway API with an AWS Lambda function that acknowledges the order and generates an order ID. The application includes two additional Lambda functions: one for inventory management and one for payment processing. These two Lambda functions run in parallel and write the order to an Amazon Dynamo DB table. 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?
Community Insight
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.
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.
Community Discussion (7 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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?
Both functions become competing consumers, so each order is delivered to only one of them and the required fan-out never happens. A standard queue also gives no ordering guarantee.
Could option B work by running inventory before payment?
Synchronous Lambda chaining has no durable queue, retries or redrive, so a rejected payment for order #1 has no reliable path to hand the seat to order #2, and it also removes the required parallelism.
Related Analysis
Practice All DVA-C02 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DVA-C02 Practice Test →