Requirements

Functional Requirements:

• Support task creation, assignment, prioritization, tagging, search and monitoring.
• Provide visualization of task at the personal and team level (Gantt charts, Kanban boards, etc).
• Provide notification for tasks near deadline, or tasks being updated.

Non-Functional Requirements:

• Strong consistency - user should see tasks at the same state when state change happened.
• High availability (99.9%)
• Low latency for viewing (<200ms), and updates (<500ms)
• Highly scalable (100M DAU, 10M teams) and reliable

API Design

// Team management

POST /teams -> Team

GET /teams

GET /teams/

PATCH, DELETE, etc.

// Task management

POST /tasks -> Task

GET /tasks

GET /tasks/

PATCH, DELETE, etc.

// Search for tasks

GET /tasks?q={query}&pageSize={}&pageToken={}

Database

User table

• id (PK)
• name
• ...

Team table

• id (PK)
• name
• ...

TeamMembership table

• user_id
• team_id
• ...

Task table

• id (PK)
• name
• team_id
• creator_id
• assignee_id
• priority
• created_at
• updated_at
• progress
• deadline
• status // created | in_progress | complete
• tags
• ...

High-Level Design

Client talks to various services via APIGateway.

TeamService handles various team management related API calls.

TaskService handles various task management related API calls. Any change in tasks triggers a notification. It puts the message on the NotificationQueue.

MonitoringService looks for tasks close to the deadline. When it determines notification is needed, it notifications team members by putting a message on NotificationQueue.

NotificationService pulls messages off notification queue, and notifies the clients.

Optionally we can introduce a search service.

Detailed Component Design

Database:

• Estimates
  • User profile: 100M * 1KB = 100GB
  • Team profile: 10M * 1KB = 10GB
  • Task: assume each team create 1 task/day, and each task is 1KB. Each day we need 10GB of storage. In 1 year it is 3.6TB. In 5 years it is 18TB
• This is a little difficult to host in 1 database. We should consider sharding database by team id, so that tasks for an team is collocated in one database.
• We should also design a policy to archive tasks, and move them to cold storage.

MonitoringService

• Responsible for notifying team members when tasks are approaching deadline.
• It can basically run a query to look for tasks whose deadline is within X days. It should then find the team members of such tasks, and notify the team members.

Notification system

• We may need to generate a lot of notifications. Estimates
  • Assume on average each team has 10 members. The task update will be 100M per day. Assume 1% of tasks are close to deadline each day, assume 100M active tasks, then that is 1M * 10 = 10M messages. Let's say we need to send 200M messages per day, which is 20k / sec
  • One message queue is sufficient to handle 20k/sec, we should consider sharding it for better reliability (e.g. on task id)
• We should consider batching updates, at the cost of slight delay of notifications.

Scalng

• All services are stateless, and we can horizontally scale them.

Failure

• We need to have good monitoring in place
• If database is overloaded, we should put in circuit breakers, and apply back pressure.
• If notification system start to fail, we should slow down the notifications (e.g. by delaying, or batching)