AWS re:Invent 2025 - Scaling MONOPOLY GO! to millions with DynamoDB & ElastiCache (DAT324)

Scaling MONOPOLY GO! to Millions with DynamoDB & ElastiCache

Overview

• Presentation by Brandon from Scopely, a long-time AWS customer and early adopter of DynamoDB and serverless technologies
• Covers how Scopely scaled their massively popular mobile game "MONOPOLY GO!" to over 1 million concurrent users using AWS database services

Reliability at Scale

• Reasons for choosing DynamoDB over MySQL:
  • DynamoDB has no single writer bottleneck like Aurora MySQL
  • Avoids MySQL connection limit issues when scaling to thousands of hosts
  • DynamoDB prevents uncontrolled queries that can bring down the database
  • No need for disruptive cluster upgrades with DynamoDB
• MONOPOLY GO! has sudden load spikes when in-game events start
  • Traffic can triple in 5 minutes, with individual DynamoDB tables spiking from 0 to 100,000 RW units/sec
  • DynamoDB's on-demand mode and pre-warming API allow handling these load spikes without throttling
  • Other services like ElastiCache Serverless and Auto Scaling groups are also leveraged to handle sudden load

Cost Optimization

• One of the biggest cost drivers is the size of DynamoDB items
  • Larger items incur higher read/write unit costs, even for small changes
  • Scopely built custom metrics to track average, min, and max item sizes
  • Optimized a "friend invitations" table by changing the data model to use one item per invitation instead of a large JSON blob
  • This reduced costs from 1-200 write units per write to a fixed 2 write units

Operational Simplicity

• Scopely wanted to avoid manual database maintenance and scaling
• Replaced self-managed Redis clusters with ElastiCache Serverless
  • Eliminated the need to manually scale and provision Redis clusters
  • Resulted in a 61% cost savings by avoiding over-provisioning
  • Some minor outages during early adoption, but AWS resolved the issues

Key Takeaways

• DynamoDB's on-demand scaling and pre-warming capabilities are critical for handling sudden load spikes in games and other applications
• Carefully monitoring and optimizing DynamoDB item sizes can lead to significant cost savings
• Managed database services like ElastiCache Serverless can simplify operations and provide cost benefits by auto-scaling behind the scenes

Technical Details

• MONOPOLY GO! architecture:
  • Unity client with C# frontend
  • .NET server-side application also using C#
  • DynamoDB for user data that scales with number of users
  • MySQL for configuration data that scales with number of employees
  • Redis (replaced with ElastiCache Serverless) for leaderboards and temporary job state
• DynamoDB strategies:
  • Launch new tables in on-demand mode and pre-warm them
  • Monitor item sizes and optimize data models to reduce costs
  • Ability to switch between on-demand and provisioned modes up to 4 times per day
• ElastiCache Serverless:
  • Eliminated need for manual Redis cluster scaling and provisioning
  • Resulted in 61% cost savings by avoiding over-provisioning

Business Impact

• MONOPOLY GO! became the #1 game in its category, growing to over 1 million concurrent users
• Scopely was able to scale the game's infrastructure to handle this massive growth without disruption
• Cost optimization efforts led to significant savings, with the ElastiCache Serverless migration alone reducing costs by 61%
• Scopely's engineers could focus on building new features rather than managing database infrastructure

Examples

• Friend invitations table optimization:
  • Old model: One item per user containing all their invitations as a large JSON blob
  • New model: One item per invitation, with a local secondary index to query the most recent ones
  • Reduced write costs from 1-200 units to a fixed 2 units per write
  • Reduced read costs from 1-50 units to 1-2 units per read by only querying the most recent invitations