Learn how to deal with the ProvisionedThroughputExceededException error when using the PutRecords API call in Amazon Kinesis. Discover two techniques that can help mitigate this exception and improve the performance of your application.
Table of Contents
Question
An application is processing clickstream data using Amazon Kinesis. The clickstream data feed into Kinesis experiences periodic spikes. The PutRecords API call occasionally fails and the logs show that the failed call returns the response shown below:
Which techniques will help mitigate this exception? (Choose two.)
A. Implement retries with exponential backoff.
B. Use a PutRecord API instead of PutRecords.
C. Reduce the frequency and/or size of the requests.
D. Use Amazon SNS instead of Kinesis.
E. Reduce the number of KCL consumers.
Answer
A. Implement retries with exponential backoff.
C. Reduce the frequency and/or size of the requests.
Explanation
The correct answer is A and C. Implement retries with exponential backoff and reduce the frequency and/or size of the requests.
This solution will help mitigate the exception because it will reduce the likelihood of exceeding the throughput limit of the Kinesis stream. The exception shown in the question is a ProvisionedThroughputExceededException, which indicates that the rate of incoming requests exceeds the throughput limit of the stream. This can happen when there are periodic spikes in the clickstream data or when the stream is not provisioned with enough shards to handle the data volume.
To handle this exception, the developer can implement retries with exponential backoff, which means that the application will wait for a progressively longer time before retrying a failed request. This will give the stream time to process the existing requests and avoid throttling errors. The developer can use the AWS SDKs or libraries such as Kinesis Producer Library (KPL) or Kinesis Client Library (KCL) to implement retries with exponential backoff.
The developer can also reduce the frequency and/or size of the requests, which means that the application will send fewer or smaller batches of records to the stream. This will lower the demand on the stream and avoid exceeding its throughput limit. The developer can use techniques such as buffering, compression, or aggregation to reduce the frequency and/or size of the requests.
The other options are not optimal or feasible for the following reasons:
B. Using a PutRecord API instead of PutRecords will not help mitigate the exception, as it will increase the number of requests to the stream. The PutRecord API sends one record at a time to the stream, while the PutRecords API sends multiple records in a single batch request. Using PutRecord will result in more network overhead and more chances of hitting the throughput limit.
D. Using Amazon SNS instead of Kinesis will not meet the requirements, as Amazon SNS is a service that provides pub/sub messaging and mobile notifications for microservices, distributed systems, and serverless applications. Amazon SNS is not designed for processing large streams of data records in real time.
E. Reducing the number of KCL consumers will not help mitigate the exception, as it will affect the performance and scalability of the application. KCL consumers are applications that use KCL to read and process data from a Kinesis stream. Reducing the number of consumers will reduce the parallelism and fault tolerance of the application, as well as increase the risk of data loss or latency.
The latest AWS Certified Developer – Associate DVA-C02 certification actual real practice exam question and answer (Q&A) dumps are available free, which are helpful for you to pass the AWS Certified Developer – Associate DVA-C02 exam and earn AWS Certified Developer – Associate DVA-C02 certification.
