Recently we reached a big milestone by surpassing eight million – yes, you read that correctly – 8,000,000+ calling minutes delivered by our Revere Calling tool between January 20, 2017 and January 20, 2018.

Because this milestone means so much to us, we’d like to share a little about the technology that powers all the phone calls behind those minutes.

We introduced our rebuilt version of Revere Calling in February 2014 using Ruby on Rails as our preferred framework. With the size of the team and the support of the Rails community, we knew it would be a great decision to introduce Ruby to our technology stack. The majestic Rails monolith allowed us to stay incredibly nimble by handling 90% of common development pitfalls and allowing us to release early and often.

In the first eighteen months, we were able to consistently connect people with their legislators without much of a hitch. Little did we know that the summer of 2015 would push the limits of calling technology.

In June of 2015, we introduced the Bernie Sanders campaign team to Revere Calling. We launched their first Calling campaign by sending an action to everyone on Bernie’s email list. Most people received their emails over their lunch break; within minutes of the email reaching inboxes, we saw a huge spike of calling activity as high as 50 times the normal amount of phone calls we were previously processing. When this happened, we noticed our database was taking most of the hit, and we were running out of memory very quickly. We were processing anywhere from 10 – 50 simultaneous calls. This doesn’t sound significant, but it meant we were using 100 times more resources than our normal volume of five calls at a time. As a short-term fix, we upped our database resources, but we knew problems would continue if we didn’t make architecture decisions quickly.

To bring stability to the platform, we decided the best route was to introduce a new layer of caching that did more than store repetitive database queries. It also cached live phone call data so we didn’t have to request this information from the database. We could read the cache and store it in the database after the phone call ended. The results were phenomenal. The new caching layer removed 90% of repetitive queries to the main database and improved our caller response times.

The second improvement we made to the system was to break up smaller pieces and move them to microservices. This was not to get away from our nice, mystic Rails monolith, but to separate bits and pieces of the platform into their own mini services that can run independently. For example, one part of our Calling platform manages content that defines phone calls. Independent of that piece, there is another that processes the phone call. The result is a significant improvement on performance. We’ve applied this same methodology to some of our other technology. By the time 2017’s onslaught against progressive values began, Revere Calling was ready.

With the new caching system and microservice architecture in place, we’ve seen a huge performance improvement in Revere Calling, while giving activists a consistently great calling experience. We also maintain our own proprietary contact database that we frequently audit for accuracy.

Continuing to build on top of those updates allowed us to have an amazing start to 2017 delivering over eight million (8,000,000) call minutes since the beginning of the year. Ruby on Rails gave us our start and inspired us to build even better tools in our Revere platform.