"We started to use Mongo during early 2011. At that time it was one of the only scalable NoSQL databases with sharding," said Amir Ish-Shalom, system architect at Viber.

"We initially used Redis only as a caching layer for Mongo, but after a few months when our workload grew we created our own in-house Redis sharder and started to use Redis as a standalone NoSQL database alongside Mongo for workloads with over a billion keys or with higher throughput," he continued.

Viber has grown extremely rapidly. Between 2012 and 2013 the company saw a five-fold increase in messages and a tripling of talk time being carried out over the app.

After three years of this breakneck growth Viber started to find that their bespoke Mongo/Redis combination couldn't keep up. While MongoDB was fine for the tens of thousands of operations per second that the firm was undertaking in its earlier days, as the number crept into the hundreds of thousands the performance began to drop off. There was also a scalability problem as the numbers of application servers, each connected to a MongoDB cluster, grew.

As Mongo performance slowed Viber started to rely more on Redis, which as an in-memory database is very fast. But the limits of the home-built sharding system started to become clear as the traffic ramped up.

Ish-Shalom had no complaints about the service received from both Redis and MongoDB, but said for Viber's purpose Couchbase is a better fit.

"We received excellent support from both companies," he said. "Mongo and Redis are both excellent products, but neither was ideally suited to our requirements."

"We needed a single robust database solution that could perform millions of operations per second with consistent low latency on huge data sets; a database that can scale easily without any performance impact and is easy to monitor."

Ultimately Viber chose to move away from its MongoDB and Redis system to Couchbase, a NoSQL database that the firm said is easier to ramp up to large scale. In doing so it moved from an estate of 150 MongoDB servers and 100 Redis servers to one of 120 Couchbase servers, because Couchbase takes care of caching duties. However, the move took some planning.

"Migrating from one database to another on a live system with zero downtime is always difficult, especially on a system with throughputs close to a million operations per second. We had to create a six-step migration plan for each of our data clusters. The actually migration process for each data cluster took between two and four weeks," Ish-Shalom said.

To read about how Couchbase is also helping airline Ryanair mend its previous reputation for bad customer service click here.

Sometimes, the power of the mainframe is the most cost effective answer. Computing's Peter Gothard puts Computing's readers' questions on the future of the mainframe to IBM's Z13 expert Steven Dickens.