Bir üretim şirketi, Amazon Kinesis Data Streams aracılığıyla IoT cihaz verilerini toplar. Yük (payload) cihaz kimliği, yakalama tarihi, ölçüm türü, ölçüm değeri ve tesis kimliği içerir. Üretici, bölüm anahtarı (partition key) olarak tesis kimliğini kullanır. Operasyon ekibi birçok WriteThroughputExceeded istisnası gözlemledi: bazı shard'lar aşırı yüklenirken diğerleri boştaydı. Şirket bu hot-shard sorununu nasıl çözmelidir?

Doğru cevap, bölüm anahtarını tesis kimliğinden rastgele oluşturulmuş bir anahtara değiştirmektir. Kinesis Data Streams'de hot-shard sorunu, belirli bir bölüm anahtarının diğerlerinden daha fazla veri almasıyla ortaya çıkar. Tesis kimliği gibi düşük kardinaliteli bir anahtar kullanılırsa, belirli tesisler çok fazla veri ürettiğinde bazı shard'lar aşırı yüklenirken diğerleri boş kalır. Rastgele oluşturulmuş bir anahtar kullanmak, verilerin shard'lar arasında daha eşit dağılmasını sağlayarak WriteThroughputExceeded istisnalarını azaltır. Shard sayısını artırmak, temel dağıtım sorununu çözmediği için yalnızca geçici bir çözüm olabilir. Üretici tarafında verileri arşivlemek, Kinesis'teki hot-shard sorununu çözmez, sadece veri depolama stratejisini etkiler. Bölüm anahtarını yakalama tarihine değiştirmek, belirli bir zaman diliminde çok fazla veri gelirse yine hot-shard sorununa yol açabilir.