Requirements

Functional Requirements:

Covered (all majors):

• ✅ One-time tasks at a future time (run_at) — major
• ✅ Recurring tasks with intervals/cron — major
• ✅ View / edit / cancel tasks — major
• ✅ High availability & reliability — major
• ✅ Low execution latency / low jitter — major
• ✅ Scalability to thousands of tasks — major
• ✅ Notifications (minor), idempotency (minor)

One gap:

• Task prioritization (minor) — priority levels so high-priority tasks win under contention. Minor, mention-and-move-on.

I'd still write the explicit list in the panel — an interviewer expects to hear it stated up front. Paste-ready:

Functional: schedule one-time tasks; recurring tasks (interval/cron); view/edit/cancel tasks; notify on completion/failure; task priority. Non-Functional: high availability & fault tolerance; low latency & minimal jitter; horizontal scalability; idempotency/dedup.

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

Capacity Estimation

Capacity numbers for a Task Scheduler

Assumptions (state these — they drive everything)

• 50M registered users, 10% active daily → 5M DAU
• Each user schedules ~20 tasks/day → 100M tasks/day
• Average ~1,200 writes/sec; peak 3–5× → ~5K writes/sec

Storage

• Task row ≈ 500 bytes (payload + metadata)
• 100M/day × 500B = 50 GB/day → ~18 TB/year
• Add execution logs at ~200B × 100M = 20 GB/day → shard/partition by time, TTL old logs

Read/Query load

• Status polling: not every task is polled; assume 1 read per write → ~5K reads/sec peak
• Due-task lookups via Redis sorted set: O(log N), don't hit the DB

Recurring tasks

• 10% of tasks recurring → 10M recurring definitions
• Midnight spike: if many recur daily at 00:00, that's millions of firings in a tight window — capacity must account for burst, not just average

Cache / Queue sizing

• Redis sorted set holds near-future tasks (e.g., next 24h) → 100M × ~100B ≈ 10 GB
• Queue depth must handle the spike; workers autoscale

API Design

Create one-time task (major)

POST /tasks { "target": { "type": "http", "url": "...", "method": "POST" }, "payload": {...}, "run_at": "2025-06-01T14:00:00Z" } → 201 { "task_id": "...", "status": "PENDING" }

Create recurring task (major)

POST /recurring-tasks { "target": {...}, "interval": "300s" | "cron": "0 9 * * *", "start_at": "...", "max_runs": 100 } → 201 { "recurring_task_id": "...", "next_run_at": "..." }

Get task status (minor)

GET /tasks/{id} → { "status": "PENDING|RUNNING|SUCCESS|FAILED|CANCELLED", "attempts": 2, "error": "...", "timestamps": {...} }

Cancel / pause (minor)

POST /tasks/{id}/cancel POST /recurring-tasks/{id}/pause

Health & metrics (minor) — GET /health, GET /metrics (queue depth, exec rate, failure rate).

High-Level Design

Reference architecture for a Task Scheduler

The end-to-end flow the interviewer wants you to narrate:

1. Client → API service (stateless, behind LB) validates the request, writes the task to Postgres, and if run_at is near-future, pushes it into a Redis sorted set.
2. Scheduler/Orchestrator periodically scans the DB for tasks coming due and loads them into Redis for fast dispatch. It also advances next_run_at for recurring tasks.
3. Dispatcher pulls due tasks (score <= now()), atomically claims each one (mark RUNNING), and hands it to a worker via a queue.
4. Workers execute the task target (HTTP callback, etc.), update status to SUCCESS/FAILED, and trigger retries.
5. Notification service reports outcomes/errors back to users.

Database Design

Core entities

• Tasks — every concrete unit of work: id, type, payload, status (pending/running/done/failed), run_at, attempts, max_retries, created_at
• Recurring Tasks — the template: id, interval/cron, next_run_at, last_run_at, max_runs. Each firing generates a concrete Tasks row.
• Execution Log — append-only audit trail: task_id, started_at, finished_at, result, error, attempt

Detailed Component Design

1. The Dispatcher / Task Claiming (most important)

• How workers atomically claim due tasks so two workers never run the same one
• The UPDATE tasks SET status='RUNNING' WHERE id=? AND status='PENDING' compare-and-swap pattern (or SELECT ... FOR UPDATE, or an advisory lock)
• Failure handling: heartbeat + watchdog timeout resets stale RUNNING tasks; retries with exponential backoff up to max_attempts

2. The Timing Wheel / Redis Sorted Set

• Near-future tasks live in a Redis sorted set scored by run_at
• Dispatchers pop score <= now() for O(log N) lookup → sub-second dispatch without hammering the DB

3. Recurring Task Engine

• Anchoring next run to next_run_at + interval (not now() + interval) to avoid drift
• Atomic compare-and-swap on next_run_at so two schedulers don't create duplicate runs