(EDIT: just realised that you specifically mentioned stateful event processing, while what I describe below are two approaches for stateless, exactly-once event

(EDIT: just realised that you specifically mentioned stateful event processing, while what I describe below are two approaches for stateless, exactly-once event processing) Having had a few cracks at this problem, in my opinion using locks is the wrong approach. What you will want is: * split all input data in batches (eg batches of 10k records, or periodic heartbeats every X seconds, etc) * assign each batch a unique identifier * when writing data to the output store, store the batch id along the data; * when retransmitting a batch for whatever reason, reuse the same batch id and overwrite any data in the output store that matches this batch id. Obviously this becomes more tricky when you’re dealing with eg window functions or more complex aggregations. In this situation, I believe that an approach such as “asynchronous barrier snapshotting” works best. Every X seconds, you increment an epoch. While incrementing, you stop ingestion. Then you first tell the output source to create a checkpoint, then the input source to create a checkpoint, and once both have been checkpointed, you can continue streaming data again. Anyway, these are two approaches I’ve used over the years that work well. Explicit locks don’t work well in distributed processing, imho.