Exam AWS Certified Big Data - Specialty topic 1 question 8 discussion

The KPL provides the following features out of the box: Batching of puts using PutRecords (the Collector in the architecture diagram) Tracking of record age and enforcement of maximum buffering times (all components) Per-shard record aggregation (the Aggregator) Retries in case of errors, with ability to distinguish between retryable and non-retryable errors (the Retrier) Per-shard rate limiting to prevent excessive and pointless spamming (the Limiter) Useful metrics and a highly efficient CloudWatch client (not shown in diagram) https://aws.amazon.com/blogs/big-data/implementing-efficient-and-reliable-producers-with-the-amazon-kinesis-producer-library/ the answer should be B

Keywords : near-real-time, most reliable and fault-tolerant technique Answer is B : Kinesis Producer Library

B is right answer. There seems to be typo in question - it must be addUserRecord method. https://aws.amazon.com/blogs/big-data/implementing-efficient-and-reliable-producers-with-the-amazon-kinesis-producer-library/

D https://docs.aws.amazon.com/kinesis/latest/APIReference/API_PutRecords.html

The answer should be B however KPL does not have a method named .addRecords. It looks like typo, as the KPL method is addUserRecord.

D is the correct answer A,is worng need to setup back of retry . B. dont' exist addrecords api C.it is anti-patern

A is correct. B - there is no addrecords in KPL. D - There is no backoff algorithm in Kinesis Agent.

After researching further, I think B is the right answer. KPL has built in fault tolerance with configurable retry mechanism and there is no need to write custom fault-tolerant logic to do so. Besides KPL allows us to batch the records ( aggregation and collection) out of the box without having to write custom code to achieve scalability.

D is the right answer. You need to do a back off with retry. You can do it exponentially. This usually happens due to a hot partition. To ensure fault tolerance if using an PutRecord API you will need to handle ProvisionedThroughputExceeded exceptions and the way to do that is to use backoff with retry mechanism. Option A seems to suggest we are doing a retry but in a loop. However if we don't do a back-off (meaning wait for a certain duration) before we retry, the system would continue to fail.

B is the Correct Answer

Answer is B. KPL is used when High performance, long-running producers Automated and configurable retry mechanism Sync and Async API(better perf for Async) 100B records (high volume of data)

my selection A

why not B? seems to me you need to reinvent the wheel in A while kpl can do all that already

exponential back-off algorithm appears in answer D -> this seems to be the correct one.

A looks correct.

A is correct

Option A is correct because there is concept of back-off algorithm in Kinesis https://docs.aws.amazon.com/streams/latest/dev/kinesis-producer-adv-retries-rate-limiting.html