Reliable PubSub vs. Valkey & Redis Streams
For developers of distributed applications, selecting a messaging infrastructure is not a simple choice. The entire development cycle might be impacted, from how long it takes to write code to the effort required for long-term maintenance.
Valkey and Redis streams are a popular choice because they provide a flexible foundation built on append-only log semantics. And while streams offer low-level primitives like XADD, XREAD, and XREADGROUP, built on the lightning-fast Valkey or Redis data store, developers must manually manage lifecycles, message claiming, and consumer group coordination.
However, the Valkey/Redis client Redisson PRO offers Reliable PubSub, a higher-level messaging abstraction built specifically for Java applications. Reliable PubSub gives Java developers enterprise-grade messaging features built on the speed of Valkey or Redis while abstracting away the low-level details with familiar methods. The feature comparisons below show the differences between bare-metal Valkey/Redis streams and Reliable PubSub.
Quick Feature Comparison
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Abstraction Level | Low-level primitives | High-level messaging |
| Deployment | Self-managed or fully managed via vendor services | Self-managed or fully managed via Valkey/Redis vendor services |
| Learning Curve | Steeper (many commands to learn) | Gentler (familiar messaging concepts) |
While both options run on the same Valkey/Redis infrastructure, Reliable PubSub provides a high-level messaging abstraction over the low-level primitives of Redis streams. Native streams offer maximum flexibility but come with a steeper learning curve, thanks to a long list of commands.
Reliable PubSub requires a Redisson PRO license but offsets this by offering an opinionated, familiar messaging framework with a gentler learning curve for Java developers.
Messaging Model
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Pub/Sub Model | ||
| Message Queuing | Via consumer groups | |
| Topic Abstraction | Stream keys (no topic metadata) | Full topic model |
| Subscription Abstraction | Consumer groups (manual setup) | Managed subscriptions |
| Fan-out (One-to-Many) | Multiple consumer groups | Multiple subscriptions |
| Load Balancing | Within a consumer group | Within subscription |
| Push Delivery | Blocking read-only | Native push consumers |
| Pull Delivery | XREAD/XREADGROUP | Short & long polling |
Both solutions support Pub/Sub models, message queuing, and various delivery mechanisms. However, Reliable PubSub offers a full topic and managed subscription abstraction, while Valkey/Redis streams rely on stream keys and manual consumer group setups. In addition, Reliable PubSub supports native push consumers, while Redis Streams is limited to blocking pull reads.
Offset & Replay
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Offset-Based Positioning | ||
| Seek to Timestamp | ||
| Seek to Message ID | ||
| Seek to Earliest | ||
| Seek to Latest | ||
| Per-Consumer-Group Offset | last-delivered-id | Per-subscription |
| Message Replay | ||
| Range Queries |
Both systems provide offset tracking and historical replay. They both feature offset-based positioning, allowing applications to search by message ID or timestamp, perform range queries, and replay messages. However, only Reliable PubSub can automatically manage per-subscription offsets.
Message Delivery & Acknowledgment
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| At-Least-Once Delivery | With XACK | Default |
| At-Most-Once Delivery | NOACK option | Via AUTO ack mode |
| Individual Message Ack | ||
| Batch Acknowledgment | ||
| Negative Acknowledgment | Failed/rejected modes | |
| Automatic Redelivery | ||
| Delivery Counter |
Valkey/Redis streams provide basic positive acknowledgment but lack negative acknowledgment out of the box. Failed messages ultimately end up idling in the Pending Entries List (PEL).
Reliable PubSub includes explicit negative acknowledgment handling, configurable retry behaviors, automatic redelivery upon visibility timeouts, and native deduplication for exactly-once delivery.
Consumer Model
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Consumer Groups | ||
| Named Consumers | ||
| Consumer Auto-Creation | ||
| Consumer Deletion | ||
| Message Claiming | ||
| Idle Consumer Detection | Idle time in XPENDING | Claim timeout |
| Push Consumer | ||
| Pull Consumer |
Both systems support consumer groups, but handle them very differently. Valkey/Redis streams force applications to implement their own background logic and scheduling to claim messages from dead consumers using XCLAIM or XAUTOCLAIM manually.
Reliable PubSub relieves this burden by automatically handling message claiming through configurable claim timeouts, and native push and pull consumers.
Visibility & Processing Control
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Visibility Timeout | ||
| Processing Time Extension | ||
| Claim Timeout |
Valkey/Redis streams lack a native visibility timeout. Once a message is delivered, it remains in the PEL indefinitely until another consumer explicitly claims it.
Meanwhile, Reliable PubSub supports configurable visibility timeouts at multiple levels, implicitly locking messages during processing and automatically redelivering them if the consumer fails to acknowledge in time.
Message Features
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Message ID | Auto-generated (timestamp-sequence) | |
| Message Headers/Metadata | Part of payload (field-value pairs) | Separate headers |
| Message Timestamp | Embedded in ID | |
| Message TTL | Stream-level trimming only | Per-message or topic-level |
| Message Delay | ||
| Message Priority | 0-9 levels | |
| Message Size Limit | Configurable | |
| Bulk Publishing |
With Reliable PubSub, developers can utilize separate message headers, set per-message time-to-live (TTL), enforce message delays, and rank messages across 0-9 priority levels.
However, Valkey/Redis streams strictly bind messages to field-value pairs within the payload and constrain their size to standard Redis string limits.
Dead Letter Queue
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Native DLQ | ||
| Max Delivery Attempts | Manual (check delivery counter) | Configurable |
| Automatic DLQ Routing | Application logic | |
| DLQ Inspection | ||
| Rejected Message Handling | Explicit rejection |
Handling persistently failing messages requires custom logic in Valkey or Redis. Streams track delivery counts within the PEL but does not offer a built-in Dead Letter Queue (DLQ). Applications are forced to inspect counters and manually move poison messages to separate streams.
Reliable PubSub provides a native DLQ out of the box, allowing for automatic routing, configurable maximum delivery attempts, and explicit rejection handling.
Retention & Cleanup
| Valkey/Redis Streams | Reliable PubSub | |
|---|---|---|
| Time-Based Retention | Manual (XTRIM with MINID) | |
| Size-Based Retention | MAXLEN/MINID in XADD or XTRIM | maxSize |
| Automatic Trimming | Approximate (~ modifier) | |
| Manual Deletion | XDEL | |
| Retain After Ack | Manual XDEL needed | Via retention modes |
| Configurable Retention Modes | 3 modes | |
| Consumer Group Coordination | Manual (check all groups before deleting) | Automatic |
With Valkey/Redis streams, messages are not automatically deleted upon acknowledgment. Developers must manually coordinate stream trimming (XTRIM) or explicit deletion (XDEL) across all consumer groups.
Reliable PubSub automates this complex coordination with three distinct retention modes, ensuring messages are safely removed once processed without requiring manual cleanup jobs.
Features Unique to Reliable PubSub
As the above feature comparisons show, Reliable PubSub improves and expands upon the messaging features of native Valkey/Redis streams. For Java developers, having these capabilities available via familiar classes and methods is a huge time-saver. Then there are numerous features found in Redisson PRO and Reliable PubSub that are not available in Valkey/Redis streams. Many developers using Redis Streams are actually building a queue pattern on top of streams; this is where Reliable Queue can be useful.
Implementing these Reliable PubSub features with native Valkey or Redis would add significant development and maintenance time. The features unique to Reliable PubSub include:
Message Priority: Reliable PubSub supports 9 distinct priority levels, ensuring urgent alerts and critical orders are processed ahead of routine events, unlike the strict FIFO ordering in Valkey/Redis streams.
Delayed Message Delivery: You can easily schedule messages for future delivery or implement exponential backoff retries without requiring an external scheduler.
Visibility Timeout: Messages automatically become invisible during processing. They are automatically redelivered once they reach the specified timeout. This prevents duplicate processing and allows apps to recover from consumer crashes quickly.
Native Negative Acknowledgment: Explicit "failed" or "rejected" states can trigger predictable redelivery or routing, providing crystal-clear semantics for error handling.
Native Dead Letter Queue: Subscriptions can be configured to automatically route persistently failing messages to a DLQ after a set number of delivery attempts.
Per-Message TTLs: Individual messages can be set to self-expire based on a wide range of criteria. This feature eliminates the need for separate streams with different TTL settings. It also helps automate cleanup processes.
Per-Operation Sync Modes: Unlike Valkey/Redis streams, each publish or pull command can specify its own durability requirements.
Native Push Consumer: Event-driven processing eliminates inefficient polling loops, simplifies consumer code, and significantly reduces latency.
Operation Control: Administrators can gracefully disable or enable publishing and consumption during migrations or emergencies without stopping clients.
Automatic Message Claiming: Transfers from failed consumers occur automatically via configured timeouts, completely bypassing the need for manual XCLAIM polling jobs.
Deduplication by Payload Hash: The system can automatically filter out duplicate deliveries—such as repeated webhooks—based on the payload hash within a specified window.
Configurable Retention Modes: Three automated retention modes seamlessly coordinate cleanup across multiple consumer groups, removing the danger of memory leaks.
Separate Message Headers: You can route and filter messages based on metadata headers without deserializing the payload.
Streams or Reliable PubSub: Which One Is Right For You?
Valkey/Redis Streams provide raw, low-level primitives, but they also place the burden of implementing timeouts, DLQs, and cleanup jobs squarely on your development team. Reliable PubSub harnesses the raw speed of Valkey or Redis and adds a comprehensive suite of enterprise features that ensure correctness and accelerate development time. Google PubSub comparison.
So, which one is right for you?
For Java developers who need advanced messaging capabilities without a ton of operational overhead, Reliable PubSub is clearly the best choice.