Question

Difficulty: HardStream Processing and Event Routing with Amazon Kinesis and EventBridge

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?

  1. Configure the Kinesis Data Stream target in the EventBridge rule to use a partition key path of $.detail.hubId.Answer
  2. B
    Configure the Kinesis Data Stream target in the EventBridge rule with a static partition key string such as SmartHomeEvents.
  3. C
    Configure 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.
  4. D
    Configure 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

1
Analyze the Kinesis shard allocation logic.
Events are routed to shards based on the hash of the partition key.
We must choose a partition key that has high cardinality to distribute the load, but also groups related messages to the same shard to ensure ordering.
2
Evaluate the ordering requirement.
Events from the same smart home hub must be processed in order.
This means all events from a given hub must share the same partition key so they are routed to the same shard.
3
Compare partition key candidates.
The hubId provides both grouping (guaranteeing ordering per hub) and high cardinality (distributing load across all shards).
A static key causes hot shards, a unique event ID violates ordering, and a low-cardinality device type does not solve throttling.

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
Rate this question