Events are distributed across partitions, but a hot key must be avoided.
Events for one customer must retain order while different customers should spread across partitions.
Which design is most appropriate?
Hash the customer ID as the partition key, then monitor hot keys and adjust the design if one customer dominates traffic.
Detailed explanation
Random keys distribute load but lose ordering for the same customer.
Random keys distribute load but lose ordering for the same customer.
Ordering is preserved but capacity and throughput are concentrated in one partition.
Ordering is preserved but capacity and throughput are concentrated in one partition.
S3 storage characteristics do not select an ingestion partition.
S3 storage characteristics do not select an ingestion partition.
One customer maps consistently to a partition for ordering while different customers distribute by hash.
One customer maps consistently to a partition for ordering while different customers distribute by hash.
Check official documentation
Compare the following points with the official documentation.
Kinesis・Kafkaのpartition key、ハッシュ分散、順序性の公式説明を確認する。
What to confirm
順序保証と負荷分散のトレードオフを説明できる。
Key points
- Partition key
- Hashing
- Ordering
- Hot key
Notes
- Environment: AWS公式DEA-C01試験ガイドと各サービスの公式ドキュメントの確認
- Confirm current AWS service behavior in the official DEA-C01 documentation.
Foundation review
Order versus distribution
The key defines the unit of ordering and the unit of load distribution at the same time.
Hot-key mitigation
Monitor skew and consider subkeys, salting, or capacity changes when one entity dominates.