Een bank verzamelt grote hoeveelheden transactionele gegevens en streamt deze naar Amazon Kinesis Data Streams met behulp van PutRecord. Op bepaalde momenten treden netwerkstoringen op en de data engineer heeft exactly-once delivery semantics nodig voor de gehele verwerkingspipeline. Welke aanpak zal dat bereiken?

De correcte aanpak is om de applicatie te ontwerpen om duplicaten te verwijderen door een unieke ID in elk record op te nemen. Dit is de meest effectieve manier om exactly-once delivery te garanderen in gedistribueerde systemen zoals Kinesis Data Streams, waar netwerkproblemen of retries kunnen leiden tot dubbele records. Door een unieke ID (bijvoorbeeld een UUID of een combinatie van bron-ID en timestamp) toe te voegen aan elk record bij de bron, kan de downstream verwerkingslogica (bijvoorbeeld een Kinesis Data Analytics-applicatie of een Lambda-functie) duplicaten identificeren en negeren. Het bijwerken van de checkpoint-configuratie van Amazon Managed Service for Apache Flink voorkomt geen duplicaten die voor het checkpointing-mechanisme ontstaan, zoals bij retries van de PutRecord-aanroep. Het ontwerpen van de databron om geen dubbele gebeurtenissen op te nemen is ideaal, maar niet altijd haalbaar of betrouwbaar bij netwerkstoringen. Stoppen met Kinesis Data Streams en overstappen op Amazon EMR lost het onderliggende probleem van exactly-once delivery in een gedistribueerde omgeving niet op en introduceert onnodige complexiteit.