MongoDB Atlas Customer Spotlight: Checkr

Jay Gordon
November 18, 2016 | Updated: June 1, 2021
#Customer Stories#Cloud

MongoDB Atlas continues to explode in popularity amongst our users. One of the big reasons MongoDB has grown to be the fourth largest database in the world is the desire by users to share their successes on implementation.

Checkr is a company that provides an API that assists businesses in performing modern and compliant background checks. Their discovery and eventual migration to Atlas was recently shared with the internet by Sašo Matejina of the Checkr team.

Checkr

The blog post "MongoDB cluster migration with zero downtime" provides a detailed idea of why they decided to make this change to Atlas and even includes additional software written in Go by Sašo and his team. I got a chance to catch up with Sašo recently to discuss his blog post and some other thoughts on his migration, open source software and MongoDB Atlas.

Jay: How long have you been working with MongoDB personally and at Checkr?

Saso: I started using MongoDB in 2010 right after it shifted its model to open source. So for the last couple of years I used, deployed and managed MongoDB at different scales. Checkr was built using MongoDB from the start and we are actively using it with our microservices.

Jay: What was your most compelling reason to switch to Atlas?

Sašo: We started evaluating the product a couple of months ago, and we were satisfied with easy management and possibility to scale our clusters with a click of a button, flexibility on storage and securing our data with on-rest encryption.

Jay: Talk to me about your support experience a bit. Did you need to reach out to our team? What was it like?

Sašo: We were quite active on support channels as our migration required some special permissions that were not available in Atlas at the time. Support was helpful, and we like that the Atlas team listened to us and made the necessary product changes.

Jay: What's your favorite feature of MongoDB Atlas?

Sašo: I would go with ease of management and scaling. But there are a lot of other cool features like access control with support for teams, alerting on host type. But there are also some features we would like to see in the future like slow query log and index management.

Jay: How do you feel about the performance you see with Atlas?

Sašo: Performance is good, and web interface is very responsive.

Jay: You wrote a wrapper to sync additional data after your data import, was this your first open source project?

Sašo: I've done and contributed to open source before. We are all using open source every day and it's important and it feels good to give something back to the community.

Jay: Would you recommend MongoDB Atlas as an alternative to any existing MongoDB as a services that exist?

Sašo: I would recommend it because I think it provides a good product with competitive pricing.

Great to hear about another successful migration. Tell me more about yours! Email us at cloud-tam@mongodb.com and share your success!

About the Author - Jay Gordon

Jay is a Technical Account Manager with MongoDB and is available via our chat to discuss MongoDB Cloud Products at https://cloud.mongodb.com.

← Previous

MongoDB 3.2.11-rc1 is released

MongoDB 3.2.11-rc1 is out and is ready for testing. This is a release candidate containing only fixes since 3.2.11. The next stable release 3.2.11 will be a recommended upgrade for all 3.2 users. Fixed in this release: SERVER-24662 Update to PCRE 8.39 SERVER-25145 During rollback (or w/minvalid invalid) select sync source based on end OpTime SERVER-25715 Stop leaking WiredTigerSessions at shutdown SERVER-25994 Allow applyOps to validate authorization permissions at the operation level SERVER-26182 3.2 node syncing from a 3.0 node can crash due to too-large BSON during upconversion to find command reply SERVER-26365 mergeChunks fails with empty error message if merging chunks that were moved SERVER-26652 Invalid definitions in systemd configuration for debian SERVER-26737 Segmentation fault in mongos at shutdown due to unconstructed ClientCursorManager SERVER-26753 Minor speed regression (13%) and 'choppy' performance in 3.4 vs 3.2 SERVER-26898 _migrateClone may hold WT snapshot for a long time WT-3000 Missing log records in recovery when crashing after a log file switch All Issues | Downloads As always, please let us know of any issues. -- The MongoDB Team

November 16, 2016
Next →

How Edenlab Built a High-Load, Low-Code FHIR Server to Deliver Healthcare for 40 Million Plus Patients

The Kodjin FHIR server has speed and scale in its DNA. Edenlab, the Ukrainian company behind Kodjin , built our original FHIR solution to digitize and service the entire Ukrainian national health system. The learnings and technologies from that project informed our development of the Kodjin FHIR server. At Edenlab, we have always been driven by our passion for building solutions that excel in speed and scale. With Kodjin, we have embraced a modern tech stack to deliver unparalleled performance that can handle the demands of large-scale healthcare systems, providing efficient data management and seamless interoperability. Eugene Yesakov, Solution Architect, Author of Kodjin Built for speed and scale While most healthcare projects involve handling large volumes of data, including patient records, medical images, and sensor data, the Kodjin FHIR server is based on a system developed to handle tens of millions of patient records and thousands of requests per second, to ensure timely access and efficient decision-making for a population of over 40 million people. And all of this information had to be processed and exchanged in real-time or near real-time, without delays or bottlenecks. This article will explore some of the architectural decisions the Edenlab team took when building Kodjin, specifically the role MongoDB played in enhancing performance and ensuring scalability. We will examine the benefits of leveraging MongoDB's scalability, flexibility, and robust querying capabilities, as well as its ability to handle the increasing velocity and volume of healthcare data without compromising performance. About Kodjin FHIR server Kodjin is an ONC-certified and HIPAA-compliant FHIR Server that offers hassle-free healthcare data management. It has been designed to meet the growing demands of healthcare projects, allowing for the efficient handling of increasing data volumes and concurrent requests. Its architecture, built on a horizontally scalable microservices approach, utilizes cutting-edge technologies such as the Rust programming language, MongoDB, ElasticSearch, Kafka, and Kubernetes. These technologies enable Kodjin to provide users with a low-code approach while harnessing the full potential of the FHIR specification. A deeper dive into the architecture approach - the role of MongoDB in Kodjin When deciding on the technology stack for the Kodjin FHIR Server, the Edenlab team knew that a document database would be required to serve as a transactional data store. In an FHIR Server, a transactional data store ensures that data operations occur in an atomic and consistent manner, allowing for the integrity and reliability of the data. Document databases are well-suited for this purpose as they provide a flexible schema and allow for storing complex data structures, such as those found in FHIR data. FHIR resources are represented in a hierarchical structure and can be quite intricate, with nested elements and relationships. Document databases, like MongoDB, excel at handling such complex and hierarchical data structures, making them an ideal choice for storing FHIR data. In addition to supporting document storage, the Edenlab team needed the chosen database to provide transactional capabilities for FHIR data operations. FHIR transactions, which encompass a set of related data operations that should either succeed or fail as a whole, are essential for maintaining data consistency and integrity. They can also be used to roll back changes if any part of the transaction fails. MongoDB provides support for multi-document transactions , enabling atomic operations across multiple documents within a single transaction. This aligns well with the transactional requirements of FHIR data and ensures data consistency in Kodjin. Implementation of GridFS as a storage for the terminologies in Terminology service Terminology service plays a vital role in FHIR projects, requiring a reliable and efficient storage solution for terminologies used. Kodjin employs GridFS , a file system within MongoDB designed for storing large files, which makes it ideal to handle terminologies. GridFS offers a convenient way to store and manage terminology files, ensuring easy accessibility and seamless integration within the FHIR ecosystem. By utilizing MongoDB's GridFS, Kodjin ensures efficient storage and retrieval of terminologies, enhancing the overall functionality of the terminology service. Kodjin FHIR server performance To evaluate the efficiency and responsiveness of the Kodjin FHIR server in various scenarios we conducted multiple performance tests using Locust, an open-source load testing tool. One of the performance metrics measured was the retrieval of resources by their unique ids using the GET by ID operation. Kodjin with MongoDB achieved a performance of 1721.8 requests per second (RPS) for this operation. This indicates that the server can efficiently retrieve specific resources, enabling quick access to desired data. The search operation, which involves querying ElasticSearch to obtain the ids of the searched resources and retrieving them from MongoDB, exhibited a performance of 1896.4 RPS. This highlights the effectiveness of polyglot persistence in Kodjin, leveraging ElasticSearch for fast and efficient search queries and MongoDB for resource retrieval. The system demonstrated its ability to process search queries and retrieve relevant results promptly. In terms of resource creation, Kodjin with MongoDB showed a performance of 1405.6 RPS for POST resource operations. This signifies that the system can effectively handle numerous resource-creation requests. The efficient processing and insertion of new resources into the MongoDB database ensure seamless data persistence and scalability. Overall, the performance tests confirm that Kodjin with MongoDB delivers efficient and responsive performance across various FHIR operations. The high RPS values obtained demonstrate the system's capability to handle significant workloads and provide timely access to resources through GET by ID, search, and POST operations. Conclusion Kodjin leverages a modern tech stack including Rust, Kafka, and Kubernetes to deliver the highest levels of performance. At the heart of Kodjin is MongoDB, which serves as a transactional data store. MongoDB's capabilities, such as multi-document transactions and flexible schema, ensure the integrity and consistency of FHIR data operations. The utilization of GridFS within MongoDB ensures efficient storage and retrieval of terminologies, optimizing the functionality of the Terminology service. To experience the power and potential of the Kodjin FHIR server firsthand, we invite you to contact the Edenlab team for a demo. For more information On MongoDB’s work in healthcare, and to understand why the world’s largest healthcare companies trust MongoDB, read our whitepaper on radical interoperability .

May 31, 2023