queue

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 9 of 2,852 analyzed posts/comments in the seven days ending that day (13 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 16:39 UTCComment

   smoothmq or bullmq. as long as you do one runner, every queue will act as a fifo. why not use a db table to do it( very similar to bullmq)

2. 2026-10-15 15:08 UTCComment

   This particular queue is for asynchronous updates to insurance policies. So we cant allow two to be run at the same time, because then one of them will be executing with outdated information on that policy.

3. 2026-10-15 05:58 UTCComment

   Also FIFO + one job in flight per key WILL cause you to have stuck jobs and now an ever growing queue.

4. 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.

5. 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.