Caso de uso

Preços ao vivo em cada tela de trading

Seu feed handler publica cada atualização de preço uma única vez, e todos os clientes web, mobile e desktop que acompanham aquele ativo a recebem via WebSockets seguros. Quem abre o app vê o último preço na hora, a partir de uma mensagem retida.

Sem cartão de crédito

Mensagem de exemplo

PUBLISH md/fx/EURUSD/quote

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

QoS 1 · TLS 8883 · PUBACK

O problema

Polling e servidores de socket próprios não escalam

Apps de corretora, cripto e fintech precisam que os preços se movam na tela no ritmo do mercado. Polling REST desperdiça banda e ainda chega atrasado; um servidor WebSocket próprio acaba reimplementando assinaturas, fan-out, reconexão e autenticação — e exige plantão quando todos os usuários abrem o app na abertura do pregão.

Como funciona

  1. 1

    Normalize o feed

    Seu feed handler recebe cotações da bolsa, do provedor de liquidez ou do fornecedor de market data e as transforma em um payload compacto por ativo.

  2. 2

    Publique uma vez por ativo

    Ele publica cada atualização em um tópico como md/equities/PETR4/quote com a flag retain, para que o broker sempre guarde o último preço de cada ativo.

  3. 3

    Clientes assinam sua watchlist

    Apps web e mobile conectam via WebSockets seguros e assinam os ativos na tela; um curinga como md/fx/+/quote cobre uma classe de ativos inteira.

  4. 4

    O resto da sua stack também escuta

    Serviços de alerta de preço, painéis de risco e ferramentas de back office assinam os mesmos tópicos; uma assinatura compartilhada divide a carga entre os workers de alerta.

ConnectMQ

O que ele precisa do broker

WebSockets seguros para o navegador

wss na porta 8084 permite que apps web falem MQTT direto do navegador, e apps nativos usam TLS ou WebSockets — sem gateway extra na frente do broker.

Último preço retido

Uma mensagem retida por ativo faz uma tela recém-aberta mostrar o preço atual na hora, sem esperar o próximo tick.

Usuários somente leitura

ACLs por tópico deixam os usuários do app assinar market data, mas nunca publicar; só as credenciais do feed handler podem escrever preços.

QoS adequado a cada dado

Ticks vão com QoS 0 — o próximo preço substitui o anterior —, enquanto status de ordens e avisos de conta usam QoS 1 para não se perderem.

O que você ganha

  • Preços que se movem na tela sem polling
  • Uma publicação chega a todos os clientes inscritos
  • Primeiro preço instantâneo em cada nova sessão
  • Nenhum servidor de fan-out WebSocket para manter
Topics de exemplo
md/equities/{symbol}/quote      (retained)
md/fx/{pair}/quote              (retained)
md/crypto/{pair}/trade
users/{user-id}/orders
users/{user-id}/alerts

Setores que usam este caso

Perguntas frequentes

MQTT é rápido o suficiente para dados de mercado em tempo real?

Para distribuir preços a apps web, mobile e desktop, sim: o MQTT empurra cada atualização aos assinantes assim que ela chega, com pouquíssimo overhead de protocolo. Ele não substitui co-location nem os links de baixa latência usados por motores de casamento de ordens e trading algorítmico — use-o na última milha até a tela do usuário.

MQTT ou WebSocket para streaming de cotações?

Os dois trabalham juntos. WebSocket é a conexão que o navegador consegue abrir; o MQTT sobre ela adiciona tópicos, curingas, últimos valores retidos, QoS e autenticação, para você não precisar criar seu próprio protocolo de mensagens e lógica de fan-out. O ConnectMQ aceita MQTT sobre WebSockets seguros nativamente.

Como impedir que usuários do app publiquem preços falsos?

Dê aos usuários do app credenciais que só podem assinar os tópicos de market data e conceda direito de publicação apenas ao feed handler. Quem pode ver os dados de qual bolsa continua sendo decidido pelo seu sistema de entitlements — ele define as credenciais e os tópicos de cada usuário.

Construa isso no ConnectMQ

Comece no plano Free — sem cartão de crédito —, conecte hoje seus primeiros dispositivos e faça upgrade quando entrar em produção.