22 February, 2018

Shared subscriptions: yet another flespi MQTT broker feature

There’s no need to load-balance the message flow across servers manually any longer — flespi MQTT broker can do it for you.

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”:

flespi mqtt shared subscriptions decision tree

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.

flespi mqtt load balancing 

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

flespi mqtt client shared subscriptions demo

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.



Get the latest updates and monthly newsletters from flespi in your inbox

10 April, 2018 | flespi features | Anton Kulichenko

First MQTT 5.0-compliant broker on the market. flespi takes the lead

The latest standard for IoT connectivity now supported. Shared subscriptions, retained messages, response topic, maximum packet size, and more. Plus bonuses from the flespi team!

30 March, 2018 | flespi features | Aliaksei Shchurko

Retained messages and extended REST API in flespi MQTT broker

We keep growing our MQTT 5.0 compliance — storing the last state of the topic added. Plus, we created a unique REST API for remote management of flespi MQTT broker.