How Matchitude Is Using MongoDB Atlas to Change Digital Recruiting

As the CTO of a startup, it's my job to balance our technology requirements with our resources. With global scalability in mind, I set out in search for the perfect database solution.

My partners and I recently launched Matchitude, a new recruitment platform which rethinks the experience of recruitment for both job seekers (candidates) and employers. On Matchitude, candidates create an anonymous prospectus, and employers have free access to the entire library of candidate prospecti to search through. Contact information is only exchanged after the employer sends an enquiry which the candidate accepts.

As we defined the concept of our platform, several criteria emerged that we deemed critical to our success: affordability, scalability, geospatial queries, and security. We looked at several database solutions, including the traditional SQL databases. We wanted to balance cost and scalability against ease of development, as the nature of our site evolved rapidly throughout development. Based on these requirements, we selected MongoDB Atlas due to its combined feature set and its ability to scale with us as we grow. 

Affordability

As with most startups, we have limited resources and require a smart and affordable solution. Through our research and experience, we learned the cost of running a production-level database using MongoDB Atlas is much cheaper and more efficient for us compared to other services, which could cost several hundred dollars more per month. The fact that we are spending much less money for the same performance was a big draw for us because it allows us to pass those savings directly onto the consumer. Today, our entire service lives in the cloud on Amazon Web Services (AWS), including our MongoDB Atlas clusters. This brings our operational costs down since we don't need to dedicate time or people to managing the underlying infrastructure. 

Planning for Scale 

From the beginning of our planning phase, scalability was a primary concern for us. As we scale up our marketing, we needed to know that we could go from 100 to 100,000 users without worry. We have several clusters: one multi-tenant MongoDB Atlas cluster that we use for our staging sites and other dedicated clusters for production deployments. If we suddenly acquired a million users in one week and found the need for a bigger database, we can scale up in a matter of minutes, with just a few clicks. Having this elastic scalability means we pay for IT resources only when we need it. 

We performed some load testing on an M10 instance in MongoDB Atlas—one of the smaller instance sizes—to help us more accurately forecast costs throughout our various growth stages. We wanted to figure out how much we could throw at it before we’d have to upgrade to a larger instance size. 

As it turns out, a lot! We built a test framework that added thousands of prospecti, reproduced the complex geospatial queries that employers submit, and sent off large batches of these queries in parallel requests. Our deployment barely broke a sweat, and was far from being overwhelmed.

This flexibility and scalability is reassuring; we know that we don’t have to break the bank in order to have a production-ready database. And when we grow, it will grow with us.

Geospatial Queries

Geographical location is one of our key selling points to employers and job seekers. When we were looking to build an application, we realized that we would have to either handle that in the software application or at the datastore layer. Since we like to keep our application servers small and light, finding a database that could handle geospatial queries natively was a very attractive solution. We evaluated several different options, but ultimately, we concluded MongoDB’s geospatial capabilities provided us with the most robust solution.

Using MongoDB, queries are built using JavaScript Object Notation (JSON); and that is still true for geospatial queries. As we use Node.js at many layers of our architecture, being able to use the familiar JSON we use every day to interface with our databases is a big advantage. Personally, I see huge value in not having to context switch between SQL and Javascript.

Security

Security is foundational to our platform. When we were first speccing out Matchitude, we knew that security was important as people share a lot of personal information throughout the recruitment process. That’s a core challenge of the industry that we’re trying to fix. The most basic way to start is with HTTPS; ensuring data is encrypted between the client browser and server—and that is why we only offer Matchitude.com on HTTPS.

We wanted to go much further, though, and we have carefully crafted our architecture and platform to isolate various parts of user data. When evaluating cloud-based DBaaS, it’s absolutely critical to evaluate the architecture and best practices implemented by the service provider and whether or not it protects the data between your application servers and your database. 

Since we had already settled on using MongoDB, the last choice was where it would be hosted. MongoDB has some great resources on deploying on AWS, and that was our first instinct, especially as we could hide away our database inside a private subnet in our Virtual Private Cloud (VPC).

In December 2016, MongoDB announced VPC peering for MongoDB Atlas, and that made the decision for us. We already appreciated MongoDB Atlas as a DBaaS, and now we could connect our Atlas cluster’s VPC with our own AWS VPCs, ensuring that our managed MongoDB databases were never exposed to the public internet. This shows that the Atlas team takes security seriously, and that’s important.

MongoDB Atlas Support 

We have been customers since Atlas’ beta days, and have been able to develop and grow our platform as MongoDB Atlas went to market. I feel like we have been a partner of the service from the beginning.

You don’t have to be an experienced database engineer to use MongoDB Atlas, and the MongoDB team is welcoming to all, encouraging, and always developing new functionality.

For example, in the early days of our product, we were interested in creating a completely serverless architecture built on AWS Lambda. One of the first things we tried when we signed up for the Atlas beta was to evaluate how well it would perform when being accessed from a Lambda function on AWS. After testing, we determined that it wouldn’t work for us. The combination of MongoDB's authentication scheme and Lambda’s short lifecycle meant that often we were seeing invocation times far beyond what we believe is acceptable latency in queries.

This has now been fixed; and we’ve seen incredible performance improvements from using AWS Lambda with MongoDB Atlas. The MongoDB Atlas team has put in a lot of time and effort addressing the idea of serverless applications and have established some best practices. A large portion of the news I hear about MongoDB Atlas is talking about using serverless applications with MongoDB as a datastore. It’s reassuring to me that MongoDB Atlas is dedicated to creating functionality and features their consumers want.

Summary

MongoDB Atlas was an easy choice when it came time to spin up our production clusters. It has a feature set that feels custom tailored to our needs, and during development we appreciated the pure flexibility of the platform.

I would recommend MongoDB Atlas to software developers who have big ideas. MongoDB Atlas takes the cognitive load off by not having to worry about physical hardware or high recurring bills.

Matchitude chose MongoDB Atlas because it is powerful, flexible, scalable, reliable, and affordable. These are exactly the qualities we need in a database-as-a-service to reinvent the way job seekers and employers are connected.