ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Viber Media: All content tagged as Viber Media in NoSQL databases and polyglot persistence

MongoDB at Viber Media: The Platform Enabling Free Phone Calls and Text Messaging for Over 18 Million Active Users

Back in November there has been quite a bit of buzz around MongoDB being behind Viber Media’s technology for free phone calls and text messaging. Understandingly so, considering we are talking about a platform with more than 18 million active users talking for more than 11 million minutes every day—and these numbers have probably grown quite a bit over the holiday season.

The nice folks from Viber Media[1] have been kind enough to share more details about their platform and the way MongoDB is used. Here is the complete exchange:

Q: Could you briefly describe how your application works so we could better understand where MongoDB fit into your architecture?

Viber’s mobile clients connect to a central service that can route messages to other such clients. These messages can either be text messages or “signals” for establishing a phone call. These front-end servers use MongoDB as a common data-store. We store variable length documents that include dictionaries.

Q: What were the main reasons that led you to use MongoDB? Were there other solutions that you’ve been tempted to use for your architecture?

We started with a proprietary code, but with the large increase in the number of new registrations per day, we realized that we needed a database that will be both scalable and redundant. At that time, this was the only database that looked like a good fit for both.

Q: The announcement mentioned that currently your clusters run on 130 nodes in the Amazon cloud. Could you describe the deployment and what components of the Amazon cloud are involved?

We have 65 MongoDB shards. Each shard consists of a master and a slave. A single EC2 instance is used for running arbiters for all shards. We are using a RAID5 (moving to RAID10) volume consisting of 6 EBS volumes for each MongoDB machine. All instances are m2x.large but we plan to migrate into larger instances.

More Amazon technology at work:

  • we are using ELB as a front-end for our proprietary load-balancers and for off-loading HTTPS processing
  • we are using S3 for storing pictures sent between users.

Q: How do you monitor your MongoDB cluster? Are there people in your team dedicated to managing the MongoDB cluster?

We have a small team to support our application and MongoDB cluster (we’re looking for MongoDB admins, BTW). We use our own monitoring server to monitor both cluster and a 10Gen MMS (Mongo Monitoring Service) to solely monitor MongoDB.

Q: Your platform has seen amazing growth reaching 18 mil. active users in less than 1 year. What has this growth meant in terms of evolving and managing the MongoDB deployment?

Hard work :). MongoDB has been very useful for increasing our reach to active users. Our exact methods are proprietary and therefore cannot be disclosed.

Q: What were the most notable moments in the evolution of your MongoDB cluster? Has it seen any radical changes over the time? Did you have to migrate your cluster to newer versions of MongoDB, etc.?

We have migrated versions from 1.7.6 to 1.8 and now to 2.0. We are still having a few problems with the last version, but we keep improving all the time.

Q: Were there any (major) bumps in the road with MongoDB? Or differently put, are there areas in which you’d like to see MongoDB improving?

  1. The database of the config server is not recovering (no master-slave). This misunderstanding has caused us to have 24 hours’ downtime with Viber at the beginning.
  2. The memory consumption of MongoDB is too high.

Thanks guys and good luck growing your platform!


  1. My thanks also to Meghan Gill and Darah Roslyn which helped getting this interview.  

Original title and link: MongoDB at Viber Media: The Platform Enabling Free Phone Calls and Text Messaging for Over 18 Million Active Users (NoSQL database©myNoSQL)