How to Increase Elasticity for Spiky POS Transaction Writes

DVA-C02 By islever Editorial Last updated

Optimize applications by using AWS services and features. Develop code for AWS Lambda. Use data stores in application development.

Short answer

D Buffer transactions through an Amazon SQS queue that triggers Lambda and set the Lambda reserved concurrency below the RDS connection limit.

Question

A company has point-of-sale devices across thousands of retail shops that synchronize sales transactions with a centralized system. The system includes an
Amazon API Gateway API that exposes an AWS Lambda function. The Lambda function processes the transactions and stores the transactions in Amazon RDS
for MySQL. The number of transactions increases rapidly during the day and is near zero at night.
How can a developer increase the elasticity of the system MOST cost-effectively?
  1. Migrate from Amazon RDS to Amazon Aurora MySQL. Use an Aurora Auto Scaling policy to scale road replicas based on CPU consumption.
  2. Migrate from Amazon RDS to Amazon Aurora MySQL. Use an Aurora Auto Scaling policy to scale read replicas based on the number of database connections.
  3. Create an Amazon Simple Queue Service (Amazon SQS) queue. Publish transactions to the queue. Set the queue to invoke the Lambda function. Turn on enhanced fanout for the Lambda function.
  4. Create an Amazon Simple Queue Service (Amazon SQS) queue. Publish transactions to the queue. Set the queue to invoke the Lambda function. Set the reserved concurrency of the Lambda function to be less than the number of database connections. Correct Answer

Key Takeaways

The real bottleneck is concurrent writes to RDS, so the trap is picking read-replica auto scaling or the nonexistent SQS 'enhanced fanout' instead of a queue plus a concurrency ceiling on Lambda.

This DVA-C02 question tests how to make a write-heavy, bursty API Gateway–Lambda–RDS pipeline elastic on a budget. It establishes that buffering transactions through an Amazon SQS queue and capping Lambda reserved concurrency below the database connection limit (option D) is the only solution that actually relieves the write bottleneck.

Common mistake: Option C is the most frequent wrong pick: it repeats the valid SQS-to-Lambda decoupling but adds 'enhanced fanout,' a Kinesis Data Streams feature that does not exist for SQS or Lambda, making the whole option invalid. Options A and B are also popular yet useless because read replicas cannot absorb writes.

Expert Analysis

Why the Answer Is Correct

Option D is the only choice that addresses the actual bottleneck, which is writes: the Lambda function "stores the transactions in Amazon RDS for MySQL," and every concurrent invocation can hold one or more connections against a fixed max_connections limit. Placing an Amazon SQS queue between the API and the function decouples the front end from processing, so the API responds instantly, transactions are buffered durably, and Lambda drains the queue at whatever rate the database can absorb. Setting reserved concurrency below the connection ceiling bounds the number of simultaneous writers, guaranteeing that connections are never exhausted while the queue soaks up the mid-day burst and drains to near zero overnight. Because idle capacity is not provisioned and nothing is dropped, this is the most cost-effective elasticity pattern for the described workload.

Why the Other Options Are Wrong

Options A and B both scale Aurora read replicas, but read replicas serve read traffic only; this workload is write-bound, so replicas add no write capacity and no elasticity to the spike. The chosen scaling trigger (CPU or connection count) is irrelevant when writes go to the primary instance, and migrating to Aurora increases cost without solving the problem. Option C is half right — an SQS queue that invokes Lambda is exactly the right decoupling — but "enhanced fanout" is an Amazon Kinesis Data Streams feature that provisions a dedicated 2 MB/s read slice per consumer; it does not exist for SQS or Lambda, so the option cannot be implemented as written. Only D is fully executable and directly targets the database connection ceiling.

Community Comment Notes

Most commenters land on D; Kirkster observes that "Neither A nor B will be of any use at all, because they say to scale out read replicas" and that "enhanced fanout is only for Kinesis-Lambda integration, not for SQS." JAMG54 and rcaliandro reach the same conclusion independently, with rcaliandro noting the question says it "stores the transactions in Amazon RDS" and therefore B's read replicas do not apply. Dissenting voices back C or B: Syre argues D creates a bottleneck, but throttling writers to protect the connection pool is the intended design — excess transactions wait safely in the queue instead of crashing the database. PVR cites the Aurora Auto Scaling documentation for B, yet that feature governs read capacity only, and sebasbonilla's claim that "Enhanced Fan-Out" applies to SQS is factually incorrect.

Official Reference

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

Exam Strategy

On DVA-C02 optimization questions, first identify the bottleneck direction — reads versus writes — because Aurora read-replica auto scaling is a distractor that only relieves reads. Then check each option for feasibility: any feature named for a different service (such as Kinesis enhanced fanout applied to SQS) invalidates the option immediately.

Frequently Asked Questions

Why don't Aurora read replicas fix this write-heavy POS workload?

Read replicas only serve read traffic; the transactions here are written to the MySQL primary. Adding or auto scaling replicas cannot relieve write load or connection pressure on the primary instance.

Is enhanced fanout a feature of Amazon SQS or Lambda?

No. Enhanced fanout is an Amazon Kinesis Data Streams feature giving each consumer a dedicated read throughput slice. SQS and Lambda have no such option, which invalidates option C.

More DVA-C02 FAQ →

Discussion 51 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 30 of 51

  1. JAMG54 👍 25
    A and B are for read problem, nor for write. C its not possible because enhanced fanout its for kinesis D is the most probably
  2. SuperPiski 👍 7 Answered D
    Read replicas are for read... transactions means that something have to be written. There is no such thing of fanout for lambda. This lead to D. Because we've limited the number of concurrent lambdas to be lower than the number of connections, the system will run with no problems
  3. rcaliandro 👍 6 Answered D
    Again, tricky question! I was for B but if we think about that, it is written "stores the transactions in Amazon RDS" and the B option is only about read replicas. So I changed my mind and now I will go for D as well. It makes sense to create a Queue before process the transactions and publish messages to the SQS Queue and attach a lambda function to perform the transaction. Also, set the reserved concurrency (max number of parallel invocations for a function) less than to the number of DB connections is a brilliant idea to avoid concurrency issues with the function.
  4. adsdadasdad 👍 4
    How can a developer increase the elasticity of the system MOST cost-effectively? sqs is a good choice but it states that the transactions are minimal at night and high through the day. This i believe points to aurora because it scales and uses the word elasticity. in this case sqs is defined not to scale in any matter and only solves the problem of parralel connections.Now the question is would you scale based on cpu or the amount of concurrent lambda requests. Like we saw it states that the number of transactions and not anything to do with CPU or READS but does impact the cpu but is not mentioned. i think this part confuses people and leads people to think to use sqs because it will solve the parralel problem of many requests. I do think its B. Here is a full explenation of SuperPiski question around writing to scaled instances.https://aws.amazon.com/blogs/database/planning-i-o-in-amazon-aurora/
  5. Kirkster 👍 4 Answered D
    Correct answer is D. Neither A nor B will be of any use at all, because they say to scale out read replicas, but this application needs to WRITE to the database. So we want to decouple writes, and the easiest way to do that is with a queue. So we want SQS. But "enhanced fanout" is only for Kinesis-Lambda integration, not for SQS. Therefore answer D is best, and it also ensures we don't saturate database connections by configuring reserved concurrency - this protects against data loss by preventing an overload of the database during peak POS system usage.
Show 25 more comments
  1. venimus_vidimus_vicimus 👍 4 Answered D
    never heard about fanout lambda
  2. sebasbonilla 👍 3
    The most cost-effective way to increase the elasticity of the system would be to create an Amazon Simple Queue Service (Amazon SQS) queue and publish transactions to the queue, then set the queue to invoke the Lambda function. Option C is the correct answer. This approach would decouple the transactions from the Lambda function and the RDS database, allowing for better scalability and fault tolerance. Turning on enhanced fanout for the Lambda function would also allow for faster processing of the transactions. Migrating to Amazon Aurora MySQL with read replicas (options A and B) would provide better performance, but it may not be the most cost-effective solution. Option D is incorrect because setting the reserved concurrency of the Lambda function to be less than the number of database connections would limit the processing capacity of the function and may cause a bottleneck
  3. Syre 👍 3 Answered C
    D is very incorrect, D would limit the number of concurrent executions of the Lambda function, potentially creating a bottleneck and reducing the throughput of the system. A and B are wrong as they are for reads. C is the answer The AWS Lambda feature called "Enhanced Fan-Out" exist, that enables multiple Lambda functions to receive and process events from an Amazon Simple Notification Service (SNS) or Amazon Kinesis Data Streams (KDS) stream in parallel. This feature is designed to increase the parallelism and throughput of the event processing pipeline, and it can be used to support high-throughput, real-time data processing use cases.
  4. PVR 👍 3
    The answer is B. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html
  5. gaddour_med 👍 2
    A and B are for read to eliminate C: there is fan-out option for lambda but is not posible here because lambda parallel workers may excute tasks more then databse connections (without replicas and autoscaling). D : lambda conccurrency less then database connection so fo each executes messag from SQS wil get database connetion available to handle transaction
  6. vipyodha 👍 2
    option D is better fit than C: in option c the reserved concurrency of lambda is set lower than database connection, that means database write operation will not throttle , while at lambda there is sqs behind lambda so for huge number of request sqs will hundle and will not throttle.
  7. imvb88 👍 2 Answered D
    transactions -> need write function. A, B only for read function -> out C: enhanced fan-out is feature of Kinesis. Lambda does support it but only with Kinesis, not with SQS -> out D make sense since SQS + Lambda is a pattern, plus setting reserved concurrency limit makes sense
  8. SBoksh 👍 2 Answered D
    lambda reserved concurrency less than DB conn so when the db connection increases, lamda can scale up to reserved concurrency to provide a consistent rate WCU to RDS https://docs.aws.amazon.com/lambda/latest/operatorguide/reserved-concurrency.html
  9. Syre 👍 2
    D is very incorrect, D would limit the number of concurrent executions of the Lambda function, potentially creating a bottleneck and reducing the throughput of the system. A and B are wrong as they are for reads. C is the answer
  10. CarlosC 👍 2
    It can't be C. Enhanced fan-out is a feature of Amazon Kinesis Data Streams, not SQS. Enhanced fan-out allows multiple consumers to receive data from a Kinesis data stream concurrently. D is the most probable
  11. tieyua 👍 2
    scale from zero at night to thousands of busy shops during the day, is the exactly selling point of Aurora. I vote by the marketing sales pitch.
  12. SuperPiski 👍 2
    Transactions cannot be done with read replicas, should be done in the write instance.
  13. JAMG54 👍 2
    https://docs.aws.amazon.com/lambda/latest/dg/services-rds.html
  14. Chhotu_DBA 👍 2 Answered C
    I think its C
  15. MrTee 👍 1 Answered C
    This approach uses an Amazon SQS queue to decouple the point-of-sale devices from the centralized system, allowing for better scalability and reliability. The queue can handle large volumes of transactions during peak periods and ensure that the transactions are processed in a timely manner by invoking the Lambda function. Using enhanced fanout for the Lambda function can further increase its elasticity by allowing multiple instances to process messages concurrently. This is the most cost-effective approach as it doesn't require any changes to the existing RDS database or the use of expensive Aurora Auto Scaling.
  16. may2021_r 👍 1
    Option D is the correct answer because creating an Amazon SQS queue and publishing transactions to the queue before storing them in Amazon RDS for MySQL can help to buffer the traffic and prevent sudden traffic spikes. Setting the queue to invoke the Lambda function can help to decouple the Lambda function from the point-of-sale devices, allowing for better scaling. Setting the reserved concurrency of the Lambda function to be less than the number of database connections can also help to prevent overloading the database tier.
  17. Kirkster 👍 1
    The answer cannot be C, as there is no "enhanced fan-out" for SQS to Lambda, that's only for Kinesis. And if it ever did exist, it would be the opposite of what you want - the fanout would mean even more Lambda functions would execute simultaneously, which would overwhelm the database's limited connection pool. The correct answer is D, because it spread outs the database write transactions over time, and protects the database from timing out on new connections due to running out.
  18. Kirkster 👍 1 Answered D
    The sales transactions are writes, not reads, so scaling out read replicas wouldn't help, which rules out A and B. There is no "enhanced fan-out" for SQL and Lambda, and that would actually make the problem worse if it even existed, as your database would be swamped. Spreading out the database write transactions over time by limiting Lambda concurrency is best of the options, it would work to protect the database from being overwhelmed, and is a cheap (cost effective) solution.
  19. Kirkster 👍 1
    It can't be B, because B (as well as A) only increase the number of read replicas, but the lambda function needs to write records to the database. So neither A nor B will help at all, because we need to write, not read. Therefore, the answer is D, because it uses SQS to decouple, and because reserved concurrency protects against data loss due to too many simultaneous database connections. (source: I'm a principal Solutions Architect at AWS)
  20. cdm2009 👍 1
    Enhanced Fan-Out applies to SNS and KDS - but we are using neither here. The reason such an option does not exist for SQS, is because that is how SQS operates natively. Because of this, we must limit the concurrency of the Lambda function to be less than the maximum connection limit of the database. If we do not create this "bottleneck" (which the SQS queue exists to level out over time) then we will instead encounter connection errors.
  21. Kirkster 👍 1
    Reserved concurrency means that you don't allow more Lambda function executions at the same time than your database can handle (max concurrent connections). This way, you decouple the database writes from the load (from the POS system's call to the API). So yes, it's D, and the reserved concurrency ensures you don't get database connection timeouts that would result in data loss.
  22. sumanshu 👍 1 Answered D
    D) Correct - By adding an SQS queue between the point-of-sale devices and the Lambda function, you can handle spikes in transaction volume without overwhelming the Lambda function or the RDS database. Limiting the concurrency of the Lambda function ensures that the number of simultaneous connections to the database does not exceed what the RDS instance can handle.
  23. trainee46 👍 1 Answered D
    A&B are out because the aplpication writes to the DB, therefore read replicas do not help. C ist out because enahced fan out is a kinesis feature D solves the issue. Setting the concurrency limit to the number of database connections ensures that all running lambdas can successfuly write to the database.
  24. gpit 👍 1 Answered A
    If fix the typo "road replica" to "read replica", "A" definitely is the answer as exemplified by https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html#Aurora.Integrating.AutoScaling.BYB More connectivity doesn't mean the DB is busy.
  25. gilleep_17 👍 1
    option c Using an Amazon SQS queue to buffer transactions and then invoking the Lambda function can help in managing the varying transaction load. Turning on enhanced fanout for the Lambda function allows it to scale more effectively by processing records in parallel.

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.

How to Log Every Lambda Invocation to an SQS Queue?

S-grade

How to Test Updated Lambda Functions with a Subset of Users Using API Gateway?

S-grade

How to automate S3 object tagging after delayed third-party content audit?

S-grade

How to automatically rotate encryption keys for API keys in serverless apps with no development effort?

S-grade

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide