FunPlus Modernizes Real-Time Gaming Data Streaming on AWS with AutoMQ

For a global gaming company, real-time data infrastructure is part of the player experience. Player logins, in-game events, service health metrics, operational dashboards, and recommendation pipelines all depend on a stable streaming backbone. FunPlus uses Apache Kafka-compatible data pipelines for two core workloads: game observability and real-time analytics.

The game observability platform processes server-side logs, performance metrics, and alerts so engineering teams can monitor service quality across global game operations. The real-time analytics platform supports player behavior analysis, operations dashboards, and game optimization workflows. Together, these pipelines process more than seven billion messages per day.

With that traffic profile, platform efficiency was a practical operating concern, not just a cost issue. Production workloads needed multi-availability zone resilience, and demand could change quickly around new game launches, live events, and regional player activity. In broker-local storage designs, growth can bring extra storage copies, data movement, and operational steps. FunPlus wanted capacity planning and scaling to depend less on where durable data was stored.

The target architecture had to keep running on AWS, preserve Kafka protocol compatibility, support more elastic operations, and increase infrastructure efficiency without forcing application teams to rewrite producers, consumers, Flink jobs, analytics pipelines, or observability integrations.

FunPlus selected AutoMQ, an AWS Partner solution, for its Kafka-compatible streaming architecture on AWS. AutoMQ keeps the Apache Kafka protocol interface and separates long-term data persistence from broker compute.

AutoMQ uses a Diskless architecture with shared storage on Amazon S3 for durable Kafka data. Brokers run as lighter-weight compute nodes, reducing reliance on broker-local disks and broker-to-broker replication for durable data.

For FunPlus, that design addressed the operating constraints behind the project. Scaling broker compute no longer required the same level of local data movement, and maintenance work became less coupled to where durable data was stored. For gaming workloads that shift around launches, campaigns, and regional activity, this gave the infrastructure team a cleaner way to adjust capacity.

Kafka compatibility mattered because application teams already had producers, consumers, Flink workloads, analytics pipelines, and observability systems built around the Kafka client ecosystem. With AutoMQ, those clients and integrations continued to use Kafka-compatible APIs, so the migration did not require application rewrites.

Migration risk was another requirement. A streaming platform processing billions of messages per day leaves little room for a disruptive cutover. FunPlus used AutoMQ Linking to move workloads in phases while preserving offset consistency and application continuity. The team migrated topic by topic, watched each stage, and avoided a single big-bang switch across business teams.

The phased rollout let FunPlus validate non-critical workloads first, then move core analytics and observability pipelines through standard rolling deployment practices.

The migration finished with zero downtime and no application changes. Existing producers, consumers, Flink jobs, analytics pipelines, and observability systems kept operating through a Kafka-compatible interface. Application teams kept their familiar Kafka clients and workflows while the infrastructure team completed the rollout in phases.

The platform supports FunPlus's game observability and real-time analytics workloads in AWS us-west-2, processing more than seven billion messages per day. Because durable data is stored in Amazon S3 rather than bound to broker-local storage, the infrastructure team can adjust broker compute capacity and plan growth with less data movement during scaling and maintenance.

FunPlus also reduced Kafka infrastructure costs by more than 60%. The savings came from the architecture, not a short-term capacity cut: shared storage on Amazon S3 and lighter-weight brokers improved resource efficiency while preserving the Kafka-compatible experience that application teams depended on.