Bank gromadzi duże ilości danych transakcyjnych i przesyła je strumieniowo do Amazon Kinesis Data Streams za pomocą PutRecord. W pewnych momentach występują awarie sieci, a inżynier danych potrzebuje semantyki dostarczania dokładnie raz (exactly-once delivery semantics) w całym potoku przetwarzania. Które podejście to osiągnie?

Aby osiągnąć semantykę dostarczania dokładnie raz (exactly-once delivery semantics) w przypadku awarii sieci, kluczowe jest deduplikowanie danych po stronie konsumenta. Osadzenie unikalnego identyfikatora (np. UUID lub kombinacji identyfikatorów) w każdym rekordzie u źródła pozwala aplikacji przetwarzającej na identyfikację i odrzucenie zduplikowanych rekordów, które mogły zostać wysłane ponownie z powodu awarii sieci i mechanizmów ponawiania prób (at-least-once delivery Kinesis). Aktualizacja konfiguracji punktów kontrolnych w Amazon Managed Service for Apache Flink pomaga w odzyskiwaniu po awariach i zapewnia przetwarzanie dokładnie raz w obrębie samej aplikacji Flink, ale nie rozwiązuje problemu duplikatów wprowadzonych przez producenta do Kinesis Data Streams. Zaprojektowanie źródła danych tak, aby zdarzenia nie były wielokrotnie ingestowane, jest trudne do zagwarantowania w przypadku awarii sieci i mechanizmów ponawiania prób. Zaprzestanie używania Kinesis Data Streams na rzecz Amazon EMR nie rozwiązuje problemu duplikacji danych u źródła i wprowadza inną architekturę, która również wymagałaby mechanizmów deduplikacji.