What about consuming the message and if success, then check the DB for that message and if not present, add message to DB and return data.
Thus if there was a failure the message will not be registered in the DB and there is no need to compare timestamps.
It adds extra processing (consuming the message and then checking if it's a duplicate), but if duplicates are rare, it would it make the system more reliable by eliminating the timestamps?
Hi! The communication is asynchronous, some client(producer) sends a message to a queue and some server(consumer) pull it from the queue.
If you have multiple consumers, they might consume the same message concurrently, which you can avoid by storing a message id in a table.
But you also want to deal with failures in the consumer (consumer gets the message but fails midway while processing it). All this logic can be abstracted away to some extend by using Step functions or DynamoDB locks.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What about consuming the message and if success, then check the DB for that message and if not present, add message to DB and return data.
Thus if there was a failure the message will not be registered in the DB and there is no need to compare timestamps.
It adds extra processing (consuming the message and then checking if it's a duplicate), but if duplicates are rare, it would it make the system more reliable by eliminating the timestamps?
Hi! The communication is asynchronous, some client(producer) sends a message to a queue and some server(consumer) pull it from the queue.
If you have multiple consumers, they might consume the same message concurrently, which you can avoid by storing a message id in a table.
But you also want to deal with failures in the consumer (consumer gets the message but fails midway while processing it). All this logic can be abstracted away to some extend by using Step functions or DynamoDB locks.