Design A Task Management Application - System Design

Requirements

Functional Requirements:

Create / update / delete tasks
Assign tasks to users or teams
Categorize tasks (tags, projects, priority)
Set deadlines and reminders
Track progress (status, % complete)
Comment and collaborate
View dashboards (My Tasks, Team Tasks, Overdue)
Receive notifications (email / push / in-app)
Search and filter tasks

Non-Functional Requirements:

Scalable to millions of users
Low latency (<200ms for most requests)
High availability
Real-time collaboration
Secure (auth, permissions)
Mobile + Web friendly UX

API Design

Create Task

Endpoint: POST /tasks
Description: Creates a new task.
Request Body:
{
  "title": "Design Database Schema",
  "description": "Create an initial database schema for the task management app",
  "due_date": "2024-06-01T12:00:00Z",
  "priority": "High",
  "category": "Development",
  "assignee_id": 12345
}
Response Body:
{
  "status": "success",
  "task_id": 1001,
  "message": "Task created successfully."
}

Update Task

Endpoint: PUT /tasks/{task_id}
Description: Updates an existing task.
Request Body:
{
  "title": "Update Database Schema",
  "description": "Refine the initial database schema based on feedback",
  "due_date": "2024-06-02T17:00:00Z",
  "priority": "Medium",
  "category": "Development",
  "assignee_id": 12346
}
Response Body:
{
  "status": "success",
  "task_id": 1001,
  "message": "Task updated successfully."
}

Get Task

Endpoint: GET /tasks/{task_id}
Description: Retrieves details about a specific task.
Response:
{
  "task_id": 1001,
  "title": "Update Database Schema",
  "description": "Refine the initial database schema based on feedback",
  "due_date": "2024-06-02T17:00:00Z",
  "priority": "Medium",
  "category": "Development",
  "assignee_id": 12346,
  "status": "In Progress"
}

List Task

Endpoint: GET /tasks
Description: Lists all tasks with filtering options.
Query Parameters: category, priority, assignee_id, status
Response:
{
  "tasks": [
    {
      "task_id": 1001,
      "title": "Update Database Schema",
      "description": "Refine the initial database schema based on feedback",
      "due_date": "2024-06-02T17:00:00Z",
      "priority": "Medium",
      "category": "Development",
      "assignee_id": 12346,
      "status": "In Progress"
    },
    {
      "task_id": 1002,
      "title": "Initial Draft for UI/UX",
      "description": "Sketch the initial UI/UX frames for the app",
      "due_date": "2024-05-25T15:00:00Z",
      "priority": "High",
      "category": "Design",
      "assignee_id": 12347,
      "status": "Not Started"
    }
  ]
}

Delete Task

Endpoint: DELETE /tasks/{task_id}
Description: Deletes a specific task.
Response:
{
  "status": "success",
  "task_id": 1001,
  "message": "Task deleted successfully."
}

High-Level Design

Web Frontend

Purpose: Provides the user interface for interacting with the application. Built using modern web technologies such as React or Angular for a responsive and interactive experience.
Responsibilities: Handling user inputs, rendering tasks, and providing visual feedback based on user interactions.

Mobile Frontend

Purpose: Delivers a native or hybrid mobile application interface, allowing access from smartphones and tablets.
Responsibilities: Similar to the web frontend but optimized for mobile experiences, including touch interactions and mobile-specific functionalities.

API Gateway

Purpose: Serves as the single entry point for all client requests, directing them to the appropriate backend services. It helps in request routing, composition, and protocol translation.
Responsibilities: Authentication, authorization, request routing, load balancing, and API metering.

Task Management Service

Purpose: Core backend service responsible for managing all task-related operations.
Responsibilities: Task creation, modification, deletion, and querying tasks based on various criteria.

User Management Service

Purpose: Manages user profiles and authentication details.
Responsibilities: User registration, login, profile updates, and user authentication.

Notification Service

Purpose: Handles sending notifications to users about task updates, due dates, and other alerts.
Responsibilities: Integrating with email services, push notification services, and possibly SMS for sending timely updates.

Database

Purpose: Central storage for all application data, including tasks, users, comments, and categories.
Responsibilities: Data persistence, ensuring data integrity, and supporting high-volume data access efficiently.

Search and Reporting Service

Purpose: Provides advanced search capabilities across tasks and generates reports on user activity and task statuses.
Responsibilities: Indexing task data, supporting complex search queries, and generating performance reports.
Listens to the queue
Fetches full task data from DB (or uses event payload)
Transforms it into ES document format
Indexes into Elasticsearch

Message queue

Decouple write operations from indexing
Avoid slowing down user requests
Provide retry capability
Handle spikes

Elasticsearch

Full-text search
Filtering
Sorting
Aggregations

Detailed Component Design

Primary DB: Relational (PostgreSQL / MySQL)

Why SQL instead of NoSQL?

Because task management has:

Strong relationships:
- User → Project → Task → Comment
Transactional updates:
- Assigning tasks
- Updating status
Complex queries:
- Filter by assignee, status, due date, priority
Consistency requirements:
- Avoid lost updates

So we want:

ACID
Joins
Constraints
Indexing
Referential integrity

NoSQL can be used later for analytics/search, but not as primary source of truth.

Core Tables:

users (
  id UUID PK,
  name VARCHAR,
  email VARCHAR UNIQUE,
  password_hash TEXT,
  role VARCHAR,
  created_at TIMESTAMP
)

projects (
  id UUID PK,
  name VARCHAR,
  owner_id FK(users.id),
  org_id UUID,
  created_at TIMESTAMP
)

tasks (
  id UUID PK,
  title VARCHAR,
  description TEXT,
  status VARCHAR,
  priority VARCHAR,
  due_date TIMESTAMP,
  assignee_id FK(users.id),
  project_id FK(projects.id),
  created_by FK(users.id),
  org_id UUID,
  version INT,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

comments (
  id UUID PK,
  task_id FK(tasks.id),
  user_id FK(users.id),
  message TEXT,
  created_at TIMESTAMP
)

tags (
  id UUID PK,
  name VARCHAR,
  org_id UUID
)
task_tags (
task_id FK(tasks.id),
tag_id FK(tags.id),
PRIMARY KEY(task_id, tag_id)
)

notifications (
id UUID PK,
user_id FK(users.id),
task_id FK(tasks.id),
type VARCHAR,
status VARCHAR,
created_at TIMESTAMP
)

Task Management Service

Scalability

Horizontal Scaling: The service can be scaled horizontally by adding more instances behind a load balancer to handle increased load, ensuring that multiple instances can manage read and write operations efficiently.
Caching: Implement caching strategies (e.g., Redis) for frequently accessed data like task lists and task details to reduce database load and improve response times.

Data Structures

Trees for Hierarchical Tasks: Use tree data structures to manage tasks that have sub-tasks, providing an efficient way to traverse and manage hierarchical relationships.
Hash Tables for Quick Lookup: Utilize hash tables to store task metadata for O(1) average-time complexity on lookup operations, which is beneficial for operations like searching tasks by ID.

Algorithms

Sorting Algorithms: Implement sorting algorithms for organizing tasks by priority, due date, or custom user-defined filters. Quick sort or merge sort can be used for backend sorting due to their efficiency in handling large data sets.
Graph Algorithms for Dependency Resolution: If tasks have dependencies (e.g., Task B cannot start until Task A is completed), graph algorithms like topological sorting can be employed to determine the order of task completions.

Each service has its own database to avoid coupling (polyglot persistence).

Use Kong, NGINX, AWS API Gateway for API Gateway.

Use containerization (Docker) and orchestration (Kubernetes) for independent deployments.

Use service discovery tools (Consul, Eureka) for dynamic microservice registration.