redis

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-10-15

Final complete day: 2026-10-15. Attention was 0.3% — this entity appeared in 8 of 2,852 analyzed posts/comments in the seven days ending that day (9 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-10-15 12:14 UTCComment

   Two things worth flagging, plus two options nobody mentioned yet. JetStream is not a drop-in for SQS message groups. Ordering there is per subject, consumers filter by subject, so per-key serialization means subject-per-key plus a consumer per key, or hashing keys into a fixed number of buckets and consuming from those. With dynamic keys you end up owning the routing layer yourself, and unique subjects are not free memory-wise. Unless something landed very recently, there is no server-side "assign this key to this consumer" feature in JetStream. The disk-persistence part above is accurate though, and that is the real difference from Redis. If the only objection to Kafka is operational weight: Redpanda is Kafka API-compatible, single binary, no JVM and no ZooKeeper, and it runs fine on k8s. Cheaper way to find out whether partition-per-key actually fits your traffic than standing up a real Kafka cluster. If you are open to something that is not a broker at all: Temporal gives you this requirement as a primitive. The server enforces at most one workflow execution per Workflow ID at a time, so key = Workflow ID, work arrives as signals, and a running execution processes them serially while other keys run in parallel. There is a TS SDK, it is self-hostable and cloud-agnostic, and the backlog behind a busy key is handled for you. Honest caveat: self-hosting it is its own ops commitment, so it is the boring-correctness option, not the lightweight one. Whichever you pick, design the lease. One in flight per key without an expiring lock means a single evicted pod, and node drains and preemption on k8s are routine, leaves that key blocked while its backlog grows. You want lease renewal with a heartbeat, redelivery on expiry, and idempotent consumers, because at-least-once is what you actually get from any of these.

2. 2026-10-15 04:02 UTCComment

   I've used BullMQ with Redis on NodeJs, it handles bursts well. For strict FIFO per key, you'd need to implement lock logic. Consider storing payloads outside the queue, like in Postgres, to reduce memory usage.

3. 2026-10-14 21:30 UTCComment

   One thing that fixes the exact OOM problem you described: stop putting payloads in the queue. Store the payload in Postgres or S3 and pass only an ID through the job. Redis then holds tiny messages, and a 2.5M-item spike doesn't move the memory needle at all — the queue becomes a notification channel, not storage. You lose some convenience versus passing the payload straight through, but for that burst pattern it's the difference between a stable queue and one that eats your events.

4. 2026-10-14 16:22 UTCComment

   That burst pattern makes complete sense. NATS JetStream solves both issues because streams persist messages directly to disk instead of forcing everything into RAM like Redis. This prevents OOM data loss during massive event spikes while keeping idle running costs near zero.

5. 2026-10-14 16:03 UTCComment

   The thing I'd nail down first is whether you need ordering per key or only one job in flight per key, because those lead to different designs. With Kafka the partition is the ordering unit, so one hot key stalls everything behind it on that partition, and a consumer group can't go wider than the partition count. With BullMQ you get per-group concurrency, but you're the one writing the lock logic and it gets fiddly when a worker dies mid-job. A quick check is to replay a burst where one key carries 40 percent of the traffic and watch p99 latency on the other keys. The tradeoff is Kafka's ops cost versus a Redis footprint that grows with payload size.