Electronic shelf labels (ESLs), also known as digital price tags, replace paper labels with networked electronic screens in retail stores. This solution uses ApsaraMQ for MQTT to push price updates and collect device status across stores in real time.
How it works
The system connects four layers: edge devices in stores, an MQTT messaging layer, backend processing services, and persistent storage.
Component roles
| Layer | Component | Role |
|---|---|---|
| Edge | Digital price tags | Electronic screens that display pricing. Connect to smart APs over Bluetooth or ZigBee. |
| Edge | Smart access points (APs) | Network devices (such as smart routers) that support application programming. Aggregate tag data, relay commands, and connect to ApsaraMQ for MQTT over the public internet with SSL/TLS encryption. |
| Messaging | ApsaraMQ for MQTT | MQTT broker that handles bidirectional messaging between smart APs and backend services. Scales to millions of concurrent connections with millisecond-level push latency. |
| Messaging | ApsaraMQ for RocketMQ | Cloud-side message queue that bridges the MQTT broker with backend services. Handles reliable message routing, buffering, and delivery to consumers. |
| Backend | Digital price tag management service | Deployed on Elastic Compute Service (ECS). Manages price-change tasks, tracks tag status, and orchestrates the update workflow. |
| Storage | ApsaraDB for RDS | Persists task state, such as price-change progress and completion status. |
| Storage | Simple Log Service (SLS) | Stores price tag report data and operation logs for auditing and tracing. |
Data flows
The system supports two primary data flows: status reporting (device to cloud) and display updates (cloud to device).
Status reporting
Each digital price tag periodically exchanges data with its smart AP over Bluetooth or ZigBee, reporting its current display status, power capacity, and other information.
The smart AP aggregates the reported data and publishes an MQTT message to the ApsaraMQ for MQTT broker.
The MQTT broker routes the message to an ApsaraMQ for RocketMQ topic.
The digital price tag management service consumes the message from ApsaraMQ for RocketMQ, processes the tag status, and writes the data to SLS.
Display updates
The digital price tag management service publishes a price-change command to ApsaraMQ for RocketMQ.
ApsaraMQ for MQTT routes the command to the target smart AP as an MQTT message.
The smart AP receives the command and queues the update task locally.
On the next polling cycle, the digital price tag retrieves the new display content from the smart AP and updates its screen.
The smart AP confirms completion by publishing an MQTT acknowledgment back to the management service.
The management service logs the task result to SLS for tracing.
MQTT concepts
MQTT protocol
Message Queuing Telemetry Transport (MQTT) is an industry-standard, lightweight messaging protocol designed for Internet of Things (IoT) and mobile Internet. ApsaraMQ for MQTT is a fully managed MQTT broker service built on this protocol.
Broker and clients
The MQTT broker is the server-side node that receives, routes, and forwards messages. In this solution, ApsaraMQ for MQTT acts as the broker.
An MQTT client is any device or application that connects to the broker to publish or subscribe to messages. In this solution, each smart AP runs an MQTT client.
P2P messages
A P2P message is an ApsaraMQ for MQTT feature that delivers a message directly to a specific MQTT client. The recipient does not need to subscribe to a topic. This makes P2P messages well suited for targeted price-change commands. For details, see P2P messaging model.
Design guidance
SDK and protocol selection
Smart APs connect through the MQTT protocol. In a typical deployment, one application may serve hundreds of offline stores, each equipped with several APs. As the business grows, each new store adds several APs, and MQTT handles this scale efficiently with persistent, low-overhead connections.
The digital price tag management service, deployed on the cloud, connects through the ApsaraMQ for RocketMQ SDK for reliable backend message processing.
Client ID structure
Every MQTT client must have a globally unique client ID. A client ID consists of two parts joined by the @@@ separator. The maximum total length is 64 characters.
| Part | Description | Example |
|---|---|---|
| Prefix (Group ID) | Registered in the ApsaraMQ for MQTT console. Classify Group IDs by platform vendor or channel to simplify troubleshooting. For example, use different Group IDs for different industries or batches, or for different client versions. | GID_pricetag_east |
| Suffix (Device ID) | Generated by the application. Use a unique device identifier such as the smart AP's MAC address. | MAC_AA_BB_CC_DD_EE_FF |
Example client ID: GID_pricetag_east@@@MAC_AA_BB_CC_DD_EE_FF
For more information about client IDs, see Terms.
Topic hierarchy design
MQTT topics follow a hierarchical directory-tree structure with parent topics and subtopics. The total topic length, including all levels, cannot exceed 64 characters.
| Topic level | Description | Registration |
|---|---|---|
| Parent topic | The first level of the topic tree. Equivalent to a namespace. | Must be registered in the ApsaraMQ for MQTT console. |
| Subtopic | Any level below the parent topic. | No registration required. Specify as needed. |
Design rules:
Separate task types by parent topic. Use distinct parent topics for price-change commands and status reports. This isolates traffic and simplifies access control.
Use P2P messages for targeted commands. P2P messages bypass subscription matching and deliver directly to the specified client. This reduces topic management overhead and avoids unnecessary message fan-out. See P2P messaging model.
For more information about topics, see Terms. For the full MQTT topic specification, see the MQTT v3.1.1 specification. For general product documentation, see ApsaraMQ for MQTT.
Message parameters
Price-change commands require real-time delivery. Configure the smart AP's MQTT connection with the following parameters. These settings prevent the AP from replaying stale commands from previous sessions.
| Parameter | Value | Rationale |
|---|---|---|
| CleanSession | true | Discards any queued messages from a previous session when the smart AP reconnects. This prevents the AP from running outdated price changes. |
| QoS | 1 (at least once) | Guarantees that every price-change command is delivered at least once. The tradeoff is that duplicates may occur, so the smart AP must deduplicate incoming messages. |
Why QoS 1? MQTT defines three QoS levels:
| QoS level | Guarantee | Tradeoff |
|---|---|---|
| 0 | At most once (fire and forget) | Fastest, but messages may be lost. Not suitable for price changes. |
| 1 | At least once | Reliable delivery with possible duplicates. The smart AP handles deduplication. |
| 2 | Exactly once | Strongest guarantee, but requires a four-step handshake that adds latency. Unnecessary overhead for this use case. |
The smart AP should perform deduplication and timeliness verification on all received messages to handle QoS 1 retransmissions and discard expired commands.
For more information about CleanSession and QoS, see Terms.
Solution highlights
Elastic scalability. ApsaraMQ for MQTT provides infinitely scalable message transmission capability, allowing you to increase the number of smart terminals without compromising system performance.
Millisecond-level push latency. ApsaraMQ for MQTT supports information pushing in milliseconds for millions of devices, with an even smaller latency for display updates of digital price tags.
Standards-based portability. Built on the MQTT v3.1.1 standard protocol, this architecture is portable and adaptable. Apply the same design to digital signage, multimedia displays, or any IoT use case with similar update-and-report patterns.
End-to-end encryption. All communication between smart APs and ApsaraMQ for MQTT uses SSL/TLS encryption, protecting pricing data in transit.
High availability. All service components are deployed in a highly available configuration to minimize downtime.
What's next
Download the ApsaraMQ for MQTT SDK for smart AP integration.
Download the ApsaraMQ for RocketMQ SDK for backend service development.
Learn about P2P messaging for targeted device communication.
Review ApsaraMQ for MQTT terminology for client ID, topic, QoS, and CleanSession details.