Currently in my project in which the controller(client) sends sensor data to the server and receives feedback from the server with some additional data, uses MQTT protocol for communication. It has 2 separate topics for client and server.

For Example:

Topic1 - Client(SUBSCRIBES), Server(PUBLISHES)
Topic2 - Client(PUBLISHES), Server(SUBSCRIBES)

But if this project is a use case of a larger application, let's say some 5000 devices need to be installed somewhere.

So, will it be needed to create 5000 different topics for both client and server? Or with lesser topics it can be done and how?

  • 1
    Why do you think it's a problem to have a lot of topics?
    – hardillb
    Commented Sep 27, 2018 at 9:19
  • 1
    Probably because the software would have to manage them all.
    – Mawg
    Commented Sep 27, 2018 at 10:33
  • 1
    @hardillb It's not a problem ... just was curious ... but can an MQTT topic have a sub-topic?
    – ron123456
    Commented Sep 27, 2018 at 11:18
  • 2
    Sure, topics are hierarchical, so any scheme can be devised. Sparkplug s3.amazonaws.com/cirrus-link-com/… has a couple of topics per edge node and device behind edge node. Commented Sep 27, 2018 at 11:35
  • have a look at this shiftr.io/shiftr-io/demo
    – jsotola
    Commented Oct 8, 2018 at 1:05

1 Answer 1


From client to server you may pack client-id into payload, e.g. if it is JSON, one of the keys can have client-id value.

Response from server to client should contain client-id in order to broker to not to broadcast message, but to send it directly to one connected client.

At the same time you may subscribe your server to something like: "requests/+" and each client will publish to "request/{client-id-1}", "request/{client-id-2}", and server will receive both with just one subscription.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.