3.2.6. Control the Frequency of Message Delivery to the Device¶
| ID | Priority | Best Practice |
|---|---|---|
| BP 3.2.6.1 | Required | Target messages to relevant devices |
| BP 3.2.6.2 | Highly Recommended | Implement retry and backoff logic to support throttling by device type |
Architecture Notes - BP 3.2.6.1 - Target messages to relevant devices¶
Devices receive information from shadow updates, or from messages published to topics they subscribe to. Some data are relevant only to specific devices. In those cases, design your workload to send messages to relevant devices only, and to remove any data that is not relevant to those devices.
Recommendation 3.2.6.1.1 - Preprocess data to support the specific needs of the device
Use AWS Lambda to pre-process the data and hone-in specifically to attributes and variables that are needed by the device to act upon
Architecture Notes - BP 3.2.6.2 - Implement retry and backoff logic to support throttling by device type¶
Retry and backoff logic should be implemented in a controlled manner so that when you need to alter throttling settings per device type, you can easily do it. Using data storage of any chosen kind gives you flexibility on what data to publish down to the device.
Recommendation 3.2.6.2.1 - Use storage mechanisms that enable retry mechanisms
- Using DynamoDB, you can hold data in key value format where device ID is the key. Retry logic can be applied to only certain device ID’s.
- Using Amazon Relational Database Service (Amazon RDS), you have the flexibility to use a variety of database engines. The retry messages can have new real-time data augmented with historic data from previous device interactions stored in RDS.
- AWS IoT Events provides state machines with built-in timers to hold back data and retry based on timers.