Scheduler System Design
Background
There are business use cases where domains are required to execute business operations periodically or at certain time in future as per configured business rules.
The following list captures few such use cases:
- Send reminder emails periodically to customers for completing onboarding process if they drop off.
- Cancel the membership subscription based on expiry date.
- Send periodic mails to customers for renewing the membership for 3 successive months.
- Issue new Credit Card upon expiry date.
Product Requirements
- A domain should be able to Add, Update and Cancel the Schedule Job for different types of use cases.
- A domain should be able to configure one time Job and periodic Job. The periodicity can be daily, weekly, monthly or yearly.
- Schedule system should maintain historic records for ad-hoc auditing and reporting purposes.
Architectural Requirements
- The proposed solution should be re-usable so that different domains can reuse it without re-inventing the wheel.
- The proposed solution should be agnostic of business logic and use case.
- The proposed solution should be scalable and fault tolerant.
High Level Architecture
The high level approach is depicted in following diagram:
In this architecture, the main responsibility of the Scheduler System is to provide a Trigger / Callback to the domain service at specified time so that domain can take the necessary action. This way business logic remains part of domain and Scheduler System is reusable by multiple business domains.
The responsibilities of these components can be described as below:
Domains
Domain will call the Scheduler System APIs for adding the schedule with required trigger details, business operation name and the payload that contains the required details for executing the business operation.
Scheduler System
Scheduler System will manage the schedules and will notify the respective domains based on the trigger configuration at specified time so that domain works can take appropriate actions.
Scheduler publishes the Events (Kafka etc) for notification that is later subscribed by Domain worker.
This architecture allows each domain to have their own dedicated topic and workers who subscribe the their own Schedule Tasks.
Domain Workers
Domain workers subscribes to the Schedule Task and knows exactly what to do with the payload that is available as part of the Schedule Task Event.
Domain Model
Domains define Task Template that is later used by Scheduler to create specific Task instance as per triggers (e.g. daily). Task gets executed at specified time and have its own status for tracking.
Job config can be used to define domain specific configuration such as topic names for event publishing.
Job config can also be used to define Json Schema for ensuring the payload is always as expected.
Detailed Design
The responsibilities of Scheduler System’s components can be described as below:
Scheduler Service
This service exposes the APIs for adding, updating and cancelling the Schedule Jobs.
Schedule Task Status Subscriber
This subscribers listens the event from worker node and update the status of the Schedule Task in the database.
This component is optional and can be used when system is expected to be highly reliable and fault tolerant. For example, If Task Status is marked as Failed then Schedule Manager will re-queue the failed task again for execution.
Schedule Manager
This component periodically scan the data source and creates the Schedule Task from the Task Template based on the Trigger.
Why Not Batch Processing
The batch processing can be another type of solution for type of problems but there are following reasons for not using it.
- Batches uses the pull model where data for processing is fetched from data sources but in this case, responsibility of scheduling is with Domains who uses the push model for creating the jobs on-demand based on business rules.
- Batches are usually aware of the business logic but in this case, Scheduler is being used purely as infra module and primary responsibility is to notify/callback the domain services for performing operations.
- Batches are not suitable when tasks are required to performed per customer each having different trigger point e.g. Notify customer A on 1st Jan 2022, Notify customer B on 13th Jan 2022 and Notify customer C on 1st Feb 2022 and in such case, Scheduler works perfectly as Domain can schedule Job as needed.
