# Jobbird ATS integration ![](https://i.imgur.com/aXwbHbZ.png) ## Assumptions on existing components - All application data is stored in an existing relational database. - We already have a UI for applicants and the customers. - We already have a backend for both of these UIs. - Both UIs and the backends might be part of a monolith, residing in the same code repository, doesn't make a difference for the design. They have separate boxes in the diagram to make it easy to follow. - We can chose a most used subset of ATS systems in the beginning and they have the same API and data schema regardless of the customer. - All the data needed to call ATS APIs can be found in our existing relational database. ## New components ### ATS config in database Existing relational database DDL should be updated to allow storing ATS config for customers. Config as which ATS they use, credentials required to connect to this ATS etc. Customer UI and backend should enable CRUD operations for this config data. ### JSON message creator in the Backend for Candidate UI The existing part of the backend that accepts the application form and stores it in the database and does some other things as sending email etc. needs to do one additional thing. Which is creating a JSON message about the application for ATS integration. This message should include all the data needed for any ATS API call. This new piece of code can query the relational database to enrich the message with ATS config of the customer. ### Happy flow queue A high volume sequential queue for happy flow. JSON message should always have a `tryCount = 0` in this queue. ### Retry queue A low volume retry queue, that supports timed messages, so we can have delayed retries. JSON messages in this queue should have a `tryCount > 0`. ### ATS message consumer An independent service that can consume both sequential and timed queues and make ATS API calls accordingly. - When an API call fails, it puts the message into the retry queue after incrementing the `tryCount`. - Retry delay should be calculated based on a randomized backoff policy. - If a message reaches to an agreed threshold `tryCount`, which is roughly equivelant of 5 minutes, the message should be saved in a dead letter S3 and emails should be sent to notify stakeholders. - Too many emails can be avoided by grouping failures in memory. ### Manuall triggered script for resending messages from dead letter S3 When an ATS connection fails for a downtime and can be retried now, a support engineer can run this script to collect certain messages and put them into the sequential queue again.