Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in managing parallel Lambda executions that update shared state without data races or double processing. In production, this is about knowing exactly how to orchestrate event-driven functions to guarantee ordering and conditional branching based on payment success. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
ZenStage is building an automated ticket booking system for their live-event streaming platform. Customers select virtual seats for an online concert via a REST API exposed through Amazon API Gateway. When a customer submits a reservation request, an AWS Lambda function generates a booking confirmation ID.
The workflow then triggers two additional Lambda functions in parallel: one handles seat inventory confirmation and the other processes the payment. Both functions write booking details to a shared Amazon DynamoDB table.
The critical booking rules are:
- If a seat is accidentally booked more than once, the first booking request must have priority and receive the seat.
- Payment is processed only for the booking that secures the seat.
- If the payment for the first booking fails, the seat should be reassigned to the next in line, and payment processed for that booking instead.
Which solution satisfies these requirements?
The Options #
- A) Publish the booking ID to an Amazon SNS FIFO topic that fans out to two Amazon SQS FIFO queues—one queue for seat inventory management and one queue for payment processing.
- B) Modify the booking Lambda to invoke the inventory management Lambda directly, and only after it completes, invoke the payment processing Lambda.
- C) Publish the booking ID to a standard Amazon SNS topic that triggers both the inventory management and payment processing Lambda functions as subscribers.
- D) Send the booking ID to an Amazon SQS standard queue that both the inventory and payment Lambda functions poll for messages.
Google adsense #
leave a comment:
Correct Answer #
A
Quick Insight: The Developer Imperative #
- For Developers: This hinges on understanding the difference between SNS vs. SQS, and especially FIFO capabilities—message ordering, deduplication, and exactly-once processing.
- When two Lambdas must process order-dependent operations in parallel, using SNS FIFO with multiple SQS FIFO queue subscribers ensures strict event ordering and deduplication, preventing double payment charging and race conditions.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option A
The Winning Logic #
Using an Amazon SNS FIFO topic combined with two SQS FIFO queues is the key to meeting all of ZenStage’s technical requirements. Here’s why:
- Message ordering: The FIFO SNS topic preserves ordering of booking IDs as they arrive, ensuring the first booking request is handled first downstream.
- Fan-out to isolated queues: Separating inventory management and payment processing into individual SQS FIFO queues lets the two Lambdas consume messages independently but in the same order.
- Deduplication and exactly-once semantics: FIFO SNS + SQS combos help prevent double-processing or race conditions. Only one Lambda processes a given booking ID at a time.
- Conditional payment logic: Because the order of booking IDs is preserved, the inventory function can determine if a seat is already assigned and the payment function only processes payment for the valid booking.
- Parallelism with control: Lambdas run concurrently but synchronized by queue order, meeting the requirement that payment occurs only after inventory validation.
The Trap (Distractor Analysis): #
- Why not B? This overly serializes the workflow and can introduce additional latency. Direct Lambda invocation is also harder to scale and coordinate rollback if payment fails.
- Why not C? A standard SNS topic does not guarantee ordering or exactly-once delivery. This can result in double payments or out-of-order handling.
- Why not D? A standard SQS queue polled by both Lambdas loses ordering and can cause both Lambdas to process the same message simultaneously, violating the seat assignment rules.
The Technical Blueprint #
Code Snippet: Creating SNS FIFO + SQS FIFO queues and subscriptions (AWS CLI) #
# Create SNS FIFO topic
aws sns create-topic --name BookingTopic.fifo --attributes FifoTopic=true,ContentBasedDeduplication=true
# Create two SQS FIFO queues
aws sqs create-queue --queue-name InventoryQueue.fifo --attributes FifoQueue=true,ContentBasedDeduplication=true
aws sqs create-queue --queue-name PaymentQueue.fifo --attributes FifoQueue=true,ContentBasedDeduplication=true
# Get ARNs and URLs (pseudocode)
SNS_ARN="arn:aws:sns:region:account-id:BookingTopic.fifo"
INVENTORY_QUEUE_ARN="arn:aws:sqs:region:account-id:InventoryQueue.fifo"
PAYMENT_QUEUE_ARN="arn:aws:sqs:region:account-id:PaymentQueue.fifo"
# Subscribe SQS queues to SNS FIFO topic
aws sns subscribe --topic-arn $SNS_ARN --protocol sqs --notification-endpoint $INVENTORY_QUEUE_ARN
aws sns subscribe --topic-arn $SNS_ARN --protocol sqs --notification-endpoint $PAYMENT_QUEUE_ARN
# Configure IAM policies to allow SNS to send messages to SQS
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Moderate (SNS FIFO + SQS FIFO integration) | High (ordered parallelism with deduplication) | Ideal for ordered parallel Lambda workflows needing message sequencing and conditional branching |
| B | Low (Direct synchronous invocations) | Moderate to low (serial, blocking) | Simple sequential orchestration, not scalable or fault tolerant for payment fallback |
| C | Low (standard SNS topic) | Low (no delivery order guarantees) | Event fan-out with loose coupling, but no ordering controls; risky for payment logic |
| D | Low (standard SQS) | Medium (unordered messages possible) | Simple queue workflow but unordered processing leads to race conditions |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick SNS FIFO + SQS FIFO pattern when you see parallel Lambda workflows requiring strict ordering and exactly-once processing.
Real World #
In production, you might also add DynamoDB conditional writes or use Step Functions for complex error handling and retries, but those add latency and cost. SNS FIFO + SQS FIFO is a great serverless orchestration pattern to maintain concurrency controls and ensure payment correctness with minimal overhead.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.