RIP‐83 Lite Topic: A New Message Model

Status

• Current State: Discussing

• Authors: imzs, f1amingo

• Mailing List discussion: [email protected]

Background & Motivation

What do we need to do

• Will we add a new module?

Yes.

• Will we add new APIs?

Yes.

• Will we add a new feature?

Yes.

Why should we do that

In the evolving landscape of AI applications, messaging systems play an increasingly critical role in asynchronous communication. As AI applications move from monolithic to multi-agent architectures with complex distributed systems, there's a growing need for more flexible messaging patterns.

A key use case involves AI gateway applications that route requests to different AI services, when these services process requests asynchronously, they need to send responses back to specific gateway instances. Similarly, communication between AI agents also has the same requirement, where agents need to send messages to specific peer agents rather than broadcasting to all agents in the system. While traditional pub/sub excels at decoupling producers and consumers, it lacks guarantees that a specific message (especially one requiring a response or tied to a particular node) will be received and processed by the intended target instance.

So our goal is to overcome the limitations of standard publish-subscribe (pub/sub) messaging by introducing a** **directed delivery mechanism, which combines the scalability and resilience of messaging systems with the precision of point-to-point communication, as so called LITE_SELECTIVE. We expect this new pattern to be applied in some specific consumption scenarios, such as asynchronous communication among AI agents, we aim to introduce the new Pub/Sub-based, session-aware message model as a valuable complement to existing A2A (Agent-to-Agent) standard communication protocols like gRPC and HTTP callbacks (request-driven notifications), here is the comparison:

Protocol	Use Case	Strengths	Limitations
gRPC	Real-time control, low-latency interaction (e.g., LLM streaming, service-to-service calls)	High performance, strong typing, bidirectional streaming	Tight coupling; fails if target is offline
HTTP Callback	Notification delivery (e.g., webhook-style events)	Simple integration, widely supported	No delivery guarantee; vulnerable to retries, lost messages
Pub/Sub	Stateful workflows, session-aware commands, durable task dispatch	Fault-tolerant, Event-driven architectures, One-to-many/Many-to-one notifications or reactions, replayable, scalable	Requires message broker infrastructure, Additional storage costs

What value is added to Agentic AI

We expect this new message model to become a best practice for building asynchronous, event-driven agent architectures.

1. Support Long-Running & Resilient Workflows
   Agents can send commands or events tied to a specific session, knowing they will be delivered once the target recovers — critical for autonomous agents in unstable environments.
2. Enable True Autonomy
   Agents react to events rather than waiting for direct calls, promoting decentralized decision-making and self-orchestration.
3. Improve System Reliability
   Message brokers act as buffers during outages, preventing data loss and enabling graceful recovery.
4. Unlock Advanced Pattern
   • Event sourcing for agent state reconstruction
   • Audit trails and replayability
   • Dynamic load distribution across agent replicas
5. Interoperable with Existing Protocols
   • Use gRPC for real-time interactions
   • Use HTTP callbacks for simple external integrations
   • Use our pub/sub model for internal, reliable, session-aware messaging

Other workarounds

1. Using machine-specific consumer groups with filtering

2. Using broadcast consumption with filtering

These approaches are complex and inefficient. What's needed is a more elegant solution that allows senders to specify receivers at a finer granularity. This leads to the concept of "Lite Topic" - dynamic, lightweight topics that can be subscribed to on-demand, enabling fine-grained message routing without the overhead of traditional topics.

Goals

1. Enable machine/session-specific message delivery without complex workarounds

2. Support dynamic topic creation and subscription without pre-configuration

3. Handle millions of lightweight topics efficiently based on RIP-28 Light Message Queue (LMQ)

4. Provide simple APIs for developers to implement dynamic-response patterns over messaging

5. Support session recovery and reconnection in distributed AI applications

6. Maintain backward compatibility with existing RocketMQ features

Changes

Interface Design/Change

New Producer API

// Enhanced message builder with lite topic support

Message message = provider.newMessageBuilder()

                    .setTopic(parentTopic)        // Pre-created parent topic

                    .setLiteTopic(liteTopic)      // Dynamic lite topic

                    .setTag(tag)

                    .setKeys("KEY")

                    .setBody(body)

                    .build();

New Consumer API

// New LitePushConsumer for lite topic subscription

LitePushConsumer pushConsumer = provider.newLitePushConsumerBuilder()

    .bindTopic(parentTopic) // Bound to parent topic

          .setConsumerGroup(consumerGroup)     

          .build();



// Subscribe to lite topics dynamically

pushConsumer.subscribeLite(liteTopic);

Implementation

Lite Topic Characteristics And Differences

• Dynamically created without pre-configuration
• Short lifecycle (minutes to hours)
• Few messages per topic (several to thousands)
• Fine-grained subscription (no filtering needed)
• Bound to a pre-created parent topic for routing and namespace management

As shown on the right side of the diagram above, although it appears consistent with traditional message models on the left, there are actually differences in practice:

• All clients have identical subscriptions in traditional model while lite message model has different subscriptions.
• Traditional model has few topics subscribed (several to a dozen), while thousands in lite model.
• Topics is dynamically generated in lite model.
• Traditional model has long topic lifecycle while lite model very short.

Architecture Components

• Lite Lifecycle Management
  • Automatic creation on first subscription
  • TTL-based cleanup
  • Manual unsubscription support
• Subscription Registry
  • ClientID-based subscription tracking
  • Subscription tied to client ID rather than group
  • Bidirectional indexing of subscriptions
  • Incremental/complete sync between client-proxy-broker
• Storage Layer
  • Built on existing million queues capability
  • Lite topics implemented as LMQ (Lightweight Message Queue)
  • Parent topic provides namespace and routing
• Message Dispatch
  • Event-driven ready set mechanism instead of polling all topics
  • ClientID-based POP and polling equests instead of topic
  • Message aggregation from multiple lite topics
• Resource Management
  • Quota controls (max topics per client, max topics total)
  • Memory-optimized offset and order info management
  • Ready set overflow control
  • Parent topic-group binding for permission/offset management
• Performance Optimizations
  • Incremental offset info updates
  • In-memory order info updates (tradeoff)
  • String concatenation optimizations to reduce GC pressure

Compatibility, Deprecation, and Migration Plan

1. Are backward and forward compatibility taken into consideration?

This feature is additive and does not affect existing functionality.

2. Are there deprecated APIs?

No existing APIs are deprecated.

3. How do we do migration?

Existing topics and subscriptions continue to work unchanged. New APIs are introduced for lite topic functionality.

Implementation Outline

We will implement the proposed changes by 4 phases.

1. Client APIs

• RocketMQ Grpc Proto
• LitePushConsumer implementation
• Enhanced producer APIs
• Client-side subscription management

2. Core Infrastructure

• Lite topic lifecycle management
• Subscription registry and sync mechanisms
• Event-driven message delivery implementation

3. Performance Optimization

• Incremental offset info updates
• Reduce gc

4. Tooling and Monitoring

• Admin tools for lite topic management
• Metrics and monitoring integration
• Documentation and examples