Mattron Entertainment was a gaming startup run by a lean team, with two board members who brought long industry experience. It had released two multiplayer games, The Real Mah Jongg and The Real Canasta, each of which ran on its own website and in the app store. The main application was a real-time Ruby on Rails app hosted on Heroku, using the Action Cable websocket layer, with additional game servers on DigitalOcean and a MongoDB database. The team also used AnyCable, a Go library, to handle socket communication. Builds relied on custom buildpacks for dependent libraries, with the main application built and hosted on Heroku.
Heroku's shared hosting produced performance inconsistencies in Mattron's applications, showing up as uneven CPU usage. The available fix, dedicated dynos, was expensive, and the performance issues persisted anyway, so the team felt it was not getting enough value from the spend. Application scaling had become a cost problem. The custom buildpacks made it hard to integrate everything on one platform. Third-party services the games depended on required subscription upgrades for even minor performance improvements and brought scalability issues of their own. Running the websocket adapter and AnyCable alongside the Heroku hosting package was a challenge. Building on AWS ECS from scratch looked complicated, and the team wanted a smaller learning curve.
Planning its Heroku migration, Mattron found Convox as a way to run on AWS ECS without building the platform layer from scratch. The setup was fast: the team stood up its production environment on Convox in one weekend, with much better control over the system's configuration. Moving to Convox also ended the reliance on the custom buildpacks that had made integration difficult. Once running, the team found the new system reliable and adapted its applications to the platform quickly.
The performance gain Mattron quantified came from AnyCable, the Go library the team used for socket communication in its real-time multiplayer games. AnyCable helped the team reduce CPU usage by around 80%. The credit for that number belongs to the library itself; Convox's contribution was operational. Running AnyCable and the websocket adapter had been difficult alongside the Heroku hosting package, and Convox's infrastructure simplified the team's use of the library, which made the reduction achievable in production.
The migration was tested quickly. Soon after the migration, demand for online games rose sharply, and Mattron's founder credited the Convox migration as critical to the startup's ability to thrive through that period. Convox's infrastructure supported autoscaling, and the team reported scaling to meet rapidly growing online user numbers while holding expenses roughly flat. Overall application performance improved at a lower cost than the previous stack, and Mattron kept the granular control it needed to work through scalability issues as they came up. The platform delivered what the team had gone looking for, and proved it through an unplanned surge in player demand: ease of use, elastic capacity, and the performance to sustain the business.
First, the 80% CPU reduction came from AnyCable; Convox made the library practical to run in production, but the number is AnyCable's. Second, this migration dates to Convox's Amazon ECS generation, per the original case study. Convox has since moved to Kubernetes, running in the customer's own cloud account (on AWS, where Mattron ran, that means EKS), so a team following Mattron's path today would get application scaling through Kubernetes autoscaling rather than ECS. The client-side facts here, including the CPU number and the one-weekend setup, come from the original case study written at the time of the migration and describe that period rather than the startup's current state.
