19Aug

So there were two fundamental problems with this architecture that we needed to solve very quickly

So there were two fundamental problems with this architecture that we needed to solve very quickly

And we had to do this every single day in order to deliver fresh and accurate matches to our customers, especially one of those new matches that we deliver to you may be the love of your life

The first problem was related to the ability to perform high volume, bi-directional searches. And the second problem was the ability to persist a billion plus of potential matches at scale.

So finally, the last issue was related to since we are running on Postgres, we start using a lot of several advanced indexing techniques with a complicated table structure that was very Postgres-specific in order to optimize our query for much, much faster output

So here was our v2 architecture of the CMP application. We wanted to scale the high volume, bi-directional searches, so that we could reduce the load on the central database. So we start creating a bunch of very high-end powerful machines to host the relational Postgres database. Each one of the CMP applications was co-located with a local Postgres database server that stored a complete searchable data, so that it could perform queries locally, hence reducing the load on the central database.

So the solution worked pretty well for a couple years, but with the rapid growth of eHarmony user base, the data size became bigger, and the data model became more complex.