Overview
In IoT platforms, distributed caches serve as the "hot data acceleration layer," used to cache high-frequency access data such as device online status, session information, hotspot configurations, and rate-limiting counters. In IoT scenarios, querying the online status of millions of devices, performing tens of thousands of authentication checks per second, and real-time rule matching in rule engines would all become bottlenecks if stored entirely in a database. Distributed caches like Redis and Memcached use in-memory storage and efficient data structures to reduce response times from milliseconds to microseconds, significantly improving system throughput and user experience.
The particularity of IoT caching lies in: high data update frequency (device heartbeat, status changes), uneven read/write ratio (status queries far exceed writes), some data requiring strong consistency (such as device key verification), and some tolerating eventual consistency (such as statistical counts). The cache architecture needs to design expiration policies, update strategies, and consistency mechanisms according to these characteristics.
Core application scenarios
Device Status Cache
Device online/offline status, last heartbeat time, connection node information. The access gateway writes to Redis when a device comes online and deletes or updates it when the device goes offline; dashboards, monitoring, and API queries directly read from the cache to avoid table scans. The key design is like device:status:{deviceId}, and the value includes status, lastSeen, gatewayNode, etc. To support batch queries by product or group, reverse indexes can be added or Redis Hash/Set aggregation can be used.
Session and Token Cache
Caching user JWTs and device connection credentials for fast authentication. When the API gateway receives a request, it first checks the cache to validate the Token. If found, it is allowed directly; if not, the authentication service is called. During device MQTT connection, the gateway can cache DeviceSecret verification results to reduce calls to the authentication service. Supports a Token blacklist (written when a user logs out) to achieve immediate invalidation.
Hot Configuration and Rule Cache
Configuration data such as product object models, rule engine rules, and device groups have low change frequency but are read frequently. The rule engine needs to match rules for each processed message, and querying the database each time cannot support high throughput. Load rules into Redis by product/device, and notify each node to refresh the cache via messages when rules change. A two-level structure of local cache + distributed cache can be used to further reduce the pressure on Redis.
Rate limiting and counting
API rate limiting (e.g., 100 requests per user per second), device message frequency control (anti-spam), alarm aggregation counting, etc. The combination of Redis INCR and EXPIRE can achieve sliding window rate limiting; Lua scripts ensure atomicity. With a large number of IoT devices, rate limiting keys need to be sharded by device/user to avoid single-key hotspots.
Technology selection and architecture
Redis Cluster: Official cluster solution, supporting data sharding and automatic failover, capable of supporting millions of QPS in a single cluster. Suitable as the main cache for IoT platforms.
Codis/Twemproxy: Redis proxies that provide transparent sharding and high availability, ideal for scenarios with existing Redis instances that want smooth scaling.
Memcached: Simpler KV cache with no persistence, suitable for pure caching scenarios where data loss is not critical.
Consistency between cache and database can be achieved through the "Cache Aside" pattern: on read, first check the cache, if missed then query the database and populate the cache; on write, first update the database, then delete or update the cache. IoT device status data can tolerate short-term inconsistencies, using "delayed double delete" or "asynchronous update" is sufficient.
IoT Scenario Optimization
Device status cache needs a reasonable TTL to avoid zombie data occupying memory; status of devices offline for more than N days can be separated into hot and cold storage and migrated to lower-cost storage. In high-concurrency scenarios, pay attention to cache penetration (querying non-existent data), cache breakdown (a hotspot key expiring and a surge of requests hitting the database), and cache avalanche (many keys expiring simultaneously), and can be mitigated by Bloom filters, mutex locks, random TTL, and other measures. In practice on the SimtoLink IoT platform, the cache layer is a key component supporting millions of online devices and second-level status queries.