Aptela- Replication and Scaling with CouchDB
Situation
The Aptela platform achieves massive scalability by dynamically distributing load across all available nodes using REST-based APIs. These APIs power a host of applications ranging from simple phone widgets to complex web-based applications. The APIs also cover all telephony interactions, ranging from routing phone calls to delivering intricate auto-attendants.
The distributed nature of Aptela's platform allows for consistent and extremely scalable access to data across all the nodes. Furthermore the telephony side of the
platform requires the ability to operate in a quasi-disconnected mode, i.e., realtime access to other nodes cannot be guaranteed. Aptela needed to address the additional burden of the volume of data being generated - millions of Call Detail Records (CDRs) are generated daily, all of which have to be accessible in near-real time.
Previous iterations of the Aptela platform have used everything from the file system to SQL databases (Oracle/Postgres/MySQL) to provide persistence. Each of these worked up to a point, but the joint imperatives of performance, manageability, maintainability, cost and (massive) scalability invariably took its toll.
Solution
Initially, Aptela's developers were considering using CouchDB solely for reporting, with the schema-less design proving particularly useful when every day seemed to bring a new reporting requirement. It proved to be such a perfect fit that it ended up replacing most of the existing "centralized data store" based persistence requirements - and should shortly be the only persistence used by the Aptela platform. Its REST-based API fits transparently into the Aptela infrastructure, and its Erlang code-base didn't hurt either (Aptela is an Erlang/OTP based platform). In the final implementation, replicated instances of CouchDB are scattered across
a variety of nodes, with the documents being replicated dependent on the function of the node. For example, all profile information (contacts, speed-dial, etc.) are
replicated across all application nodes for maximum performance.
Results
The results have been striking. What started off as a simple point solution - moving reporting to CouchDB - has now ended up with the migration of the entire persistence infrastructure. Reliability has been exceptional and performance management has become somewhat trivial, with replication solving a lot of performance issues. The only hurdle now is finding the time to migrate the rest of the persistence infrastructure to CouchDB.
