I actually didn’t realize that the expected last sequence could be combined with nats-rollup. In the example above (as I understand it) if we added that to the snapshot, NATS would throw out the snapshot, so the log would still be correct, but the work of snapshotting it and sending it over the wire would be lost. If messages were frequent enough, and/or snapshots took a while to compute/transfer, you might never have a roll-up succeed.
Our approach is that a roll-up will always succeed, we just preserve any messages in the stream with a sequence number greater than the one provided.
(I’m enjoying it too, and am a user of NATS so I’m happy to learn things I didn’t know about it :)
> If messages were frequent enough, and/or snapshots took a while to compute/transfer, you might never have a roll-up succeed.
Yes, good point. The "snapshotting up to a lagging sequence" could be achieved with two separate subjects to reduce contention, but is a bit more work.
It sounds like, in Drift's case, the snapshot effectively brings up the tail (snapshot), but the head can still be appended to with new events.
I actually didn’t realize that the expected last sequence could be combined with nats-rollup. In the example above (as I understand it) if we added that to the snapshot, NATS would throw out the snapshot, so the log would still be correct, but the work of snapshotting it and sending it over the wire would be lost. If messages were frequent enough, and/or snapshots took a while to compute/transfer, you might never have a roll-up succeed.
Our approach is that a roll-up will always succeed, we just preserve any messages in the stream with a sequence number greater than the one provided.
(I’m enjoying it too, and am a user of NATS so I’m happy to learn things I didn’t know about it :)