With mqtt it depends on the broker, eg. Emitter.io can save them for a week etc.
Offset for a client is usually stored on the broker, so if a client reconnects, all of the messages it has missed are forwarded to it.
As mentioned in other answers, service levels have a defined meaning, which is different to the absolute theoretical meaning, and really is to do with the message aks.
Really, as the article mentions, kafka and mqtt are for different purposes, with some overlap. Kafka is all about the log, whereas mqtt is about uncertain connections. A better comparison which I've yet to see, is comparing mqtt to nats.
Lastly, kafka is much easier to administer using redpanda, which doesn't have zookeeper, combines the registry and kafka connect (see WASM runners) with the runtime, and has a very nice console for debugging.
Similarly, Emitter.io does a great job with clustering for mqtt.
I'd like to see an open source kafka-mqtt bridge that worked in both directions as they all seem to go mqtt->kafka only.
As mentioned in other answers, service levels have a defined meaning, which is different to the absolute theoretical meaning, and really is to do with the message aks.
Really, as the article mentions, kafka and mqtt are for different purposes, with some overlap. Kafka is all about the log, whereas mqtt is about uncertain connections. A better comparison which I've yet to see, is comparing mqtt to nats.
Lastly, kafka is much easier to administer using redpanda, which doesn't have zookeeper, combines the registry and kafka connect (see WASM runners) with the runtime, and has a very nice console for debugging.
Similarly, Emitter.io does a great job with clustering for mqtt.
I'd like to see an open source kafka-mqtt bridge that worked in both directions as they all seem to go mqtt->kafka only.