Apache RocketMQ introduced LiteTopic, a two-level topic model, in a talk at Apache 2026, and Alibaba Cloud published the write-up on 29 October. A Parent Topic is the namespace and control boundary for permissions, routing and quotas, created in advance. LiteTopics sit underneath it, are created by the first message of a session, and are reclaimed by TTL when the session goes idle; each is ordered, isolated and replayable. Two implementation changes make this affordable at scale. The file-based consumption-queue index is replaced by a RocksDB key-value engine, and long polling is replaced by event-driven dispatch. The team reports two production users: the Qoder Cloud Agents coding service and the Model Studio inference gateway. In Qoder, task progress is stored in a checkpoint treated as authoritative rather than inferred from message acknowledgement timing, so restarts and replays do not distort it. In the gateway, rate limiting becomes pacing, because GPU throughput has a hard ceiling. Load tests with five brokers hold 2.5 million sessions at about 21 ms average and 47 ms P95 at 12.5k TPS, and about 29 ms and 61 ms at 25k TPS; six million sessions push those five brokers to roughly 84 percent CPU at 25k TPS. Ten brokers carry six million sessions at 50k TPS at about 26 ms average, 81 ms P95 and 47 percent CPU, and 15 million sessions at 50k TPS stay near 26 ms average and 71 ms P95.
Our takeThe design choice worth keeping is that progress lives in a checkpoint, not in delivery state. That is what makes replay safe: replaying events cannot rewind a task that already advanced. Per-session topics also turn a queueing problem into an index problem, which is why the RocksDB swap matters more than the abstraction on top. The latency figures are vendor load tests without published message size or hardware, so read them as a shape rather than a benchmark.