HikeHills.com (HH) is an online specialty retailer that sells clothing and outdoor refreshment gear for trekking, go camping, boulevard biking, mountain biking, rock hiking, ice mountaineering, skiing, avalanche protection, snowboarding, fly fishing, kayaking, rafting, road and trace running, and many more.
HH runs its entire online infrastructure on java based web applications running on AWS. The HH is capturing click stream data and uses a custom-build recommendation engine to recommend products which eventually improve sales, understand customer preferences and already using AWS Kinesis Producer Library to collect events and transaction logs and process the stream.
HH IT team identified a lot of performance issues with the Kinesis Stream and based on the metrics captured, identified hot and cold shards.IT team wants to effectively improve the performance of the hot shards. There are 2 hot shards SHARD 1 with a hash key range of 276...381 and SHARD 2 with a hash key range of 382...454. What basic re-sharding strategy needs to be applied and how can it be applied?

Answer options:

A.SHARD 1 need to be split as SHARD 1A with hash keys between 276.. .332 and SHARD 1B between 332…381, SHARD2 into SHARD2A between 382..410and SHARD B between 410..454
B.SHARD 1 need to be split as SHARD 1A with hash keys 276.. .332 and SHARD 1B as 333…381, SHARD2 into SHARD2A 382..410and SHARD B as 411..454
C.MERGE AND SPLIT SHARD 1 and SHARD2 into 3 SHARDS, SHARD12A with hash keys 276…370, SHARD12B as 371…420, SHARD12Cas 421..454
D.MERGE 2 SHARDS into 1 SHARD with hash keys between 276..454 which improves performance by unifying hash keys into a single shard

Answer: B
Option A is incorrect. Shards cannot overlap each other shard. Besides, The performance of hot shards improves when the hot shards are split into 2 shards.
Considering the following case, where SHARD 1 has a hash key range of 276..381 and SHARD 2with a hash key range of 382..410. when split, shards cannot overlap each other shard.
In this option, SHARD 1A is with hash keys 276.. .332 and SHARD 1B with hash keys 332…381, SHARD2 into SHARD2A between 382..410and SHARD B between 410..454. There is a clear overlap shown.
https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-resharding-split.html
Option B is correct. The performance of hot shards improves when the hot shards are split into 2 shards.
Besides, there is no overlap of shards after the split.
SHARD 1 need to be split as SHARD 1A with hash keys between 276.. .332 and SHARD 1B between 333…381, SHARD2 into SHARD2A between 382..410and SHARD B between 411..454.
This is a perfect illustration
https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-resharding-split.html
Option C is incorrect. Merge of shards does not improve performance but helps with costs. This resharding strategy helps with cold shards. Merging 3 shards happens after SHARD 1 and SHARD 2 are merged and the result with SHARD 3. This may be an alternate option but need to see how much performance the split brings on. definitely not a first resharding strategy to consider.
https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-resharding-split.html
Option D is incorrect. Merge of shards does not improve performance but helps with costs. this resharding strategy can be applied for cold shards.
https://docs.aws.amazon.com/streams/latest/dev/kinesis-using-sdk-java-resharding-merge.html