Earlier quoted context omitted.
It's not down
Hmm weird. I get: This site can’t be reached segment.com refused to connect. Try: Checking the connection ERR_CONNECTION_REFUSED Maybe something local to me only?
Delivering Billions of Messages Exactly Once
11–20 of 141 posts
Re: Delivering Billions of Messages Exactly Once
#12Isn't the new feature of Kafka about this? https://issues.apache.org/jira/browse/KAFKA-4815
So we can get duplicate API submissions regardless of whether or not we enabled transactional productions into kafka from a producer.
Re: Delivering Billions of Messages Exactly Once
#13Earlier quoted context omitted.
It's not down
Hmm weird. I get: This site can’t be reached segment.com refused to connect. Try: Checking the connection ERR_CONNECTION_REFUSED Maybe something local to me only?
Re: Delivering Billions of Messages Exactly Once
#14Re: Delivering Billions of Messages Exactly Once
#15Would something like AWS SQS not scale for something like this? We currently push about 25k daily transactions over SQS, obviously no where near the scale of this, just wondering about what limitations we will bump into potentially.
Re: Delivering Billions of Messages Exactly Once
#16Earlier quoted context omitted.
It's not down
Hmm weird. I get: This site can’t be reached segment.com refused to connect. Try: Checking the connection ERR_CONNECTION_REFUSED Maybe something local to me only?
Re: Delivering Billions of Messages Exactly Once
#17> If the dedupe worker crashes for any reason or encounters an error from Kafka, when it re-starts it will first consult the “source of truth” for whether an event was published: the output topic.
Does this mean that "on worker crash" the worker replays the entire output topic and compare it to the rocksdb dataset?
Also, how do you handle scaling up or down the number of workers/partitions?
Re: Delivering Billions of Messages Exactly Once
#18IIRC, it's provably impossible in a distributed system where processes might fail, i.e. all real systems.
Re: Delivering Billions of Messages Exactly Once
#19Would something like AWS SQS not scale for something like this? We currently push about 25k daily transactions over SQS, obviously no where near the scale of this, just wondering about what limitations we will bump into potentially.
Re: Delivering Billions of Messages Exactly Once
#201) do nothing, risking message loss
2) retransmit, risking duplication
But of course that's only from messaging system point of view. Deduplication at receiver end can help reduce problem, but itself can fail (there is no foolproof way of implementing that pseudocode's "has_seen(message.id)" method)