How to Prevent Duplicate Lambda Payments with SQS FIFO?

SAA-C03 By islever Editorial Last updated

Design scalable and loosely coupled architectures. Design highly available and/or fault-tolerant architectures.

Short answer

C Use an SQS FIFO queue with a Lambda poller so exactly-once processing prevents duplicate payment handling.

Question

A solutions architect is designing a payment processing application that runs on AWS Lambda in private subnets across multiple Availability Zones. The application uses multiple Lambda functions and processes millions of transactions each day. The architecture must ensure that the application does not process duplicate payments. Which solution will meet these requirements?
  1. Use Lambda to retrieve all due payments. Publish the due payments to an Amazon S3 bucket. Configure the S3 bucket with an event notification to invoke another Lambda function to process the due payments.
  2. Use Lambda to retrieve all due payments. Publish the due payments to an Amazon Simple Queue Service (Amazon SQS) queue. Configure another Lambda function to poll the SQS queue and to process the due payments.
  3. Use Lambda to retrieve all due payments. Publish the due payments to an Amazon Simple Queue Service (Amazon SQS) FIFO queue. Configure another Lambda function to poll the FIFO queue and to process the due payments. Correct Answer
  4. Use Lambda to retrieve all due payments. Store the due payments in an Amazon DynamoDB table. Configure streams on the DynamoDB table to invoke another Lambda function to process the due payments.

Key Takeaways

The question tests exactly-once processing versus at-least-once delivery, and the trap is choosing DynamoDB Streams or standard SQS even though Lambda consumers can redeliver messages.

A payment processing application on AWS Lambda must avoid duplicate payments across multiple Availability Zones; Amazon SQS FIFO queues provide exactly-once processing and deduplication, making option C the correct solution.

Common mistake: Many learners pick D because DynamoDB Streams writes each record once, but Lambda stream processing is at-least-once and can retry, so duplicate payments are still possible without idempotency.

Expert Analysis

Why the Answer Is Correct

Amazon SQS FIFO queues are designed to provide exactly-once processing and deduplication: a message is delivered once and remains invisible until the consumer deletes it, and duplicates are not introduced within the 5-minute deduplication interval. That directly satisfies the requirement that the payment application must not process duplicate payments. Commenters such as hajra313 summarized this by quoting "FIFO queues provide exactly-once processing" while standard queues are only at-least-once. Lambda's SQS event source mapping can poll the FIFO queue, and high-throughput FIFO mode supports enough throughput for millions of transactions per day across partitions. The queue is also regional and durable across Availability Zones, matching the multi-AZ Lambda design.

Why the Other Options Are Wrong

Option A uses Amazon S3 event notifications, which are at-least-once and can invoke the downstream Lambda more than once for the same object or retry a failed invocation, so duplicate payments remain possible. Option B uses a standard SQS queue, which also offers at-least-once delivery and can therefore deliver the same due-payment message multiple times. Option D is the tempting distractor: DynamoDB Streams guarantees each stream record appears once in the stream, but Lambda's stream processing is at-least-once and can retry a batch, as escalibran noted, "Processing dynamo streams with lambda can cause duplication." Cali182 argued for D based on stream record uniqueness, but uniqueness in the stream does not guarantee exactly-once payment processing, and you would need idempotency or conditional writes to make D safe.

Community Comment Notes

Scheldon pointed to AWS documentation that FIFO queues do not introduce duplicates when SendMessage is retried inside the deduplication interval, and recommended option C. escalibran also raised the practical point that FIFO high-throughput mode can exceed the older 3,000 messages-per-second batched limit, addressing scalability for millions of daily transactions. One commenter said the phrase "does not process duplicate payments" is the key point that leads directly to SQS FIFO, and several others simply marked option C. Cali182's dissent for DynamoDB Streams reflects the common confusion that stream-record uniqueness equals consumer-level exactly-once processing.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Look for exactly-once processing cues such as “does not process duplicate,” “deduplication,” or “ordering” and map them to SQS FIFO. Differentiate FIFO from at-least-once services like standard SQS, S3 event notifications, and Lambda stream polling; DynamoDB Streams record uniqueness does not prevent Lambda re-delivery.

Frequently Asked Questions

Why is DynamoDB Streams not sufficient to prevent duplicate payments?

Each stream record appears once, but Lambda stream consumers are at-least-once and can retry a batch, so the same payment could be reprocessed without an idempotency check.

Can an SQS FIFO queue handle millions of payments per day for Lambda?

Yes. Millions per day is low average throughput; FIFO high-throughput mode supports up to 3,000 messages per second per partition with batching, and Lambda scales by message group.

More SAA-C03 FAQ →

Community Votes

C
82%
D
18%

82% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 11 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 11

  1. hajra313 👍 17
    Standard queues provide at-least-once delivery, which means that each message is delivered at least once. FIFO queues provide exactly-once processing , which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue. OPTION C
  2. escalibran 👍 3 Answered C
    C over D, because https://docs.aws.amazon.com/lambda/latest/dg/with-ddb.html Processing dynamo streams with lambda can cause duplication. SQS FIFO can be configured for High Throughput to exceed the 3000/s (batched) limit https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/high-throughput-fifo.html I previously worked with payments and would argue that either option doesn't fully solve duplications. Events might be sent multiple times from source, you definitely want to perform de-duplication and have some sort of idempotent processing for them, instead of just blindly processing each thing you're given.
  3. Scheldon 👍 3 Answered C
    AnswerC SQS FIFO was created for such tasks Unlike standard queues, FIFO queues don't introduce duplicate messages. FIFO queues help you avoid sending duplicates to a queue. If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues-exactly-once-processing.html
  4. Cali182 👍 3 Answered D
    Option D DynamoDB Streams helps ensure the following: Each stream record appears exactly once in the stream. For each item that is modified in a DynamoDB table, the stream records appear in the same sequence as the actual modifications to the item. DynamoDB Streams writes stream records in near-real time so that you can build applications that consume these streams and take action based on the contents.
  5. haci 👍 3 Answered C
    "The application does not process duplicate payments" is the key point, which leads us directly to SQS FIFO
Show 6 more comments
  1. shahreh1 👍 2
    Option C: FIFO queues Exactly-Once Processing – A message is delivered once and remains available until a consumer processes and deletes it. Duplicates aren't introduced into the queue. First-In-First-Out Delivery – The order in which messages are sent and received is strictly preserved.
  2. Mikado211 👍 2
    SQS can have duplicate messages in case of problems with the timeout window.
  3. FZA24 👍 3 Answered C
    Option C Fifo
  4. asdfcdsxdfc 👍 2 Answered C
    c is correct
  5. kempes 👍 2
    Option c
  6. Andy_09 👍 1
    Option B

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Most Cost-Effective 7-Year Retention for EBS Snapshots?

S-grade

AWS Forecast vs SageMaker for Time-Series Prediction

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide