Resolving Kinesis Data Streams Throttling from Hot Shards
A data engineer uses Amazon Kinesis Data Streams to ingest and process records that contain user behavior data from an application every day. The data engineer notices that the data stream is experiencing throttling because hot shards receive much more data than other shards in the data stream. How should the data engineer resolve the throttling issue?
Community Votes
71% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The core concept tested is Kinesis shard distribution mechanics, with the common trap being the assumption that increasing capacity (adding shards) fixes uneven data skew rather than addressing the root cause of the hot shard.
This question addresses how to resolve throttling caused by hot shards in Amazon Kinesis Data Streams. The correct approach involves modifying the partition key strategy to ensure even data distribution across all shards.
Many candidates choose Option B (increase shards) because it seems like a logical way to handle high load, but adding shards does not solve the problem if the partition key still directs traffic to specific shards, leaving them 'hot' and throttled.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option A is correct because 'hot shards' are caused by an uneven distribution of data, typically due to a partition key that has low cardinality or predictable patterns (e.g., sequential IDs). By using a random partition key (or appending a random suffix), the data engineer ensures that records are distributed uniformly across all available shards. This prevents any single shard from becoming a bottleneck, thereby eliminating the throttling issue at its source.Why the Other Options Are Wrong
Option B is incorrect because simply increasing the number of shards increases overall throughput capacity, but if the partition key logic remains unchanged, the new shards will also receive disproportionate loads. The 'hot' shards remain hot, just with potentially higher absolute limits, but the distribution skew persists. Option C is incorrect because limiting the producer rate is a workaround that sacrifices ingestion speed and doesn't fix the inefficiency of the stream design. Option D is incorrect because decreasing record size helps with bandwidth but does not address the fundamental issue of uneven sharding caused by the partition key.Community Comment Notes
The community discussion highlights the distinction between capacity and distribution. As Faye15599 noted, "A is the best solution because the issue of hot shards is typically caused by an uneven distribution... Using a random partition key ensures that records are distributed more evenly." JekChong correctly identified that increasing shards doesn't solve the desproporción (disproportion) if the key causes concentration, reinforcing that partition key strategy is the primary lever for balancing load.Exam Strategy
When dealing with Kinesis throttling, always distinguish between insufficient capacity (need more shards) and uneven distribution (need better partition keys). If the problem is specifically 'hot shards,' focus on the partition key's randomness and cardinality before considering scaling up.
Frequently Asked Questions
Why isn't increasing shards the right answer for hot shards?
Increasing shards adds capacity but doesn't fix the underlying skew. If the partition key is still deterministic, new shards will also suffer from uneven loads.
What is a hot shard in Kinesis?
A hot shard is one that receives significantly more data than others, hitting its throughput limit and causing throttling while other shards remain underutilized.
Related Analysis
Practice All DEA-C01 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DEA-C01 Practice Test →