I have been organizing books I read before.
This post is about Building an IoT Platform from 0 to 1.
This book helped me a lot, especially when my company decided to introduce MQTT.
I used to think IoT was pretty simple.
Device connects. It publishes a message. The backend subscribes. Data goes into the database.
It sounded not that hard.
After reading this book, I realized the hard part is not really "how to connect."
The hard part starts after the device connects.
Devices go offline.
Networks jitter.
Clients can be slow.
Battery can be limited.
Topics can get long.
Authorization cannot hit the database every time.
A command being sent does not mean it was actually received.
What made this book useful to me is that the author has more than ten years of experience in large-scale IoT companies.
So the book is not just explaining the MQTT spec. It opens up problems that usually only appear after a system is actually online.
For example, ACL cache.
In a normal backend system, I might instinctively think: checking the database on every publish or subscribe sounds reasonable, right?
But IoT is not a few users clicking buttons.
It can be a large number of devices sending data continuously.
Checking the database every time sounds like something that would break very quickly.
I later added a practical comparison here.
MQTT 5 is a protocol. EMQX cache is a broker implementation design. These two things should be separated.
MQTT 5 provides protocol-level capabilities such as session expiry, enhanced authentication, and user properties. These give the broker more context to work with.
But ACL cache, authorization cache, and external resource cache are usually implementation designs that brokers use to handle large numbers of device requests.
You can see similar ideas in brokers like EMQX.
It has authorization cache, which can store authorization results in the client session.
Within the same connection, if a client's publish or subscribe request hits a rule that has already been checked, the broker does not need to run the full authorization check again.
If authorization data comes from external resources such as MySQL, MongoDB, or Redis, external resource cache can also help the broker avoid repeatedly calling the database or service behind it.
Shared Subscription also stood out to me, because it is easy to forget during development.
When I think about backend subscribe, I might imagine one service subscribing to a topic and writing data into the database.
In development, there is usually only one backend instance, so everything looks normal.
But in production, there may be multiple consumers, multiple pods, or multiple workers processing device data together.
That is when Shared Subscription becomes important.
It is a bit like a consumer group.
Multiple backend workers can join the same shared group, and the broker distributes each message to one of them.
For example: $share/backend-workers/device/+/telemetry.
Then there is sending commands by tag.
I used to think of a command as something sent to one specific device.
But reality is usually not like that.
You may want to operate on a product, a region, a firmware version, or a group of devices.
In that case, tags are not just labels. They become the boundary of an operation.
The book also mentions tag version.
I found this interesting because it feels a bit like optimistic locking in a database.
You need to know which version of the tag rules your command is based on. Otherwise, you may operate on a group of devices using stale conditions.
This is the kind of detail I probably would not think of by only reading the MQTT spec.
Topic Alias also made sense to me.
In a backend system, a long topic name may look harmless. It can even make the purpose of the topic clearer.
But in the IoT world, if there are many devices, high reporting frequency, and unstable networks, sending the full topic every time becomes bandwidth cost.
MQTT 5.0 Topic Alias can use a shorter alias instead of repeatedly sending a long topic.
This may not feel important in a normal web backend, but in a device scenario it makes a lot of sense.
Inflight Window is another example.
Not every client has a good network.
If a client is slow and you keep pushing messages to it, either the client breaks, or the broker has to carry a lot of state for it.
So it is not enough to say, "just use a higher QoS."
Reliability itself has a cost.
The book even talks about CoAP.
This reminded me that not every device is suitable for MQTT.
Some devices have very limited battery and weak network capability. They may sleep most of the time.
In that case, a lighter UDP-based protocol such as CoAP may make more sense.
In other words, building an IoT platform is not finished after choosing a protocol.
You always have to return to the device itself:
How much battery does it have?
How stable is its network?
Will it go offline?
Does it need to respond after receiving a command?
If there is no response, did the device not receive the command, or did it receive it but not process it yet?
My biggest takeaway from this book is:
The hard part of MQTT is not the connection.
The connection is only the beginning.
The real challenge is whether the platform can maintain a trustworthy state after devices enter the real world.
Who is online?
Who is offline?
Which permissions are still valid?
Which command was actually delivered?
Which data only arrived late?
Which command has already expired and should simply not be sent anymore?
That is also why I still think Old School reading is useful.
Some pitfalls do not appear when you search for one answer.
You need to follow someone who has really worked in the field for many years, walking through connection, authentication, authorization, messaging, data, and operations, before you slowly start to understand.