JD originally used Kafka, but due to the double triple-replication strategy leading to nine times data redundancy, six copies were made. By adopting AutoMQ, which directly relies on the underlying cloud storage CubeFS, the need for upper-layer replication is eliminated. The architecture is expected to save two-thirds of storage costs when fully implemented. AutoMQ's stateless computing layer perfectly meets the requirements for containerization transformation, significantly enhancing system flexibility.

Initially, Palmpay selected Kafka for its architecture, but Kafka’s limitations in resource overhead and elastic scalability became apparent. Within one month, Palmpay seamlessly migrated its business, including metrics tracking and real-time computing to AutoMQ, processing and distributing billions of messages and events daily. The new solution reduced costs by over 50% compared to the original setup, without causing any negative impacts.

Xpeng Motors originally used Apache Kafka to receive and process data such as monitoring and logs, and applied it to core scenarios such as operational data analysis, security audit compliance, etc. With the rapid development of the business, the architecture of Apache Kafka, which guarantees data persistence based on ISR multiple copies, exposed issues in terms of cost and elasticity. After seamlessly replacing it with the Apache Kafka-compatible AutoMQ, the overall cost has dropped 50%+, and it can automatically scale horizontally without the need for manual intervention.

Qianxu SI is a spatiotemporal intelligent infrastructure company. A large number of hardware terminal devices generate massive amounts of messages daily. As the company continues to grow, the cost and elasticity issues of Kafka have become increasingly severe. AutoMQ helps Qianxun Location process tens of billions of messages daily, completely resolving the operational pain points caused by Kafka's elasticity and helping the company reduce Kafka costs by over 50%.

By leveraging cloud-native architecture and tiered storage, RedKafka accommodates vast amounts of real-time data. However, the challenge lies in flexible scaling and cost optimization. AutoMQ, with its new architecture based on EBS shared storage and object storage, provides significant elasticity improvements for scaling. Its feature of separating storage and computing aligns well with current operational requirements based on Kubernetes. When combined with Red's current messaging engine architecture, it can lead to greater cost savings and efficiency gains.

Poizon used to rely on Kafka to build the observability platform, requiring a team to spend several days each quarter on scaling operations. Since adopting AutoMQ, data storage has been moved to object storage, making the compute layer stateless and fully compatible with Kafka. This has enabled automatic elastic scaling without manual intervention, significantly reducing cloud resource costs by up to 85%.

360 extensively adopts Apache Kafka internally. However, its storage-computing integrated architecture requires data migration during scaling, increasing operational burden. In contrast, AutoMQ employs a storage-computing separation architecture, storing data in object storage, eliminating the need for data migration during cluster scaling. Additionally, AutoMQ is fully compatible with Apache Kafka, effectively shielding against hardware failures, ensuring read-write traffic isolation, significantly improving operational efficiency, and reducing scaling risks.