Imagine or acknowledge that you have a rapidly growing telematics business (congrats!). You are using flespi as a stable and reliable backend (good for you!) and acquire data via MQTT (nice choice!). Your marketing works hard and sales dept can’t process all the requests. The number of maintained devices is growing every week (I almost envy you!). The dynamics persist for a while, so we skip the part about Rolex, sports cars, and villas on Rivera, and proceed with the tech stuff.
At some point, the number of incoming MQTT messages exceeds the computational capacity of the handler in your business application, and you start losing data. You need to solve this problem before the clients are gone, employees are dispersed, and creditors take out the last Hennessy bottle.
What should you do?
Most probably you will start by optimizing the handler code, adding memory or upgrading CPU. Then (better sooner than later) you will think of extending the number of servers and, as a result, the number of backend workers. The key question your developers need to solve at this step is “How to distribute incoming messages from the flespi MQTT broker?”
Here is a decision tree that led us to the necessity of messages distribution aka “load balancing”:
Let’s justify the choice between creating your own load balancer and using shared subscriptions. Imagine that you have two workers subscribed to a flespi MQTT shared topic. Each of them will receive half of all messages incoming to the topic. This is not some synthetic case — we have already written about how we use MQTT in our internal architecture and we do use shared subscriptions to load-balance between flespi service workers. So you don’t need to invent own solution — we have done it on our side.
How to create shared subscriptions
You don’t even need to install any MQTT software to see how it works. Just open the flespi MQTT page in two tabs. In addition to the configuration info and features, you will find a simple MQTT client. Let’s use it to test shared subscriptions! I recommend using your flespi token instead of a default value since the default token will send regular messages from our demo devices. So we connect two (or three, or five, or N) clients to flespi MQTT broker. The shared subscription looks like:
$share/group_name/topic/name
where $share prefix tells MQTT broker to distribute messages for /topic/name topic between the members of the group_name group. flespi MQTT broker picks a client from the shared group at random.
One more feature is useful for an MQTT connection with QoS=1. If a handler gets stuck and can’t handle new messages, the undelivered messages will go to other clients from the shared group.
As you see, flespi likes sharing (and not only subscriptions). We find a promising technology, implement it, test-drive it by embedding in our solutions, and if we see that it can add value to the public, we share it with you for free with high availability. By the way, MQTT 5.0 support is coming soon, so we’ll prepare a detailed overview of our implementation once ready.
By the way, on top of shared subscriptions we implemented their extended version - so called sticky shared subscriptions where you define the scheme for messages distribution order instead of random.