How SteppeChange used MongoDB Zones to build a Global Mobile Customer Engagement Platform for 220 million users in the hybrid cloud

SteppeChange is a big data analytics technology firm that designs and implements client-tailored, fast-to-market data science and technology solutions. They work with clients around the world to find innovative answers to challenging problems and allocate analytical effort where it will create the most value.

Gregory Rayzman, CTO and Chief Data Architect at SteppeChange shares how and why the company relies on MongoDB for a variety of solutions, including an extendable mobile customer engagement platform for 220 million global users.

A Complex Task

A global technology company hired us to build a mobile customer engagement platform to be used by mobile operators around the world. The second we were assigned the project, we knew we were up for a challenge as different countries have vastly different data management laws. While one country might require that all data be encrypted at rest, another might require that all data is stored within their country boundaries.

Our goal was to build a platform with a single code-base, all while balancing multiple data management requirements and meeting the needs of an expected user base of 220 million subscribers globally.

Design Options

Finding a system that would meet varying data management requirements governed by multiple countries was of utmost importance when evaluating database options. After surveying a number of different options including relational players like MySQL and PostgreSQL, and NoSQL players like Cassandra and Couchbase, we quickly realized that MongoDB Enterprise Advanced provided the flexibility, scalability, and agility we needed.

The Zones feature in MongoDB is critical to our application. With it, we can break data from MongoDB collections into multiple shards and assign each shard to a zone associated with a specific geographic location. Zones are part of the same cluster and can be queried globally, but the data resides at sovereign locations where local laws prevail. Not only is latency reduced with MongoDB Zones, but we are also able to scale and grow each zone independently of others.

MongoDB Cloud Manager was also a major asset in setting up and monitoring our MongoDB deployment. It allows us to visualize the ongoing state and status of all systems, troubleshoot issues, and easily perform point-in-time restores.

Our Solution

With MongoDB Zones, we separate user data for regulatory purposes and keep it under local jurisdiction. More specifically, user data resides in data centers physically located in the appropriate country, so that the application’s access to user data complies with local regulation boundaries.

We designed and set up a multi-sharded MongoDB cluster consisting of three Zones. Each Shard has three voting replicas, in addition to hidden non-voting replicas for reporting purposes, allowing the system to spread the load based on node functionality. We do this so the data pertinent to a specific jurisdiction is deployed at data centers inside the respective jurisdictional boundaries, while data that is not subject to the same regulations is deployed on AWS.

For MongoDB Zones deployed on AWS, we distribute replica set nodes across multiple AWS Availability Zones (AZs) to increase application availability and protect against AWS outages. In addition, we leverage a similar design for configuration servers — they reside in multiple AZs as well.

To guarantee compliance with security and privacy standards, we also leverage MongoDB’s native encryption. To satisfy regulations around data access, we use the auditing framework to record and log all administrative and non-administrative actions performed against the database.

SteppeChange’s deployment topology diagram

Accelerated Delivery with MongoDB

With MongoDB, we were able to quickly bring our application to market by shaving approximately six months off of our development schedule. Our team has been able to take advantage of MongoDB BSON based document storage, Binary Serializable JSON objects. It was a perfect native match to the JSON-based underlying data structure used in our app, which provides an agile approach to adding new features rapidly. We were also able to simplify our data management and remove the complexities of data migration, increasing developer productivity and allowing our engineering team to concentrate on the task at hand.

As we work towards the future, we are looking to expand our use of other features in MongoDB, like the geospatial capabilities — such as geo-fencing and geo-based offer management — and add them to our Mobile Customer Engagement Platform.

Originally published at www.mongodb.com.