A developer is building a home automation backend where smart home hubs publish state-change events to a custom Amazon EventBridge event bus. The developer wants to route these events to an Amazon Kinesis Data Stream for real-time anomaly detection. It is critical that events originating from the same home hub are processed in the exact order they are generated to avoid false alarm triggers. During testing, the Kinesis Data Stream suffers from write throttling due to a hot shard, while other shards remain underutilized. Which target configuration change in the EventBridge rule will resolve the throttling while preserving the ordered processing of events from each hub?
- Configure the Kinesis Data Stream target in the EventBridge rule to use a partition key path of $.detail.hubId.Answer
- BConfigure the Kinesis Data Stream target in the EventBridge rule with a static partition key string such as SmartHomeEvents.
- CConfigure the Kinesis Data Stream target in the EventBridge rule to use a partition key path of $.detail.eventId, which is a unique UUID generated for every event.
- DConfigure the Kinesis Data Stream target in the EventBridge rule to use a partition key path of $.detail.deviceType, and increase the consumer Lambda function timeout.
Answer
Configure the Kinesis Data Stream target in the EventBridge rule to use a partition key path of $.detail.hubId.
Configuring the partition key path to extract the hub identifier ensures that all state-change events generated by a specific hub are assigned the same partition key. Kinesis hashes this key to route all these events to the same shard, preserving their sequential order. Since there are many unique hubs, this high-cardinality key distributes events evenly across all available shards, resolving the write throttling.
Step-by-Step Solution
Key Concept
In Amazon Kinesis Data Streams, partition keys determine which shard receives a record. When Kinesis is targeted by EventBridge, configuring a partition key path with a high-cardinality identifier that is common to related events (like a hub ID) distributes the workload evenly across shards while guaranteeing sequential processing for each identifier.
Estimated Time:2m 0s