Redis Pub/Sub Explained with a Real-World Example

Real-time communication between distributed services is a common challenge in modern applications.
Traditional approaches, such as polling the database or cache on each request, introduce latency, network overhead, and scalability issues.

To tackle this, Redis Pub/Sub provides a push-based notification mechanism that allows instances to stay in sync instantly and efficiently.

To illustrate this concept, we implemented a feature flag synchronization project in Spring Boot. While feature flags serve as our example scenario, the core lesson is about Redis Pub/Sub architecture and its advantages.

TL;DR: If you want to skip the explanation and dive straight into the code, check out the implementation on GitHub:
https://github.com/ercansormaz/redis-pub-sub

How Redis Pub/Sub Works

Redis Pub/Sub is a publish/subscribe messaging pattern:

1. Publisher: Sends messages to a channel when an event occurs.
2. Subscriber(s): Listen to the channel and react to incoming messages.

Key benefits:

• Push-based: No polling is required, so updates are near-instantaneous.
• Lightweight: Only minimal memory is needed for subscriptions; data persistence is not required.
• Scalable: Multiple subscribers can listen to the same channel and update their local state independently.

In our demo, each Spring Boot instance:

• Loads feature flag states from a database on startup.
• Maintains a local in-memory cache.
• Subscribes to a Redis channel for updates.
• Updates its cache immediately upon receiving a message.

This pattern can be applied to any near-real-time notification scenario, not just feature flags.

Why This Approach?

Typically, applications either:

• Query the database or cache on each request, or
• Poll periodically for updates.

Both approaches have downsides:

Demo Example: Feature Flags

To simulate a real-world scenario:

• Database (MySQL): Stores the persistent state of feature flags.
• Spring Boot instances: Each maintains a local cache of feature states.
• Redis Pub/Sub: Used solely for notifying instances about updates.

When a feature flag is updated:

1. DB record is updated.
2. Redis publishes a message to a channel.
3. All subscribed instances receive the event and update their local cache.

Example log output:

redis-pub-sub-3  | [FEATURE_FLAG_SUSCRIBER] [MESSAGE] [FEATURE=FEATURE_1] [ENABLED=true]
redis-pub-sub-2  | [FEATURE_FLAG_SUSCRIBER] [MESSAGE] [FEATURE=FEATURE_1] [ENABLED=true]
redis-pub-sub-1  | [FEATURE_FLAG_SUSCRIBER] [MESSAGE] [FEATURE=FEATURE_1] [ENABLED=true]

Notice that Redis is not persisting the messages, which is fine because the database holds the source of truth.

Redis Pub/Sub vs Traditional Message Brokers

While Redis Pub/Sub may look similar to systems like RabbitMQ or Kafka, there are key differences:

Takeaway: Redis Pub/Sub excels for ephemeral, near-real-time state synchronization, while traditional brokers are better for durable, guaranteed delivery workloads.

Conclusion

Redis Pub/Sub provides a lightweight, fast, and efficient way to synchronize state across multiple distributed services.
While we demonstrated this with a feature flag example, the pattern is broadly applicable to any real-time notification scenario where persistence is not critical.

By leveraging push-based updates, developers can eliminate polling, reduce latency, and keep distributed caches or in-memory state in sync effortlessly.

👉 You can explore the source code on GitHub:
https://github.com/ercansormaz/redis-pub-sub