Use case

Live prices on every trading screen

Your feed handler publishes each price update once; every web, mobile and desktop client watching that symbol receives it over secure WebSockets. A user who opens the app sees the last price straight away, from a retained message.

No card required

Example message

PUBLISH md/fx/EURUSD/quote

{"bid":1.08412,"ask":1.08415,"ts":1761120000123}

QoS 1 · TLS 8883 · PUBACK

The problem

Polling and home-grown socket servers don’t scale

Brokerage, crypto and fintech apps need prices to move on screen as the market moves. REST polling wastes bandwidth and still lags; a home-grown WebSocket server ends up re-implementing subscriptions, fan-out, reconnection and authentication — and needs on-call engineers when every user opens the app at market open.

How it works

  1. 1

    Normalise the feed

    Your feed handler takes quotes from the exchange, liquidity provider or market data vendor and turns them into one compact payload per symbol.

  2. 2

    Publish once per symbol

    It publishes every update to a topic such as md/equities/AAPL/quote with the retain flag set, so the broker always holds the latest price for each symbol.

  3. 3

    Clients subscribe to their watchlist

    Web and mobile apps connect over secure WebSockets and subscribe to the symbols on screen; a wildcard such as md/fx/+/quote covers a whole asset class.

  4. 4

    The rest of your stack listens too

    Price-alert services, risk dashboards and back-office tools subscribe to the same topics; a shared subscription spreads the load across alert workers.

ConnectMQ

What it needs from the broker

Secure WebSockets for browsers

wss on port 8084 lets web apps speak MQTT straight from the browser, and native apps use TLS or WebSockets — no extra gateway in front of the broker.

Retained last price

One retained message per symbol means a freshly opened screen shows the current price at once instead of waiting for the next tick.

Read-only app users

Per-topic ACLs let app users subscribe to market data but never publish to it; only the feed handler’s credentials can write prices.

QoS that fits the data

Ticks go out at QoS 0 — the next price replaces the last one — while order status and account notifications use QoS 1 so they are not lost.

What you get

  • Prices that move on screen without polling
  • One publish reaches every subscribed client
  • An instant first price for every new session
  • No WebSocket fan-out server to maintain
Example topics
md/equities/{symbol}/quote      (retained)
md/fx/{pair}/quote              (retained)
md/crypto/{pair}/trade
users/{user-id}/orders
users/{user-id}/alerts

Industries that run this use case

Frequently asked questions

Is MQTT fast enough for real-time market data?

For distributing prices to web, mobile and desktop apps, yes: MQTT pushes each update to subscribers as it arrives, with very little protocol overhead. It does not replace co-location or the low-latency links that matching engines and algorithmic trading rely on — use it for the last mile to people’s screens.

MQTT vs WebSocket for streaming stock prices?

They work together. WebSocket is the connection a browser can open; MQTT on top of it adds topics, wildcards, retained last values, QoS and authentication, so you don’t design your own message protocol and fan-out logic. ConnectMQ accepts MQTT over secure WebSockets out of the box.

How do I stop app users from publishing fake prices?

Give app users credentials that may only subscribe to the market data topics, and grant publish rights to the feed handler alone. Which users may see which exchange’s data stays in your entitlement system — it decides which credentials and topics each user gets.

Build it on ConnectMQ

Start on the Free plan — no card required — connect your first devices today and upgrade when you go live.