Katkat
Back

Design a To-Do List Service (CRUD, Auth, Rate Limiting, Caching & API Versioning)

MicrosoftSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

This question tests the ability to design a scalable, multi-tenant To-Do service, focusing on API versioning, authentication, rate limiting, and data integrity.

System Design: To-Do List Service

Design a scalable backend service that allows users to create, read, update, and delete (CRUD) tasks in a personal to-do list. The service will be used by millions of users, requiring low latency and high availability.

Requirements

  • Functional Requirements:
    • Users must be able to create tasks with titles, due dates, and priority levels.
    • Users must be able to list, update, and delete their own tasks.
    • Implement API versioning (e.g., v1 vs. v2) to allow for future feature evolution without breaking existing clients.
  • Non-Functional Requirements:
    • Authentication: Securely identify users and ensure they can only access their own data (multi-tenancy).
    • Rate Limiting: Prevent abuse by limiting the number of requests per user per minute.
    • Performance: Provide fast read access to lists, especially for frequently accessed tasks.
    • Consistency: Ensure task updates are eventually consistent or strongly consistent where required.

Expectations

  1. API Design: Define the core REST endpoints, including versioning strategy and authentication headers.
  2. Data Model: Propose a schema for tasks and users, discussing partitioning or sharding strategies.
  3. Architecture: Describe the components (e.g., API Gateway, Load Balancer, Cache, Database) and how they interact.
  4. Operational Logic: Explain how you would implement rate limiting (e.g., token bucket) and handle cache invalidation during updates.

Hints

Hint 1

Consider using an API Gateway to handle authentication and rate limiting before requests reach the core application logic.

Hint 2

Think about how to store user-specific data to ensure isolation, perhaps by using a `user_id` as a partition key in your database.

Hint 3

Use a caching strategy like Redis for 'Read' operations while maintaining a write-through or cache-aside policy for updates to ensure data integrity.

Follow-up questions

  • How would you handle global secondary indexes if a user needs to fetch tasks sorted by 'due date' vs 'priority'?
  • If you needed to add real-time collaboration features (e.g., shared lists), what architectural changes would be necessary?
  • How would you migrate a user from v1 to v2 of the API without causing downtime?