Building a Maker-checker system with audit trail
Hevo is scaling rapidly, we now have 300+ customers across 40+ countries. Therefore, it has become difficult to keep up with the customers’ demands. Hevo’s internal teams have to increasingly execute a lot of critical customer-related operations and monitor the services provided by Hevo every week.
This gave rise to the Control Tower team. The purpose was to build tools to help the internal teams in APM(Application Performance Management) as well as executing customer-related operations. Alfred was built for executing customer-related operations like billing, account management, pipeline management, etc. across all deployments(environments) for all customer teams.
Hevo also has to ensure that these operations are executed accurately and rightfully. To prevent errors as well as incorrect use of these operations, we came up with an idea to build a maker-checker system in Alfred.
Maker-checker is an authorization workflow that ensures that at least 2 people are involved in a transaction. A Maker is responsible for making the request and a checker is responsible for approving the request. The segregation of duties in maker-checker helps keep a strict check over the use of software and data.
For keeping track of all the operations performed using maker-checker, we decided to have an audit trail of them in the application DB. An audit trail is a series of records or events about user activities on an application. Therefore, all maker-checker requests made on Alfred are logged as well as persisted in the DB.
Use case example
An employee wants to execute a billing waiver operation for a customer.
S/he will undertake the following steps:
- S/he makes the request for the action with the relevant parameters and their values.
2. S/he selects the checker for the request and specifies the purpose behind making the request.
3. The checker receives an email having details about the action and the configured parameters. The checker can either decline or accept the request via buttons available in the mail or in the past requests tab in the Alfred app.
4. A notification mail is sent to the maker regarding the outcome. i.e whether the request was accepted and executed successfully or the request was declined.
Detailed Flow:
Whenever the maker makes a request, the request details are stored in a table in the DB. The request status is marked as PENDING. An email with these details is sent to the checker.
For the checker to accept/decline the request, he/she is required to login into the app or he/she needs to have the cookie of his/her existing login in the browser. This ensures the accept/decline action can’t be undertaken by anyone except the checker.
If the checker accepts the request, it gets executed. If the execution is successful, it is marked as FINISHED. If the execution fails, it is marked as FAILED. The success/error message, status, and response data(if any) are also stored.
If the checker declines the request, the request is marked as DECLINED.
The accept() flow uses the Factory design pattern for determining the appropriate execution flow of the request based on the type of the request. Using the factory pattern enables us to have a single resource for handling all types of requests.
Other features:
- Past Requests Tab
All users of the Alfred app can view all the past maker-checker requests with their details in this tab. These details are retrieved from the database and can be filtered on the basis of environment, team(customer), maker, checker, request types, and status. They are always ordered by the time of creation.
2. Maker is allowed to cancel the request before the checker takes a decision or notify the checker if he does not respond on time.
3. In case the request is declined or fails after being accepted, the maker can make a duplicate request.
Next Steps
In order to ensure faster response from the checker, we can have an option for sending a slack notification as well when the maker makes a request along with an option of automatically resending the request notification after a fixed time duration in the case where the checker has not responded.
Alfred’s motivation has always been to reduce the turnaround time for any tickets or requests raised by our customers. With this in mind, we plan to build multiple dashboards that can help visualize important information depending on the particular problem. By categorizing this information at a generic problem level we hope to increase the efficiency of our support team.
