DAS-C01 · Question #129
A power utility company is deploying thousands of smart meters to obtain real-time updates about power consumption. The company is using Amazon Kinesis Data Streams to collect the data streams from…
The correct answer is C. Reduce the propagation delay by overriding the KCL default settings. The KCL default polling interval (idleTimeBetweenReadsInMillis) is 1000 ms (1 second), which directly explains the observed 1-second latency. Overriding this KCL setting to a lower value (e.g., 250 ms) reduces the propagation delay and can bring end-to-end latency well below…
Question
A power utility company is deploying thousands of smart meters to obtain real-time updates about power consumption. The company is using Amazon Kinesis Data Streams to collect the data streams from smart meters. The consumer application uses the Kinesis Client Library (KCL) to retrieve the stream data. The company has only one consumer application. The company observes an average of 1 second of latency from the moment that a record is written to the stream until the record is read by a consumer application. The company must reduce this latency to 500 milliseconds. Which solution meets these requirements?
Options
- AUse enhanced fan-out in Kinesis Data Streams.
- BIncrease the number of shards for the Kinesis data stream.
- CReduce the propagation delay by overriding the KCL default settings.
- DDevelop consumers by using Amazon Kinesis Data Firehose.
How the community answered
(31 responses)- A10% (3)
- B3% (1)
- C84% (26)
- D3% (1)
Explanation
The KCL default polling interval (idleTimeBetweenReadsInMillis) is 1000 ms (1 second), which directly explains the observed 1-second latency. Overriding this KCL setting to a lower value (e.g., 250 ms) reduces the propagation delay and can bring end-to-end latency well below 500 ms. Option A (enhanced fan-out) uses an HTTP/2 push subscription model that achieves ~70 ms latency but is primarily designed to support multiple simultaneous consumer applications - the company has only one consumer, making this more complex than needed. Option B (more shards) increases read/write throughput capacity but does not reduce per-record latency for a single consumer. Option D (Kinesis Data Firehose) is a delivery service to destinations like S3 or Redshift and is not used to build low-latency consumer applications.
Topics
Community Discussion
No community discussion yet for this question.