Lists

Redis lists are doubly linked lists of strings — useful for simple FIFO/LIFO queues, recent-items buffers, and lightweight job staging. Producers push; consumers pop or block waiting for work.

					LPUSH jobs:email '{"id":1,"to":"a@b.c"}'
BRPOP jobs:email 30          # blocking consumer, 30s timeout
RPUSH logs:api "2026-06-15 ok"
LTRIM logs:api 0 999         # cap to last 1000 entries
LLEN jobs:email
				

| Operation | Behavior | |-----------|----------| | `LPUSH` / `RPUSH` | Add at head or tail — O(1) | | `LPOP` / `RPOP` | Remove one element | | `BRPOP` / `BLPOP` | Block until element or timeout | | `LTRIM` | Keep fixed window — ring buffer pattern |

Lists are not durable message queues by themselves: a popped item is gone unless you use a reliable-queue pattern (e.g. `RPOPLPUSH` to a processing list, or prefer Streams). At-most-once is the default story.

On interviews: describe a queue requirement and why lists, streams, or a real broker fits.

Common pitfalls: using lists for critical workflows without ack/retry; unbounded list growth; `BRPOP` without visibility timeout equivalent; multiple consumers racing without coordination.

The trade-off is simplicity and low latency versus delivery guarantees — lists are fine for best-effort work distribution; durability and consumer groups need streams or an external queue.

Checklist:

• State delivery semantics (at-most-once vs at-least-once).
• Bound list size with `LTRIM` when buffering.
• Explain blocking consumer behavior and timeouts.
• Name when Streams replace lists.