Join our Streaming Lakehouse Tour!
Register Now.->
More Than a Cache: Unlocking New Architectures with RisingWave's Enhanced Redis Sink

More Than a Cache: Unlocking New Architectures with RisingWave's Enhanced Redis Sink

In real-time stream processing, generating insights in milliseconds is only half the battle. The other, equally critical half is serving those insights to your applications and users with the same low latency. Your fraud detection system is useless if the alert arrives too late. Your real-time dashboard is misleading if the data is stale. This is the "last mile" problem of real-time data.

This is where the combination of RisingWave and Redis truly shines. RisingWave excels at complex, stateful stream processing—transforming, aggregating, and joining raw data streams into valuable insights. Redis, the industry-standard in-memory data store, excels at serving data at microsecond speeds.

By connecting RisingWave directly to Redis with its native sink connector, you create a powerful, end-to-end pipeline for building a new class of interactive, real-time applications. This post explores three powerful patterns you can build today.

Pattern 1: The Real-Time Cache for Instant Lookups

Use scenario: Imagine you're building a user personalization service. You want to enrich incoming user activity events with a complete, up-to-date user profile that includes their recent behavior, purchase history, and segment information. This enriched profile needs to be available for downstream services with sub-millisecond latency.

Architecture: RisingWave continuously consumes multiple streams (e.g., clicks, purchases, user updates) and uses a materialized view to maintain a complete, real-time profile for every user. The Redis sink then pushes every change to this profile into Redis as a simple Key-Value pair, with the user_id as the key and a JSON object as the value. Your application can now fetch a rich, complete user profile with a single, fast GET command from Redis.

Example:

First, define a materialized view in RisingWave to compute the user profiles.

CREATE MATERIALIZED VIEW user_profiles_mv AS
SELECT
    user_id,
    -- Aggregate other user data into a single record
    ...
FROM all_user_sources;

Next, create a sink to push these profiles to Redis. Using FORMAT PLAIN ENCODE JSON, RisingWave automatically handles serializing the row into a JSON value.

CREATE SINK redis_cache_sink
FROM user_profiles_mv
WITH (
    connector = 'redis',
    redis.url = 'redis://127.0.0.1:6379/',
    primary_key = 'user_id' -- This becomes the Redis key
) FORMAT PLAIN ENCODE JSON (
    force_append_only = 'true'
);

You've built a high-performance, continuously updated caching layer without writing any complex cache invalidation logic. RisingWave and Redis handle the entire lifecycle.

Pattern 2: The Proximity Engine for Location-Aware Services

Use scenario: Consider a food delivery app. You need to show customers nearby restaurants in real-time. Or, on the flip side, you need to assign an incoming order to the nearest available driver. These queries require efficient geospatial indexing and searching.

Architecture: You can offload this complex logic to Redis's native geospatial capabilities. Your stream of driver locations or restaurant coordinates flows through RisingWave. The Redis sink is configured to use the geospatial type, which maps the longitude and latitude from your stream directly into a Redis Geospatial Set using the GEOADD command under the hood. Your application can then query Redis directly with commands like GEORADIUS to find all drivers within a 5km radius, letting Redis handle the heavy lifting.

Example:

Assume you have a source of driver location updates.

CREATE TABLE driver_locations (
    driver_id VARCHAR,
    city VARCHAR,
    longitude FLOAT,
    latitude FLOAT
);

Now, create a sink to populate a Redis geospatial index for each city.

CREATE SINK geo_sink
FROM driver_locations
WITH (
    connector = 'redis',
    redis.url = 'redis://127.0.0.1:6379/',
    primary_key = 'driver_id,city' -- Ensures uniqueness for updates
) FORMAT UPSERT ENCODE TEMPLATE (
    redis_value_type = 'geospatial',
    key_format = 'drivers:{city}',      -- e.g., drivers:san_francisco
    member = 'driver_id',               -- The object we are tracking
    longitude = 'longitude',
    latitude = 'latitude'
);

You can build sophisticated, real-time location-based features without a dedicated geospatial database. This simplifies your architecture and reduces operational overhead.

Pattern 3: The Event Broadcaster for Live Notifications

Use scenario: You're building a real-time fraud detection system. When RisingWave identifies a suspicious transaction pattern, you need to instantly notify multiple downstream systems: one to block the user's account, another to log the event for review, and a third to update a live monitoring dashboard.

Architecture: This is a perfect use case for the Pub/Sub pattern. RisingWave acts as the publisher. When a fraudulent event is detected in a materialized view, the Redis sink publishes a message to a specific Redis channel (e.g., fraud_alerts). Multiple, decoupled microservices can subscribe to this channel and react to the event independently and in parallel. This creates a resilient, scalable, event-driven architecture.

Example:

Suppose you have a materialized view that outputs alerts.

CREATE MATERIALIZED VIEW fraud_alerts_mv AS
SELECT
    user_id,
    alert_type, -- e.g., 'high_value_transaction'
    details     -- JSON string with event details
FROM suspicious_events;

Create a sink that publishes each alert to a dynamic channel based on the ”alert_type”.

CREATE SINK pubsub_sink
FROM fraud_alerts_mv
WITH (
    connector = 'redis',
    redis.url = 'redis://127.0.0.1:6379/',
    primary_key = 'user_id,alert_type'
) FORMAT UPSERT ENCODE TEMPLATE (
    redis_value_type = 'pubsub',
    channel_column = 'alert_type', -- Dynamically set channel from a column
    value_format = '{details}'     -- The message payload
);

You can build loosely coupled, highly scalable event-driven systems. New services can listen for events simply by subscribing to a Redis channel, with no changes needed in RisingWave.

Conclusion: A Foundation for Interactive Systems

The RisingWave Redis sink is more than just a connector; it's a bridge that closes the gap between real-time data processing and real-time user interaction. By leveraging these patterns, you can:

  • Serve pre-computed analytics with microsecond latency using the Key-Value cache pattern.

  • Build sophisticated location-based services by offloading geospatial queries to Redis.

  • Create scalable, event-driven architectures with loosely coupled components via Pub/Sub.

Together, RisingWave and Redis provide a robust foundation for the next generation of responsive, data-driven applications.

Get started with Redis Sink in RisingWave

Ready to connect RisingWave with Redis and unlock seamless real-time data delivery?

  • Learn More: Check out the documentation to understand how to configure and use the Redis sink in RisingWave.

  • Try RisingWave Today:

  • Talk to Our Experts: Have a complex use case or want to see a personalized demo? Contact us to discuss how RisingWave can address your specific challenges.

  • Join Our Community: Connect with fellow developers, ask questions, and share your experiences in our vibrant Slack community.

We’re excited to see how you’ll use the Redis sink to power responsive, data-driven applications in real time!

The Modern Backbone for Your
Event-Driven Infrastructure
GitHubXLinkedInSlackYouTube
Sign up for our to stay updated.