MQTT has some basic Quality of Service (QoS) capability built in. Basically, say you were using MQTT over a radio, and your toaster is sending radio signals to some base station...there's a chance those messages won't arrive.
Depending on your type of data and the underlying transport, you may have different requirements for how reliable you want MQTT to be. More reliability means more data transmissions, and more code management. This is mostly managed by the broker, but the client can request certain QoS
The simplest QoS is called 0 - in this QoS, the broker/client will deliver the message once, with no confirmation. This is best used when your underlying transport is very reliable, say TCP/IP, or when you want to conserve power and data at the trade of consistancy
For example, say you have a GPS vehicle tracker that sends location data over cellular every 30 minutes. If your tracker is running over a long period of time it might be OK if once in a while, a GPS location is ‘dropped’. You just want to get most messages so you have an idea of where your truck is. It's more important that you conserve battery because the cellular network has reliability and re-transmission built in - if you are outside range you don't want to keep re-trying, you'll use up your battery!
The next step up is QoS 1. In this QoS, the broker/client will deliver the message at least once, with confirmation required. These are called ACKs and you'll get an ACK for every publication, subscription, etc. You'll need to send an ACK from the broker and the client!
For example, you have an IoT AC unit that is monitored and controlled remotely. When you send a message for it to turn on you want to make sure it turns on! If you send a message and the transport fails, you can just keep sending messages over until you get a reply from the broker.
This QoS is what most people use. It's a good balance!
Finally, you have QoS 2, the greatest of the QoS's! In this QoS, the broker/client will deliver the message exactly once by using a four step handshake.
This one is not as common because it’s very hard to really guarantee single-delivery without a rock solid transport. So you will want to consider a feedback system using different topics and sensors instead!
For example, you have a robotic tractor that you send commands like “Move forward 50 meters” - you want to make sure that you don’t accidentally send two messages and it turns out it moved 100 meters! Since QoS 2 is a bit of a pain, you may want to change this to, instead, use two topics: one that sends the movement command from controller to tractor, and then another one from the tractor to controller that gives the current location.