MQTT is a fantastic pub/sub protocol, but forcing it to handle request/response patterns is a recipe for disaster. Let’s explore why you need a proper abstraction layer like MQTT+ for RPC and streams in your IoT stack.

Beyond Pub/Sub: Bringing Sanity (and RPC) to Your MQTT Architecture

I remember one late night, staring at a Grafana dashboard that was just a sea of red. We had a fleet of thousands of IoT gateways that needed to pull down new configurations. The brilliant idea was to use MQTT. Simple, right? The device publishes to gateways/req/config/{gatewayId} and our backend would reply on gateways/res/config/{gatewayId}. What followed was a multi-week nightmare of untraceable timeouts, duplicate requests from flaky network connections, and a rat’s nest of code trying to match a response to the original request using a `correlationId` buried in the JSON payload. We were trying to hammer in a screw, and it was a mess. That’s the exact pain a library like MQTT+ is built to solve.

The “Why”: You’re Fighting The Protocol

Let’s be clear: MQTT is fundamentally a publish-subscribe protocol. It’s designed for decoupled, fire-and-forget messaging. A publisher fires a message to a topic, and it has no idea if zero, one, or a thousand subscribers received it. This is a feature, not a bug! It’s what makes it so resilient and scalable for telemetry and event-driven systems.

The problem arises when you need a direct request/response interaction, also known as Remote Procedure Call (RPC). You send a command and you need a specific answer from a specific service, and you need it now. When you try to force this pattern onto a pub/sub system, you end up manually rebuilding all the things a real RPC framework gives you for free: request/response correlation, timeouts, error handling, and discovery. You’re fighting against the very nature of the protocol, and that’s a battle you’ll eventually lose in complexity.

The Fixes: From Duct Tape to a Proper Toolkit

So, you’re stuck. You need RPC over MQTT. Here’s how we’ve tackled this on my teams, from the quick-and-dirty to the architecturally sound.

Solution 1: The “Roll-Your-Own” RPC Hack

This is the path most people stumble down first. It’s the manual, duct-tape approach I mentioned from my war story. You invent a topic scheme and use a correlation ID to stitch things together.

The Pattern:

1. The client generates a unique ID (e.g., a UUID) and a unique response topic.
2. The client subscribes to its unique response topic: responses/my-client/123-abc.
3. The client publishes a message to a generic request topic like rpc/get-device-status. The payload includes the response topic and the correlation ID.
4. The server, listening on rpc/get-device-status, picks up the message, does its work, and publishes the result to the response topic specified in the payload.
5. The client receives the message, checks the correlation ID, and continues its work.

// --- Client Side (The Hacky Way) ---
const correlationId = 'unique-id-12345';
const responseTopic = `responses/client-abc/${correlationId}`;

// Listen for the specific response
mqttClient.subscribe(responseTopic);
mqttClient.on('message', (topic, payload) => {
  if (topic === responseTopic) {
    console.log('Got my response!', JSON.parse(payload));
    // Don't forget to unsubscribe and handle timeouts!
    mqttClient.unsubscribe(responseTopic);
  }
});

// Send the request
mqttClient.publish('requests/get-status', JSON.stringify({
  correlationId: correlationId,
  replyTo: responseTopic,
  params: { deviceId: 'thermostat-99' }
}));

Warning: This “works,” but it’s incredibly brittle. You are now responsible for managing thousands of unique subscriptions, handling timeouts if a response never arrives, and cleaning everything up. It’s a massive source of bugs and technical debt. Use it only if you have a single, critical use case and no time for a better solution.

Solution 2: The Abstraction Layer (Enter MQTT+)

This is the permanent fix. Instead of reinventing the wheel, you use a library that’s purpose-built to solve this exact problem. A tool like MQTT+ sits on top of the excellent MQTT.js library and provides a clean, modern `async/await` API for RPC and even streaming responses. It manages the ugly topic schemes, correlation IDs, and timeouts for you, so you can focus on your application logic.

The Pattern (with MQTT+):

The library handles all the underlying complexity. You just define a procedure and call it.

// --- Server Side (The Clean Way) ---
// Define an RPC endpoint
mqttPlus.rpc.handle('get-device-status', async (payload) => {
  const { deviceId } = payload;
  const status = await db.getStatusFor(deviceId);
  // Just return the result. The library handles the rest.
  return { status: status, ts: Date.now() };
});

// --- Client Side (The Clean Way) ---
// Just call the remote procedure!
async function checkStatus() {
  try {
    const response = await mqttPlus.rpc.call('get-device-status', { 
      deviceId: 'thermostat-99' 
    });
    console.log('Server responded with:', response);
    // { status: 'online', ts: 167... }
  } catch (error) {
    console.error('RPC call failed:', error.message);
  }
}

Look at that. It’s clean, it’s testable, and it reads like any other modern asynchronous code. This is the approach a senior engineer should advocate for. You’re not fighting the tool; you’re using a higher-level tool that leverages the underlying protocol correctly.

Solution 3: The “Wrong Tool” Reality Check

Sometimes, the right move is to take a step back and ask: are we using the right tool for the job? If your entire application is 90% RPC and only 10% pub/sub, you might be forcing MQTT into a role it was never designed for. In this scenario, the “nuclear option” is to use a different primary protocol.

Pro Tip: Don’t be a technology zealot. A good architect knows when to pivot. Being married to a tool, even a great one like MQTT, can be a huge mistake if the application’s requirements have changed.

Here’s a quick breakdown of when to consider alternatives:

Choosing this option requires courage and honesty. It often means admitting an early architectural choice was wrong. But making that hard call will save you from the “late night dashboard of red” I experienced. Use MQTT for what it’s amazing at, and when you need to extend its capabilities, use a proper abstraction like MQTT+ to do it right.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions