Redis hard
In Redis Streams, a message read by a consumer group enters the Pending Entries List (PEL). What specific guarantee does this data structure provide?
- A It guarantees that the message has been physically deleted from the primary stream buffer to reclaim volatile RAM.
- B It tracks messages that are delivered but not yet acknowledged, allowing for recovery if the consumer crashes.
- C It creates a permanent compressed archive of the message for long-term historical auditing and compliance reporting.
- D It holds the message in a high-priority background queue until the producer confirms the next sequence ID.
Answer: B. It tracks messages that are delivered but not yet acknowledged, allowing for recovery if the consumer crashes.
The PEL is the foundation for 'At-Least-Once' delivery. It tracks which consumer 'owns' which message until `XACK` is called. If a consumer dies, an admin can use `XCLAIM` to move the pending messages to a healthy worker.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- If the Redis memory limit is reached, what specific behavior is exhibited by the `allkeys-lru` eviction policy?
- What is the defining characteristic of a Redis 'Set' data type compared to a standard Redis 'List'?
- In the context of Redis messaging, what is the functional definition of the 'Pub/Sub' feature?
- How does the Redis background snapshotting process (`BGSAVE`) leverage the operating system's `fork()` mechanism to minimize memory overhead?
- Why does Redis proactively disconnect a Pub/Sub client that exhibits high 'output buffer' usage relative to its ingestion rate?
- How does a 'Sorted Set' (ZSET) manage its internal membership and ordering differently from a plain Set?