We send the confirm as soon as the message hits the mmap and is appended to the local replication queue because that keeps publish latency at memory-copy speed, and the loss window is narrow: only messages still in the page cache or sitting in the replication queue when the leader dies. Config options are coming to opt into stronger guarantees (msync on the leader, waiting for follower ack, or follower fsync), at the cost of added latency.
Hi Anders, thank you for the clarity!
That make sense, it sounds like the "publisher confirm" feature for RabbitMQ that we used before! And it's good to know the stronger options are coming :D
We send the confirm as soon as the message hits the mmap and is appended to the local replication queue because that keeps publish latency at memory-copy speed, and the loss window is narrow: only messages still in the page cache or sitting in the replication queue when the leader dies. Config options are coming to opt into stronger guarantees (msync on the leader, waiting for follower ack, or follower fsync), at the cost of added latency.