Dog on a HorseMobile Apps

A MongoDB Ready Partner

Woody’s Great Grandfather

Digital Trading Card Platform with Topps

Three apps that run on the same systemso far…

HUDDLE

BUNT

KICK

MLB

NFL

BPL

Collectible Card Games

Yes, That Topps

The New Trading Card

Live stats and game info

Online trading

Card sales info

Brief History of BUNT• 2012: Introduced product on MySQL

• Revenue model fine-tuned

• Thought of new features and scaling considerations

• Migrate to MongoDB for MLB 2013 opening day

• Learn MongoDB

• Re-design the schema

• Write & Run migration scripts

• Total: 4-5 months, 1-2 people

• Product Demo

• System Overview

• Specific example of why MongoDB

• One case where another database technology is used with MongoDB

• Scalability issue and resolution

Product Demo

System Overview

Server Technologies• MongoDB

• MySQL

• Redis

• Python

• AWS

• External data feed

MongoDB Basic Structure

Simple View of Server Architecture

Big Piece 1: Processing Live Data• Live data is received and stored into MySQL• A heartbeat picks up the event and stores player stats into

MongoDB• It then pulls from MongoDB and updates leaderboard data in

Redis

Big Piece 2: Formatting Leaderboards for Users• API servers combine fan data from MongoDB with points data

from Redis• The result is a richly-detailed set of leaderboards

All other processes• All other processes are handled by the API servers and MongoDB

• Sign in, Trading, Commenting, Content Management, Purchases, Playing Cards

• Storage is used for fan and player photos as well as other simple files

Big Piece 1Specific reason we

chose MongoDBProcessing Live Game Data in Realtime

Realtime Live Game Updates

• Game play requires up-to-the-minute stats from live events for user scoring

• These data are stored in JSON format for the app

• The JSON data has to be updated frequently with stats and player points

• Support multiple live games for multiple apps on the same platform

Old Way: Processing Live Game Data with MySQL

New Way: With MongoDB, we can simply update the JSON data in the player’s

document db.players.update( { _id: ObjectId(“52be0717978ca03fc1984069"), ‘games.g':'2013-e.39141 }, { $set:{ 'games.$.b': "1-for-2: Ground out, Walk, Home run" }, $inc:{ 'points': 36 } })

In general, the system with MongoDB is much simpler, faster, more

scalable

Where we use Redis with MongoDB

Leaderboards

Building User Leaderboards

• Leaderboards updated in realtime

• 96 leaderboards in BUNT

• Final output is constructed on-demand, no cache

• User scores are stored in sorted sets in Redis (ranking is automatic)

• Redis is an in-RAM key-value data store

Leaderboard Process

Scaling issue and resolution

Scaling Example: Buying Packs of Cards

• In order to support complex trading algorithms, each user profile needs to contain a reference to the owner’s card collection

Initial Structure of User Profile with Embedded Card Summary

Documents• Profile contains an

embedded document of card summaries

• When users buy cards, the profile can grow out of its allocated space

• MongoDB creates a new, bigger allocation for the user profile

Profiles were refactored to include only player IDs

• Finite number of players in the system, so size of player IDs list is limited

Basic Metrics

• On average, 1 pack sold per second

• Consistently top 10 grossing sports app

• Up to 30,000 requests per minute

• Up to 2,000 OPS

Conclusions• MongoDB great for apps, especially social

• JSON-ready data

• Normal NoSQL arguments

• For realtime leaderboards, Redis provides simple and fast “automatic sorting” of user scores

• Don’t embed documents if you hope for them to grow

• Easy to learn

We’re Hiring!

MongoDB+Py, Web, iOS, Android, App Producer, Project Management, QA