Redis Agent Skills là bộ kỹ năng giúp AI coding agent hiểu và áp dụng các Redis best practice khi thiết kế data model, viết code, review hệ thống và xử lý các vấn đề liên quan đến Redis Cluster.

Các công cụ như Codex, Claude Code hay Cursor hiện có thể viết code rất nhanh. Tuy nhiên, một đoạn Redis code chạy được chưa chắc đã phù hợp để sử dụng trên production. AI vẫn có thể lựa chọn sai data structure, bỏ qua TTL, tạo quá nhiều network round trip hoặc đề xuất những operation không tương thích với Redis Cluster.

Những sai sót thường gặp bao gồm:

• Không thiết lập TTL cho dữ liệu cache.
• Gọi Redis liên tục trong vòng lặp thay vì sử dụng pipelining.
• Dùng KEYS * trên database có hàng triệu key.
• Tạo ra big key hoặc hot key.
• Chọn data structure chưa phù hợp.
• Để key tăng trưởng không giới hạn.
• Thực hiện multi-key operation không tương thích với Redis Cluster.
• Không xử lý đúng timeout, retry hoặc partial failure.

Trong bài viết We built an Agent Skill so AI writes Redis code the way Redis experts would, Redis chỉ ra rằng AI agent thường sử dụng những pattern cũ từ dữ liệu huấn luyện, bỏ qua các tính năng Redis mới và không chủ động cảnh báo về các vấn đề chỉ xuất hiện khi hệ thống chạy ở quy mô production.

Để thu hẹp khoảng cách đó, Redis đã xây dựng một bộ Redis Agent Skills chính thức.

Ý tưởng khá đơn giản: thay vì hy vọng AI đã biết mọi Redis best practice, chúng ta cài cho AI một bộ kiến thức và hướng dẫn do chính Redis xây dựng.

Sau khi cài đặt, AI coding agent có thể hoạt động như một “Redis expert” hỗ trợ:

• Hỏi đáp về Redis.
• Lựa chọn data structure.
• Thiết kế key và TTL.
• Review code sử dụng Redis.
• Phân tích Redis Cluster.
• Phát hiện các Redis anti-pattern phổ biến.

---

Agent Skill là gì?

Agent Skill là một tập hợp hướng dẫn và tài nguyên giúp AI thực hiện tốt một nhóm công việc chuyên biệt.

Khi AI nhận được một yêu cầu phù hợp, Skill tương ứng sẽ được đưa vào context để cung cấp thêm best practice, checklist và quy trình xử lý.

Có thể hình dung Redis Skill như một cuốn cẩm nang dành cho AI:

Yêu cầu của developer
          ↓
    AI coding agent
          ↓
  Redis Agent Skills
          ↓
Pattern + checklist + guardrail
          ↓
Câu trả lời hoặc code đề xuất

Skill không làm model thông minh hơn theo nghĩa tổng quát. Nó cung cấp cho model đúng kiến thức vào đúng thời điểm.

---

Redis Agent Skills cung cấp những gì?

Redis không đóng gói toàn bộ kiến thức vào một file duy nhất. Repository Redis Agent Skills chia kiến thức thành nhiều Skill nhỏ, mỗi Skill tập trung vào một nhóm vấn đề riêng.

redis-core

Tập trung vào các kiến thức cốt lõi:

• Redis data structures.
• Key naming.
• Memory và TTL.
• Atomic operations.
• JSON và Hash.
• Streams và Pub/Sub.

redis-connections

Tập trung vào cách ứng dụng kết nối và giao tiếp với Redis:

• Connection pooling.
• Multiplexing.
• Pipelining.
• Client-side caching.
• Timeout.
• Slow commands.

redis-clustering

Tập trung vào Redis Cluster:

• Hash slot.
• Hash tag.
• Multi-key operation.
• Tránh lỗi CROSSSLOT.
• Đọc dữ liệu từ replica.

redis-observability

Hỗ trợ việc theo dõi và phân tích Redis:

• Các metric quan trọng từ INFO.
• Phân tích SLOWLOG.
• Sử dụng MEMORY DOCTOR.
• Query profiling.
• Redis Insight.

Repository còn có các Skill dành cho Redis Search, vector similarity search, semantic caching, security, authentication, TLS, ACL và agent memory.

Nhờ việc chia nhỏ này, agent chỉ cần load phần kiến thức phù hợp với yêu cầu hiện tại, thay vì đưa toàn bộ tài liệu Redis vào context cho mọi câu hỏi.

---

Redis Skill thay đổi cách AI làm việc với Redis như thế nào?

Theo Redis, bộ Skill cung cấp cho agent bốn nhóm kiến thức chính.

Các Redis pattern hiện tại

Agent được hướng dẫn về những pattern phổ biến như:

• Caching.
• Rate limiting.
• Session management.
• Vector search.
• Semantic caching.
• Agent memory.
• Pub/Sub.
• Streams.

Chọn đúng data structure

Agent không chỉ tìm một Redis command có thể giải quyết yêu cầu mà còn cân nhắc data structure phù hợp:

• String.
• Hash.
• Set.
• Sorted Set.
• JSON.
• Stream.
• Vector Set.

Guardrail chống anti-pattern

Skill giúp agent chủ động phát hiện các vấn đề như:

• Sử dụng KEYS trong production path.
• Key tăng trưởng không giới hạn.
• Lưu value quá lớn.
• Tạo quá nhiều network round trip.
• Sử dụng multi-key operation không phù hợp với Redis Cluster.

Production-aware defaults

Agent được hướng dẫn cân nhắc những yếu tố thường bị bỏ qua khi code chỉ mới chạy trên local:

• Connection pooling.
• Pipelining.
• Timeout.
• Cluster compatibility.
• Error handling.
• Retry behavior.
• Partial failure.

Điểm quan trọng là Redis Skill không chỉ giúp AI trả lời:

Code này có chạy không?

Nó còn giúp AI xem xét câu hỏi quan trọng hơn:

Code này có chạy tốt, có thể scale và đủ an toàn trên production không?

---

Cài đặt Redis Agent Skills

Repository Redis Agent Skills hỗ trợ nhiều AI coding agent và tuân theo định dạng Agent Skills mở.

Cài bằng Agent Skills CLI

Cách nhanh nhất là sử dụng Agent Skills CLI:

npx skills add redis/agent-skills

CLI sẽ cho phép lựa chọn Skill và AI agent cần cài đặt.

Sau khi cài xong, các Skill sẽ tự động được sử dụng khi agent phát hiện một task liên quan đến Redis.

Ví dụ:

What Redis data structure should I use for a leaderboard?

Help me optimize this Redis query.

Review the Redis connection handling in this project.

Cài cho Claude Code

Có thể cài Redis Skills dưới dạng Claude Code plugin:

/plugin marketplace add redis/agent-skills
/plugin install redis-development@redis

Cài cho Cursor

Trong cửa sổ chat của Cursor, chạy:

/add-plugin redis

---

Thử Redis Skill với một bài toán thực tế

Để kiểm tra Redis Skill, tôi sử dụng Codex với một bài toán liên quan đến trạng thái hoạt động của hàng triệu device.

Bài toán

Hệ thống cần lưu:

• Trạng thái online của device.
• Thời điểm hoạt động gần nhất.
• Hỗ trợ hàng triệu device.
• Có thể tìm hoặc đếm các device hoạt động trong 10 phút gần nhất.
• Chạy trên Redis Cluster.

Thay vì chỉ hỏi nên sử dụng Redis Hash hay String, tôi cung cấp thêm yêu cầu để agent có đủ context phân tích data model.

Prompt sử dụng

I need to store the online status and last-seen timestamp
for several million devices.

Review the requirements and recommend an appropriate Redis
data structure.

Also explain:

- Key structure
- TTL strategy
- Memory considerations
- Cluster compatibility
- How to query devices that were active in the last 10 minutes
- Possible big-key and hot-key risks

Đề xuất chính của Codex

Codex đề xuất sử dụng Sorted Set làm index chính:

• member: device ID.
• score: thời điểm lastSeen dưới dạng Unix timestamp.
• Trạng thái online được suy ra từ thời điểm hoạt động gần nhất.

Ví dụ:

ZADD device:last_seen:42 1721458800 device_abc123

Một device được xem là online khi:

last_seen >= current_time - 600 seconds

Cách tiếp cận này tránh việc phải lưu một boolean riêng như:

online=true

Boolean có thể trở nên không chính xác nếu quá trình cập nhật trạng thái bị gián đoạn. Trong khi đó, lastSeen vừa lưu được thời điểm hoạt động cuối cùng, vừa có thể dùng để suy ra trạng thái online.

---

Không sử dụng một Sorted Set duy nhất

Một điểm đáng chú ý là Codex không đề xuất đưa toàn bộ hàng triệu device vào một key:

device:last_seen

Một key duy nhất như vậy có thể trở thành:

• Big key.
• Hot key.
• Điểm tập trung toàn bộ traffic ghi.
• Nút thắt khi chạy range query.
• Nguyên nhân khiến memory phân bố không đều giữa các Redis Cluster node.
• Một key khó xóa hoặc cleanup khi có hàng triệu member.

Thay vào đó, Codex đề xuất chia dữ liệu thành nhiều shard:

device:last_seen:00
device:last_seen:01
device:last_seen:02
...
device:last_seen:255

Shard có thể được xác định bằng một hàm hash ổn định:

shard = crc32(device_id) % 256

Mỗi lần cập nhật, ứng dụng tính shard từ device ID rồi ghi vào Sorted Set tương ứng:

ZADD device:last_seen:42 1721458800 device_abc123

Cách làm này giúp phân phối dữ liệu và traffic ra nhiều Redis Cluster slot, thay vì tập trung toàn bộ workload vào một node.

---

Chiến lược TTL và dọn dẹp dữ liệu

Redis không hỗ trợ TTL riêng cho từng member trong Sorted Set.

Codex đề xuất định kỳ xóa các member có score cũ bằng ZREMRANGEBYSCORE:

ZREMRANGEBYSCORE device:last_seen:42 -inf 1721372400

Ví dụ, hệ thống có thể xóa các device không hoạt động trong:

• 24 giờ.
• 7 ngày.
• Hoặc một retention window phù hợp với nghiệp vụ.

Việc cleanup nên được thực hiện liên tục theo những batch nhỏ, thay vì đợi dữ liệu tích lũy rồi chạy một job lớn để xóa hàng triệu member cùng lúc.

Nếu hệ thống cần tra cứu trực tiếp từng device với tần suất cao, Codex đề xuất có thể bổ sung một key riêng:

device:<device_id>:status

Ví dụ:

HSET device:abc123:status last_seen 1721458800
EXPIRE device:abc123:status 86400

Tuy nhiên, phương án này tạo dữ liệu trùng lặp giữa status key và Sorted Set.

Do đó, chỉ nên bổ sung status key khi nhu cầu point lookup đủ lớn để bù lại:

• Chi phí memory.
• Chi phí ghi hai nơi.
• Rủi ro dữ liệu không đồng bộ.
• Logic xử lý partial failure.

---

Truy vấn device hoạt động trong 10 phút gần nhất

Với từng shard, ứng dụng có thể chạy:

ZRANGEBYSCORE device:last_seen:42 1721458200 +inf

Trong đó:

1721458200 = current_time - 600 seconds

Nếu chỉ cần số lượng device active, nên sử dụng:

ZCOUNT device:last_seen:42 1721458200 +inf

Ứng dụng có thể chạy query song song trên các shard, sau đó:

• Cộng kết quả nếu chỉ cần tổng số lượng.
• Ghép kết quả nếu cần danh sách device.
• Phân trang nếu số lượng kết quả lớn.

Một điểm hợp lý trong câu trả lời là Codex phân biệt giữa hai nhu cầu:

Cần số lượng  → ZCOUNT
Cần danh sách → ZRANGEBYSCORE

Nếu dashboard chỉ cần hiển thị số device online, sử dụng ZCOUNT sẽ phù hợp hơn việc tải toàn bộ device ID về ứng dụng.

---

Khả năng tương thích với Redis Cluster

Mỗi Sorted Set shard là một key độc lập nên các thao tác trên từng shard có thể được phân phối trên Redis Cluster.

Codex cũng cảnh báo không nên đặt cùng một hash tag cho tất cả shard:

{device}:last_seen:00
{device}:last_seen:01
{device}:last_seen:02

Trong Redis Cluster, phần nằm trong {} được dùng để xác định hash slot.

Nếu tất cả key sử dụng cùng hash tag {device}, chúng sẽ được đưa vào cùng một slot. Điều này làm mất mục đích phân tán dữ liệu thành nhiều shard.

Các key nên được đặt theo dạng:

device:last_seen:00
device:last_seen:01
device:last_seen:02

để Redis có thể phân phối chúng qua nhiều slot.

Tất nhiên, cách đặt key cuối cùng vẫn phải phụ thuộc vào các operation mà ứng dụng cần thực hiện. Nếu hệ thống cần một multi-key operation atomic, các key liên quan có thể phải nằm trong cùng slot.

---

Big-key và hot-key risk

Ngoài việc lựa chọn data structure, Codex còn chủ động xem xét các rủi ro khi hệ thống scale.

Big key

Một Sorted Set chứa hàng triệu member có thể gây ra:

• Range query tốn nhiều tài nguyên.
• Cleanup dữ liệu chậm.
• Xóa key mất nhiều thời gian.
• Memory phân bố không đều.
• Tăng latency trên node đang giữ key.

Việc chia dữ liệu thành nhiều shard giúp giảm kích thước của mỗi key.

Hot key

Hot key có thể xuất hiện khi:

• Tất cả device cùng cập nhật một key.
• Một tenant tạo ra phần lớn traffic.
• Dashboard liên tục truy vấn toàn bộ danh sách device active.
• Cleanup job liên tục hoạt động trên cùng một key lớn.

Một số hướng giảm rủi ro được Codex đề xuất:

• Shard theo hash của device ID.
• Batch hoặc pipeline các lệnh cập nhật.
• Dùng ZCOUNT nếu chỉ cần số lượng.
• Phân trang khi lấy danh sách.
• Cleanup liên tục thay vì chạy một job khổng lồ.
• Cân nhắc đọc từ replica nếu chấp nhận được dữ liệu trễ.

---

Tóm tắt phương án Codex đề xuất

Data structure: Sharded Sorted Sets
Member:         Device ID
Score:          Last-seen timestamp
Online status:  Suy ra từ khoảng thời gian
Cleanup:        ZREMRANGEBYSCORE
Active count:   ZCOUNT
Active list:    ZRANGEBYSCORE
Distribution:   Hash device ID thành nhiều shard

---

Điều tôi thấy hữu ích từ câu trả lời

Việc Codex chọn Sorted Set không phải điều quá bất ngờ. Đây là một data structure phù hợp khi cần sắp xếp và truy vấn theo thời gian.

Giá trị thực sự nằm ở việc agent không dừng lại ở câu trả lời:

Hãy sử dụng Sorted Set.

Redis Skill giúp Codex xem xét đồng thời nhiều khía cạnh production:

• Không lưu boolean online có thể trở nên stale.
• Không đưa hàng triệu device vào một key duy nhất.
• Hiểu rằng Sorted Set không hỗ trợ TTL trên từng member.
• Đề xuất cleanup dữ liệu theo score.
• Xem xét Redis Cluster slot distribution.
• Cảnh báo hash tag sai có thể đưa tất cả shard về cùng một slot.
• Phân biệt truy vấn count và truy vấn lấy danh sách.
• Nhắc đến pipelining, pagination, big key và hot key.

Nói cách khác, Codex đã biến một câu hỏi lựa chọn data structure thành một buổi review data model tương đối đầy đủ.

---

Những điểm vẫn cần kiểm chứng

Redis Skill giúp đưa ra một thiết kế ban đầu và một checklist tốt hơn. Tuy nhiên, câu trả lời của AI không thể thay thế benchmark và phân tích workload thực tế.

Trước khi áp dụng phương án này, tôi vẫn cần xác minh:

• Tổng số device.
• Tần suất cập nhật của từng device.
• Tổng số write mỗi giây.
• Số lượng device active trung bình trong 10 phút.
• Số shard phù hợp.
• Memory thực tế trên mỗi member.
• Chi phí chạy query trên tất cả shard.
• Chi phí merge kết quả ở phía client.
• Retention window thực tế.
• Tần suất cleanup.
• Yêu cầu consistency giữa Sorted Set và status key.
• Mức độ stale data được chấp nhận nếu đọc từ replica.

Số shard 256 trong câu trả lời chỉ nên được xem như một ví dụ. Con số phù hợp cần được lựa chọn dựa trên workload, cluster topology và kết quả benchmark.

Redis Skill giúp agent đặt ra những câu hỏi đúng, nhưng quyết định cuối cùng vẫn phải dựa trên dữ liệu thực tế của hệ thống.

---

Redis Skill còn có thể được sử dụng như thế nào?

Ngoài việc hỗ trợ thiết kế data model, Redis Skill còn có thể được dùng cho nhiều công việc khác.

Review Redis code đang có

Có thể yêu cầu agent review Redis code trong project để phát hiện các vấn đề về production readiness:

Review this Redis-related code for production readiness.

Identify the most important problems and recommend improvements.

Classify each finding as:

- Critical
- Warning
- Improvement

For each finding, include evidence, impact, and a recommended fix.

Phân tích Redis Cluster đang chạy

Redis Skill cũng có thể hỗ trợ phân tích output từ các command như INFO, CLUSTER INFO, SLOWLOG hoặc MEMORY DOCTOR.

Prompt có thể sử dụng:

Review these Redis Cluster diagnostic outputs.

Identify the most important health, performance,
memory, replication, latency and cluster-distribution issues.

For every finding, provide:

- Severity
- Evidence
- Possible impact
- Commands to verify
- Safe remediation options

Clearly separate confirmed findings from hypotheses.
Do not recommend destructive commands.

Redis Skill không tự động nhìn thấy cluster đang chạy. Người dùng vẫn phải cung cấp output đã được loại bỏ thông tin nhạy cảm hoặc cho agent quyền truy cập thông qua một tool phù hợp.

---

Từ Redis Skill chính thức đến Redis Expert riêng của team

Redis Agent Skills cung cấp kiến thức chung do Redis xây dựng. Tuy nhiên, mỗi hệ thống lại có kiến trúc, convention và yêu cầu khác nhau.

Để xây dựng một Redis expert thực sự phù hợp với dự án, team có thể bổ sung thêm context như:

• Phiên bản Redis đang sử dụng.
• Redis standalone, Sentinel hay Cluster.
• Client library và version.
• Quy định về connection pool.
• Timeout mặc định.
• Retry policy.
• Key naming convention.
• Default TTL.
• Giới hạn kích thước key và value.
• Serialization format.
• Các command bị hạn chế trên production.
• Quy trình cleanup.
• Quy trình failover.
• Checklist review code.
• Các incident Redis từng xảy ra.

Khi đó, Redis expert của team có thể được hình thành từ ba lớp:

Kiến thức chính thức từ Redis
                +
Best practice và guardrail của team
                +
Kiến trúc và lịch sử incident của hệ thống
                =
Redis Expert riêng của team

Skill có thể được lưu cùng source code và quản lý bằng version control.

Khi team thay đổi kiến trúc hoặc phát hiện một anti-pattern mới, nội dung Skill cũng có thể được cập nhật và chia sẻ lại.

---

Redis Skill không thay thế điều gì?

Redis Skill có thể làm cho AI agent hữu ích hơn, nhưng không nên xem nó như một hệ thống tự động đưa ra quyết định production.

Nó không thay thế:

• Redis monitoring.
• Alerting.
• Load testing.
• Capacity planning.
• Benchmark trên workload thực tế.
• Incident investigation.
• Code review của engineer.
• Việc xác minh khuyến nghị trước khi áp dụng.

Chất lượng phân tích còn phụ thuộc vào:

• Chất lượng và độ mới của Skill.
• Code, metric và log được cung cấp.
• Context về hệ thống.
• Phiên bản Redis.
• Client library.
• Cách developer viết prompt.
• Khả năng agent nhận diện đúng Skill.

Một Skill tốt không nên khiến AI tự tin hơn khi thiếu dữ liệu.

Ngược lại, Skill nên hướng dẫn AI phân biệt rõ:

Confirmed finding:
Được xác nhận trực tiếp từ code, log hoặc metric.

Hypothesis:
Một nguyên nhân có thể xảy ra nhưng chưa đủ bằng chứng.

Missing information:
Thông tin cần bổ sung trước khi đưa ra kết luận.

---

Kết luận

Điểm thú vị của Redis Agent Skills không phải là biến AI thành một chuyên gia biết mọi thứ về Redis.

Giá trị thực sự nằm ở việc đưa kiến thức chuyên môn, production pattern và guardrail vào context đúng lúc AI đang làm việc với Redis.

Trong ví dụ về trạng thái online của hàng triệu device, Codex không chỉ đề xuất sử dụng Sorted Set. Nó còn chủ động xem xét sharding, cleanup, memory, cluster distribution, big key, hot key và cách query dữ liệu hiệu quả.

Đây chính là giá trị mà tôi mong đợi từ một Skill: không chỉ trả lời câu hỏi trực tiếp, mà còn mang theo checklist và kinh nghiệm của một chuyên gia vào quá trình phân tích.

Redis Skill không loại bỏ nhu cầu phải hiểu hệ thống. Nhưng nó có thể trở thành một reviewer bổ sung, giúp phát hiện sớm những vấn đề mà developer dễ bỏ qua.

Thay vì mỗi lần gặp một vấn đề Redis lại bắt đầu tìm kiếm tài liệu từ đầu, chúng ta có thể mang tài liệu, best practice và kinh nghiệm đó vào một Skill có thể tái sử dụng.

Và lần tiếp theo khi yêu cầu AI thêm Redis vào một project, câu hỏi sẽ không còn chỉ là:

Đoạn code này có chạy không?

Mà sẽ là:

Đoạn code này có sử dụng Redis đúng cách, có thể scale và đủ an toàn để chạy trên production không?

---

Phụ lục: Toàn bộ câu trả lời của Codex cho ví dụ

For several million devices, I’d use a Sorted Set as the primary
index, with the score equal to the device’s last-seen Unix timestamp.

Recommended Structure

Use one or more sharded sorted sets:

device:last_seen:{bucket}

Example:

device:last_seen:00
device:last_seen:01
...
device:last_seen:255

Each member is the device_id, and the score is
last_seen_epoch_seconds or milliseconds.

ZADD device:last_seen:42 1721458800 device_abc123

Online status is then derived from recency:

online = last_seen >= now - 600

That avoids storing a separate boolean that can become stale.

Key Structure

Avoid one huge global key if you have millions of devices.
Shard by a stable hash of device ID:

device:last_seen:{shard}

For example, crc32(device_id) % 256.

If you also need direct lookup by device ID, you can optionally store:

device:{device_id}:status

as a small String or Hash:

HSET device:abc123:status last_seen 1721458800
EXPIRE device:abc123:status 86400

But I’d only add this if point lookups are frequent enough to
justify duplicate storage. The sorted set alone supports both
update and activity-window queries.

TTL Strategy

Do not TTL individual members inside a sorted set; Redis does not
support per-member TTL.

Instead, periodically prune old entries:

ZREMRANGEBYSCORE device:last_seen:42 -inf 1721372400

For example, remove devices not seen for 24 hours, 7 days,
or whatever your retention window is.

If using per-device status keys too, give them a TTL slightly
longer than the offline threshold:

online threshold: 10 minutes
status key TTL: 1-24 hours, depending on lookup needs

Memory Considerations

Sorted sets are a good fit, but millions of members are still
significant. Memory cost comes from:

device ID length
sorted-set overhead
score storage
key overhead per shard
optional duplicate status keys

Keep device IDs compact. Prefer numeric IDs or short opaque IDs
over long UUID-like strings if you control the format.

Avoid storing JSON per device unless you need rich metadata.
For online/last-seen only, JSON is overkill.

Cluster Compatibility

Sharded sorted sets are cluster-friendly because each query
touches one key at a time.

Good:

device:last_seen:00
device:last_seen:01
...

To query all shards, issue parallel ZRANGEBYSCORE calls from
the client and merge results client-side.

Avoid a single key like:

device:last_seen

because it creates one massive key on one cluster slot.

Also avoid hash-tagging all shards into the same slot, such as:

{device}:last_seen:00
{device}:last_seen:01

That would defeat cluster distribution.

Query Active In Last 10 Minutes

For each shard:

ZRANGEBYSCORE device:last_seen:42 1721458200 +inf

Where:

1721458200 = now - 600 seconds

If you need count only:

ZCOUNT device:last_seen:42 1721458200 +inf

Across 256 shards, run those in parallel and concatenate or
sum results.

Big-Key And Hot-Key Risks

A single sorted set with several million devices is a big key risk:
slower deletes, expensive range reads, uneven cluster memory,
and one shard taking all writes.

Shard the sorted set to reduce this.

Hot-key risk appears if:

all devices update the same key
one tenant has extreme traffic
dashboards repeatedly query all active devices

Mitigations:

Shard by device ID hash
Batch or pipeline updates
Use ZCOUNT for counts instead of fetching full device lists
Paginate active-device queries with ZRANGEBYSCORE + LIMIT
Prune old entries continuously, not in giant cleanup jobs
Route read-heavy dashboards to replicas if slight staleness
is acceptable

So the core recommendation is: sharded Redis Sorted Sets,
score = last-seen timestamp, member = device ID,
online derived by score range.

---

Nguồn tham khảo

• Redis Blog: We built an Agent Skill so AI writes Redis code the way Redis experts would
• Redis Agent Skills repository