System Requirements

Functional

1. Users can schedule tasks
2. Users can schedule recurring tasks with different possible recurring frequency for example, every day, every week, every year etc.
3. Users can also set the time of a task
4. Users can add sub-tasks to a task
5. Users can set the priority of a task
6. Users can add notes to a task
7. Users will receive a notification when the task is due
8. Users should be able to make their own profile and store their task there

Non-Functional

1. Scalability
   1. Service should be able to handle a growing user base with more to be added in the future
2. Reliability
   1. Tasks should be stored reliably and never be lost
   2. Data should be replicated multiple times over to provide redundancy
3. Latency
   1. Notification for tasks should arrive promptly and not be late
   2. Notification should be sent no matter what

Capacity Estimation

1. We assume we deal with 1 million daily active users
2. We assume that each user creates 10 tasks on average every day
3. In a day, we create 10^6 * 10 = 10^7 tasks every day
4. We assume each task needs 1 KB data
5. Thus, amount of data generated in a day would be 10^10 bytes = 10 GB
6. Over a month, we would need 300 GB data
7. Over a year we would need 3600 GB data or 3.6 PB
8. Over 10 years we would need 36 PB data
9. Factoring in redundancy we would need roughly 200 PB data over 10 years

API Design

1. /tasks/create
   1. POST
   2. Takes in a JSON as arguments which would describe the task, its title, frequency if it reoccurs, description, sub-tasks, due date etc.
   3. Returns the unique task ID
2. /tasks/update
   1. PUT
   2. Takes in a JSON as argument and updates a previously created task
   3. Returns success in case the task is updated, error otherwise
3. /tasks/cancel
   1. DELETE
   2. Removes the specified task
4. /tasks/read
   1. GET
   2. Returns the description of a task

Database Design

1. Consistency is important when executing tasks accurately, thus, we go with a relational database

classDiagram

class tasks {

taskID

userID

executionDataTime

recurringPeriod

description

priority

}

High-Level Design

1. Scheduler service stores tasks in a relational database
2. Task Runner reads the stored tasks and in case a notification needs to be sent, it adds a notification to be sent to a user in a message queue which is then sent to the user
3. Email sender takes in the message from the queue and sends en email to the user

Request Flows

Detailed Component Design

1. We can have a priority queue where the priority of a task is based on the time of a task, a task for which a notification needs to be sent next has the highest priority
2. We can keep checking the top of the queue against the current time, if the current time matches that on the message at the top of the queue, we trigger a notification

Trade Offs/Tech Choices

1. For the relational database, we use PostgreSQL
2. For our message queue, we use Apache Kafka
3. We do not choose a non-relational database since relational databases provide better consistency

Failure Scenarios/Bottlenecks

1. Notification or payment fails. Retry N times using the Message Queue. After that, notify the user of failure. 

Future Improvements