> Could the service have committed more messages than it acknowledged?

Yes of course. It may have committed records but not had time to to ACK success.

> Or many less than I've sent?

Yes again. However it will NEVER ACK success for writes which it hasn't committed.

So the persistence story is pretty straightforward (I'll see if we can update docs if this is missing).

If you want to avoid duplication on the write side, you would have to retrieve the last log record-- with id x-- and start adding records again from id x+1.

Fencing + locking combine to provide efficient exclusive access and the fat client (for now) guarantees write ordering.