Integrating Redis-Style Channels with AMPS

This page assumes a bridge, adapter, or application republishes messages from a Redis-based pub/sub or notification environment into AMPS while preserving the original channel naming convention. In that deployment, AMPS adds a current-state and analytics layer on top of the Redis-style channel space while preserving naming that existing operators and applications already understand. The same layout also provides a clean path for publishing directly into AMPS later without redesigning the channel taxonomy.

AMPS uses the glob topic matching policy for this pattern. That policy follows Redis-style glob semantics rather than PCRE regular expressions.

Where Redis-Style Matching and AMPS Overlap

Redis-style channel spaces often rely on lightweight wildcard matching rather than full regular expressions. AMPS can preserve that style with TopicMatchingPolicy set to glob as the instance default or as a local override on the imported channel space. Subscriptions and SOW queries can also use topic_matching_policy=glob, and any TOPIC_MATCH predicate in the same command filter uses glob rules.

That is useful when a team wants to keep a familiar channel naming scheme but also needs:

• Current-state storage for channels or keyspaces that would otherwise be transient
• Atomic query plus live stream behavior through sow_and_subscribe
• Lower-bandwidth UI updates through sow_and_delta_subscribe
• Aggregated or normalized datasets built with Views and Unions
• Dashboard refresh control with ConflatedTopics

Redis-Style Glob Patterns Compared to Default AMPS PCRE

The default AMPS policy, pcre, supports full regular expressions. The glob policy is intentionally simpler and closer to Redis-style channel matching.

Glob Pattern	Meaning	Representative PCRE Equivalent
orders/*.json	Match any channel that starts with orders/ and ends with .json	^orders/.*\.json$
orders/order-?.json	Match exactly one character in the ? position	^orders/order-.\.json$
*	Match every channel	.*

Under glob, * matches any sequence of characters, ? matches exactly one character, and \ escapes wildcard characters. Unlike RabbitMQ, MQTT, Solace, or TIBCO topic matching, the wildcard is not tied to a specific topic-level separator.

Recommended AMPS Design

For Redis-style integrations:

1. Preserve the original channel name when publishing into AMPS if downstream users already think in those channel names.
2. Keep the instance default at pcre unless most of the instance uses glob semantics. For imported Redis-style namespaces, add TopicMatchingPolicy set to glob beside each Pattern or UnderlyingTopic that should use glob rules.
3. Capture the relevant channel space into a Pattern SOW topic such as orders:* or __keyspace@0__:*.
4. Add a Union whose UnderlyingTopic repeats that same pattern expression if analytics, dashboards, or other downstream consumers need one stable SOW topic.
5. Add Views and ConflatedTopics for operational summaries and browser delivery.

This arrangement works well when teams want to add AMPS observability and state immediately while keeping open the option of shifting selected flows to native AMPS topics over time.

Because glob patterns are whole-string patterns, a broad * can capture a very large namespace. Narrow the Pattern to a functional area when possible.

Sample Configuration

The following example keeps the instance default at pcre, preserves a Redis-style order channel namespace with local glob overrides, aggregates it inside AMPS, and creates a UI-oriented topic:

<AMPSConfig>
  <Name>redis-observability</Name>
  <TopicMatchingPolicy>pcre</TopicMatchingPolicy>

  <SOW>
    <Topic>
      <Name>redis-orders-space</Name>
      <Pattern>orders:*</Pattern>
      <TopicMatchingPolicy>glob</TopicMatchingPolicy>
      <MessageType>json</MessageType>
      <Key>/orderId</Key>
      <FileName>./sow/%n.sow</FileName>
    </Topic>

    <Union>
      <Name>redis-orders-union</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>orders:*</UnderlyingTopic>
      <TopicMatchingPolicy>glob</TopicMatchingPolicy>
    </Union>

    <View>
      <Name>redis-orders-by-region</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>redis-orders-union</UnderlyingTopic>
      <Projection>
        <Field>/region</Field>
        <Field>COUNT(/orderId) AS /orderCount</Field>
      </Projection>
      <Grouping>
        <Field>/region</Field>
      </Grouping>
    </View>

    <ConflatedTopic>
      <Name>redis-orders-by-region-ui</Name>
      <MessageType>json</MessageType>
      <UnderlyingTopic>redis-orders-by-region</UnderlyingTopic>
      <Interval>1s</Interval>
    </ConflatedTopic>
  </SOW>
</AMPSConfig>

To capture an entire Redis-style namespace, use * as the Pattern. In practice, most teams begin with a smaller channel family such as orders:*, metrics:*, or __keyspace@0__:*.

Usage Tips

• Use TOPIC_MATCH for fields that store channel names, for example /channel TOPIC_MATCH 'orders/order-?.json'.
• If you need a literal * or ? in a TOPIC_MATCH filter, escape it with \ in a raw string literal, such as r'orders/\*.json'.
• Remember that glob * spans separators. If you need one-level semantics, encode that constraint in the naming convention or use a more specific pattern.
• Migrating clients can keep glob syntax on a per-request basis with topic_matching_policy=glob on commands such as subscribe, sow, and sow_and_subscribe.
• Use LIKE only when you intentionally want PCRE behavior rather than the resolved glob behavior.
• If AMPS normalizes channel names for internal use, keep the original Redis channel name in a message field so UI and filter logic can still use it.