документDiscussion: What does “at-most-once” mean?
When it comes to describing the semantics of a delivery mechanism, there are three basic categories:

at-most-once delivery means that for each message handed to the mechanism, that message is delivered once or not at all; in more casual terms it means that messages may be lost.

at-least-once delivery means that for each message handed to the mechanism potentially multiple attempts are made at delivering it, such that at least one succeeds; again, in more casual terms this means that messages may be duplicated but not lost.

exactly-once delivery means that for each message handed to the mechanism exactly one delivery is made to the recipient; the message can neither be lost nor duplicated.

The first one is the cheapest—highest performance, least implementation overhead—because it can be done in a fire-and-forget fashion without keeping state at the sending end or in the transport mechanism. The second one requires retries to counter transport losses, which means keeping state at the sending end and having an acknowledgement mechanism at the receiving end. The third is most expensive—and has consequently worst performance—because in addition to the second it requires state to be kept at the receiving end in order to filter out duplicate deliveries.

Ага зачотный зоопарк - любо-дорого почитать

На моей памяти потерять сообщение может только еще Кафка и то скорее всего там выскочит эксепшин, что сообщение не прошло от продьюсера после третьей попытке или что-то навроде того. Но там хотя бы осознанный выбор
acks = 0 - the producer won't wait for the confirmation from the leader replica.

P.S. С Аккой не работал всех прелестей не знаю и скорее всего не пойму - прошу строго не судить. Но то, что прочитал заценил.

В теории судя по прерыванию в Кафке это может произойти по таймауту когда продьюсер пытается послать сообщение т.е. когда нагрузка на порт такая, что сообщение попала в дед пул другими словами так как у сообщений нет приоритета кто первый стоит в пуле то сообщение три раза ушло в тайм аут так как более новые сообщения в силу рандомизации прошли и не дали "старому" сообщению доступа. Но это еще не все у вас должно быть асинхронный доступ и вы не проверяете ексепшины.

Так же понятно может быть эксепшин на уровне консьюмера если при обработке сообщения срабатывает ран тайм эксепшин (скажем по какой-то причине делите на ноль) то с точки зрения уровня приложения сообщени так же пропадет.

andreykaT,

Если в продьюсере задействована многопоточность, то может быть вариант когда отсылается сообщение не завершенное и ее уже консьюмер не может обработать и помечает как не прошедшее.

Вообще как Вы пытаетесь определить, что сообщение прошло или потерялось?