// the take
Apache RocketMQ is Alibaba's distributed messaging and streaming broker, now an Apache top-level project, built for high-throughput pub/sub with strict per-queue ordering and financial-grade transactional messages. It's for teams that need Kafka-scale throughput but also need guarantees Kafka doesn't give out of the box, like exactly-ordered queues or two-phase transactional sends.
Transactional messages and strict FIFO ordering per queue are native features, not a workaround built on partition keys the way you'd do it in Kafka. DLedger gives built-in broker HA/failover without bolting on a separate coordination service. It's proven at genuinely enormous scale (Alibaba's own peak traffic), so the million-message-per-queue accumulation claims aren't marketing. The protocol surface is unusually wide for a single broker — native gRPC client protocol plus MQTT and JMS bridges — so it can sit under IoT and legacy JMS workloads as well as normal pub/sub.
The quickstart is still manual NameServer-then-Broker startup with nohup and log tailing; there's no one-command docker-compose or single-binary path the way Kafka's KRaft mode now offers. Running it means juggling NameServer, Broker, and optionally a Controller/DLedger cluster as separate processes, with monitoring living in an entirely separate Dashboard repo. The ecosystem is scattered across a dozen satellite repos (operator, exporter, connect, per-language clients), so compatibility between them isn't guaranteed by a single release train. Client maturity is uneven — Java is clearly first-class, but the C++/Python/Node clients trail noticeably in features and release cadence.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →