Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Redis Pub/Sub is a lightweight messaging paradigm enabling real-time communication between decoupled services. In 2026, it remains a foundational tool for low-latency notifications, live dashboard updates, and simple event broadcasting. Unlike persistent message brokers, Redis Pub/Sub is 'fire-and-forget,' meaning messages are not stored; they are delivered only to active subscribers. For software engineers, AI engineers, and system architects, understanding this pattern is critical for building responsive, event-driven architectures. Interviewers focus on this topic to test your grasp of distributed system trade-offs, specifically the distinction between ephemeral messaging and persistent event streams. Junior candidates are expected to understand basic commands like PUBLISH and SUBSCRIBE, while senior candidates must articulate the implications of its lack of persistence, how it compares to Redis Streams, and when to choose it over more robust message queues like Apache Kafka.
Redis Pub/Sub provides an extremely low-latency path for inter-service communication, often operating in the sub-millisecond range. Its primary value lies in simplicity; it requires no complex configuration or disk I/O, making it ideal for transient data like chat messages, stock ticker updates, or server-side events (SSE). In 2026, as systems become more distributed and latency-sensitive, distinguishing between ephemeral Pub/Sub and persistent streams is a high-signal differentiator. A strong candidate knows that Pub/Sub is not a database and does not provide reliability guarantees, whereas a weak candidate might incorrectly suggest it for mission-critical task queues. Understanding this distinction is vital for avoiding data loss in production systems. Furthermore, with the rise of AI-driven real-time applications, Redis Pub/Sub is frequently used to broadcast model inference status or agent state changes across clusters, making it a relevant skill for modern AI infrastructure.
Redis Pub/Sub operates as an in-memory broadcast system. When a publisher sends a message to a channel, the Redis server iterates through its internal subscriber list for that channel and pushes the message to each client's output buffer. There is no intermediate storage or queueing mechanism.
[Publisher Client]
↓
[PUBLISH Command]
↓
[Redis Server Engine]
↓ ↓ ↓
[Sub 1] [Sub 2] [Sub 3]
↓ ↓ ↓
[Buffer] [Buffer] [Buffer]
↓ ↓ ↓
[Subscriber Clients]Using a single channel to notify multiple microservices of a state change.
Trade-offs: Extremely fast but provides no guarantee that all services received the event.
Using Pub/Sub to send configuration updates or shutdown signals to worker nodes.
Trade-offs: Simple to implement but dangerous if a node is offline during the signal.
| Reliability | Pub/Sub is inherently unreliable; messages are lost if subscribers are disconnected. Use Redis Streams for at-least-once delivery. |
| Scalability | Scales horizontally by adding more Redis nodes, but Pub/Sub channels do not automatically shard across clusters. |
| Performance | Extremely high throughput; latency is primarily network-bound. |
| Cost | Low cost as it requires minimal CPU and memory compared to persistent brokers. |
| Security | Requires ACLs to restrict which users can publish or subscribe to specific channels. |
| Monitoring | Monitor 'pubsub_channels' and 'pubsub_patterns' metrics via INFO command. |
No. Redis Pub/Sub is an ephemeral messaging system. Messages are sent to active subscribers only and are discarded immediately after delivery. If a subscriber is not connected at the time of publication, the message is lost forever.
Redis Pub/Sub is a 'fire-and-forget' broadcast mechanism with no history, while Redis Streams is a persistent, log-based data structure that supports consumer groups, message acknowledgement, and historical data retrieval.
It is not recommended. Because Pub/Sub lacks persistence and acknowledgement, tasks will be lost if the worker is offline or crashes. Use Redis Streams or a dedicated queueing system for task management.
If a subscriber cannot keep up with the rate of incoming messages, its output buffer will grow. Once it hits the configured 'client-output-buffer-limit', Redis will disconnect the client to protect the server's memory.
Redis guarantees that messages published to a specific channel will be delivered in the order they were published to that channel. However, there is no global ordering guarantee across different channels.
You can use the 'INFO pubsub' command to see the number of active channels and patterns. For deeper insights, you should monitor client output buffer sizes and connection counts.
Yes, it is extremely fast and efficient for broadcasting. However, you must be careful with network bandwidth and ensure your subscribers can process messages fast enough to avoid buffer overflows.
Yes, using the 'PSUBSCRIBE' command, you can subscribe to channels using glob-style patterns (e.g., 'news.*'). This allows you to listen to multiple related channels with a single connection.
This is often due to the client being disconnected by Redis because its output buffer exceeded the limit. Ensure your subscriber logic is non-blocking and processes messages efficiently.
The message is simply discarded. Redis does not store it, queue it, or log it. The publisher receives a return value indicating how many clients received the message (which will be 0).
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.