Protocol selection is one of the most impactful architectural decisions in an IoT product. The wrong protocol increases power consumption, bandwidth costs, and implementation complexity — all of which compound at scale.
MQTT: Publish-Subscribe for IoT
MQTT (Message Queuing Telemetry Transport) was designed for constrained devices and unreliable networks. It uses a publish-subscribe model with a central broker, making it ideal for many-to-many IoT deployments.
- Very low overhead — 2-byte fixed header minimum.
- Persistent sessions survive network drops.
- QoS levels (0, 1, 2) let you trade reliability for performance.
- Natively supported by AWS IoT Core, Azure IoT Hub, Mosquitto.
HTTP: Request-Response for IoT
HTTP is familiar and universally supported, but it was designed for the web — not for battery-powered sensors reporting every 5 seconds.
- High overhead per request (headers, TCP handshake).
- Request-response model requires polling for downstream commands.
- Easy to debug and test with standard tools.
- Best for infrequent data uploads from powerful devices.
When to Choose MQTT
- High-frequency sensor data (> once per minute).
- Battery-powered or cellular devices where bandwidth costs money.
- Many devices reporting to a central platform.
- Bidirectional communication (device receives commands from cloud).
When to Choose HTTP
- Infrequent, large data uploads (e.g. daily log files).
- Simple webhook-style integrations with existing REST APIs.
- Devices with stable power and reliable WiFi.
- Teams with no MQTT broker infrastructure.
FoogleTech's IoT team in Surat has designed communication architectures for 40+ IoT products. The answer is almost always MQTT for telemetry and HTTP for configuration/OTA. Contact us if you need help designing yours.