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

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

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.

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.