Amazon Web Services (AWS)
Research & Strategy
Backend & Infrastructure Development
Interested in learning more?
Send us a message 👋
Certn is one of North America’s fastest growing background check providers. They came to Lazer for help architecting and building out a Python microservice that integrates with 3rd-party data providers they relied on for background checks.
Certn’s expected timeline for the project was 3 months - Lazer completed the work in just 1 month and was able able to drive 67% cost savings. The remaining time and budget was used to push forward other projects such as core internationalization efforts to help Certn expand faster into other markets.
We worked closely with the Certn leaders to design and develop a microservice that would exist between Certn user-facing systems and third-party data providers that they relied on for background checks. The main purpose of the system was would handle orders from users, trigger the correct background check from a data provider, and send the data back to the user once it was received.
Developing an initial game-plan
We had a three-month timeline for the project and understood there were quite a few moving parts within the system. In order to move fast and efficiently, we decided on an initial game-plan. First, we would architect the system and model the database upfront. Secondly, we would implement the foundation of the project. Lastly, we would thoroughly test the microservice.
Architecting before writing code
It’s very easy to just jump into a project, start writing code immediately, and see early progress. However with this approach you can sometimes quickly you find yourself backtracking and drastically changing logic or database models as a result of not thinking through the entire system and how all the pieces will integrate with each other.
When Lazer received the requirements for the project the first thing we tackled were the details of the microservice and all the functions needed. The best approach we found for this was creating a system architecture diagram that defines all the major flows and pieces of the system.
Having the architecture diagram not only let us be confident about the implementation but it let us easily explain it to the Certn team to gather their feedback and most importantly, see if we missed anything.
Modelling the database
As much as we want to get modelling the database right on the first pass with PostgreSQL, we knew that this would have slight modifications as we got down to implementing all the features. Putting together a quick database model allowed us to have a strong understanding of the basic relationships and tables that would exist.
Aligning on the best tech stack
The tech stack we decided to move forward with was primarily with Python, Django, and PostgreSQL. We set up empty Django apps to cover the major features of the system and then created a docker image along with a docker-compose file to build and run the project with all its dependencies. This allowed us to move quickly as Django provides a built-in admin panel and also allows to stay aligned with the the rest of Certn's system. We lastly added a Makefile that would easily allow developers to format, lint, build, test, and run the project.
Moving quickly and avoiding roadblocks
Moving quickly was extremely important. So to avoid the headaches and delays of getting access to all the tools and systems Certn, we relied on Github issues and Github Actions for CI. Once we were near the end of the project we quickly flipped over to Jenkins CI to easily integrate with Certn's CI + deployment pipeline.
Building the robust microservice to fulfill orders
Since the system relied on third-party data to fulfill orders, each background check would need to be sent to a third-party and once the third-party fulfilled the check, we would then update the user. The system we designed had two significant parts to it. First, it needed to provide Certn client-facing servers the schemas requested by each data provider. Secondly, it needed to actually fulfil the orders.
Order fulfillment from clients was asynchronous so we set up Celery task queues, with Redis as the broker, and integrated them with the Django project. This allowed us to complete work on a different process and not block any threads so user requests can be served immediately. Finally, we relied on JSON schema specifications to translate data provider forms to JSON schema objects to easily validate data forms sent by the user.
Overall, our engagement with Certn was a huge success. We were able to complete the project in 1/3rd of the expected time. And with the extra time, Certn was able to use the Lazer team to push forward other projects. Certn’s now become one of the fastest growing background check providers in North America and has expanded to Europe and Australia.