Firma produkcyjna zbiera dane z urządzeń IoT za pośrednictwem Amazon Kinesis Data Streams. Ładunek zawiera identyfikator urządzenia (device ID), datę przechwycenia (capture date), typ pomiaru (measurement type), wartość pomiaru (measurement value) i identyfikator obiektu (facility ID). Producent używa identyfikatora obiektu (facility ID) jako klucza partycji. Zespół operacyjny zaobserwował wiele wyjątków WriteThroughputExceeded: niektóre shardy są przeciążone, podczas gdy inne są bezczynne. Jak firma powinna rozwiązać ten problem z gorącymi shardami?

Poprawna odpowiedź to zmiana klucza partycji na losowo generowany klucz. Problem WriteThroughputExceeded wskazuje na nierównomierne rozłożenie danych, gdzie niektóre shardy są przeciążone (gorące shardy), a inne niewykorzystane. Użycie facility ID jako klucza partycji powoduje, że dane z często używanych obiektów trafiają do tych samych shardów. Losowo generowany klucz, np. UUID, równomiernie rozłoży dane między wszystkie shardy, eliminując gorące shardy i optymalizując wykorzystanie zasobów. Zwiększenie liczby shardów (opcja B) może tymczasowo pomóc, ale nie rozwiąże problemu nierównomiernej dystrybucji danych. Archiwizowanie danych (opcja C) nie wpływa na dystrybucję danych w Kinesis. Zmiana klucza partycji na capture date (opcja D) również może prowadzić do gorących shardów, jeśli w danym momencie jest duży napływ danych.