And it started to perform quite slow, way too slow. It was taking us more than two weeks to reprocess everyone in our entire matching system. And that was way, way too long for our customer.

So since we migrated to the MongoDB data storage solution, we achieved amazing results. We were able to reduce or decrease the processing time to match by 95% plus, from two plus weeks to less than 12 hours on $3 billion plus potential matches that we created every single day. In terms of the key performance metrics, compared to a year ago, we are seeing about 30% increase in two-way communication, 50% increase in the paid subscribers, and 60% plus increase in traffic growth, in terms of the unique visitors and visits.

So today’s talk is about our compatibility matching system, and how and why we rebuilt it on MongoDB data storage solution, and a lesson we learned along the way. Then, I will talk about the old system, how it was architected, and where we ran into problems. Then, I will talk about the new system, our requirements, and the technology we evaluated, and why we selected the MongoDB solution. And finally, I will discuss some of the lessons we learned during the MongoDB transition and some of the new cases we plan to use MongoDB for.

So eHarmony’s secret sauce is our compatibility matching system. It consists of a very sophisticated three tier process. The compatibility matching models identify potential matches based on your core compatibility, derived from the 29 dimensions of personality and psychology traits and based on your user set of preferences as well.

So for today’s agenda, first I will talk about our compatibility matching system, which is the key to generating all those happy couples and satisfied marriages that I was talking about earlier

The affinity matching models predicts the probability of communication between two people. That is, will these two people connect, or want to connect, even though the two people are very compatible, because they have similar interests, they have similar beliefs, they have similar values. However, they may not want to connect because of other reasons.

It helps to ensure that we deliver the right matches to the right user at the right time and to deliver as many matches as possible across our entire active network

For example, they could be completely different age groups. One person could be 30, the other person could be 60. You know, like Donald Sterling, for example. That’s a bad example, by the way. I didn’t mean to refer to Donald Sterling.

Or they could live about 3,000 miles apart. She lives in Los Angeles, and her soulmate lives http://www.besthookupwebsites.org/tr/whatsyourprice-inceleme in New York. So that’s way too far, right? 3,000 miles apart. But also, they may not be attractive to one another. So this leads to the last process, which is our match distribution model.

So, for the purpose of today’s talk, I will stay mostly on the compatibility matching system, allowing us to focus a lot more on the usage of the MongoDB solution. So the compatibility matching system is a two-step process. So traditional search is uni-directional, right? To understand how it works, let’s take a look at Nikki as an example.

In this particular scenario, Nikki’s in the ple. All that really matters in the uni-directional search is to return the toaster that meets the criteria that Nikki had specified. And whichever toaster, she gets to take it home. The poor toasters have no choice in this matter.