How We Replaced HTTP Polling with MQTT for Real‑Time, Low‑Latency Messaging

Background and Problem with HTTP Polling

In an era demanding real‑time interaction, users tolerate little latency for messages, notifications, and data updates. Our product initially used a straightforward HTTP polling scheme to keep client‑server data in sync, but growing user numbers and business complexity exposed serious drawbacks.

Initial HTTP Polling Solution

Mode : Client periodically requests the server to check for new messages.

Tech stack : Nginx + Spring Boot + Redis + MySQL.

Advantages : Simple to implement, highly compatible, stateless on the server, quick to launch.

Issues Encountered

Massive ineffective requests: 99% of polls return “no data”, wasting DB and network resources.

Latency hard to reduce: 5‑second interval yields ~2.5 s average latency; 1‑second interval overloads the server.

Bandwidth and power waste: HTTP header overhead and unstable mobile networks degrade user experience.

Lack of push capability: Server cannot proactively notify clients, making many scenarios awkward.

Why MQTT?

After evaluating WebSocket, Server‑Sent Events (SSE), and MQTT, we selected MQTT for its lightweight protocol and robust publish/subscribe model.

Technical Comparison

WebSocket : Full‑duplex TCP, low latency, but requires custom message protocol, heartbeat, and reconnection logic.

SSE : One‑way HTTP push with built‑in reconnection and ordered messages, unsuitable for bidirectional interaction.

MQTT : Publish/subscribe, ultra‑lightweight (2‑byte header), QoS levels, native persistence, but needs a separate broker.

Reasons for Selecting MQTT

Fits weak networks and mobile scenarios: tiny header size adapts well to unstable connections.

Decouples publishing from subscribing: server only publishes, unaware of subscriber details.

Flexible QoS: supports “best effort” to “exactly once” reliability as needed.

Mature ecosystem: high‑performance brokers like EMQX and HiveMQ, abundant client libraries.

Implementation Details

Architecture Diagram

业务服务器 (Publisher) ---> MQTT Broker (EMQX) ---> 客户端 (Subscriber)
        |                         |
        |                         |
        v                         v
      鉴权中心 -----------------> Token 校验与 ACL 控制

Core Components

MQTT Broker (EMQX cluster)

Maintains TCP long connections, routes and distributes messages.

Provides QoS, persistent sessions, and offline message support.

Business Server (Publisher)

Spring Boot service that publishes messages to specific topics.

Client (Subscriber)

Web: MQTT.js Mobile: Eclipse Paho / MQTT-Client Subscribes to topics such as user/${userId}/#.

Auth Center

JWT/Redis based HTTP authentication and ACL control for EMQX.

Migration Challenges

Smooth migration: dual‑track approach, prioritize MQTT, fallback to HTTP polling for compatibility.

Connection loss handling: automatic reconnection with proper Keep‑Alive detection.

Topic design examples: app/chat/{roomId} – chat room messages user/{userId}/order – user order updates system/announcement – system broadcasts

Security isolation: precise ACL to prevent cross‑user subscription or topic injection attacks.

Performance and Monitoring

Key Metrics

Latency reduced from average 2.5 s to ~50 ms.

API request volume dropped >95 %.

Database QPS decreased dramatically.

Server count cut by 30 %; EMQX cost far lower than saved resources.

High Availability & Scaling

Clustered EMQX nodes scale horizontally to support millions of connections.

Persistence integrated with Redis/Kafka for message archiving and big‑data analysis.

Monitoring & alerts via Prometheus + Grafana for connection count, message throughput, and disconnect rate.

Practical Experience and Pitfalls

QoS Strategy : Avoid using QoS 2 everywhere; most business scenarios work well with QoS 1 plus idempotent handling.

Message Backlog : Set expiration for offline users to prevent excessive accumulation.

Mobile Keep‑Alive : Mobile OS may kill long connections; combine APNs/FCM wake‑up with MQTT to deliver missed messages.

Security Hardening : End‑to‑end TLS encryption, DDoS protection configurations, and limits on client connections and request rates.

Future Outlook

Integrate with Kafka as an enterprise‑level event bus.

Adopt serverless MQTT for on‑demand scaling and cost reduction.

Deploy MQTT brokers at edge nodes to further lower latency.

Combine MQTT with WebRTC for audio/video real‑time transmission when needed.

Conclusion

Transitioning from HTTP polling to MQTT represents a shift from a request‑response paradigm to an event‑driven architecture, delivering lower latency, higher concurrency, and better system decoupling, making MQTT the optimal choice for our real‑time communication needs.