Design a meeting scheduler with cancellations

Quick Overview

Design a meeting scheduler with cancellations evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a meeting scheduler with cancellations

Company: Uber

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a meeting scheduling system for an organization. Include APIs for creating, updating, and cancelling single or recurring meetings; preventing double-booking of attendees and rooms; and querying free/busy to find the earliest common slot across N participants with room constraints and time zones. Specify the data model (tables/collections and key fields), storage choices (SQL/NoSQL), indexing, and sharding strategy for multi-tenant scale. Describe conflict-detection algorithms and concurrency control (e.g., optimistic locking, transactional boundaries, idempotency) during create/update/cancel flows. Detail the cancellation flow: how to efficiently remove a meeting, propagate notifications, free resources, and maintain audit history; propose optimizations for O(log n) cancel operations and for bulk cancellations. Cover nonfunctional requirements: expected QPS, latency SLOs, caching, eventual consistency vs strong consistency trade-offs, background jobs, failure handling and retries, deduplication, security and access control, and back-of-the-envelope capacity planning.

Quick Answer: Design a meeting scheduler with cancellations evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/Uber
Uber logo
Uber
Jul 26, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
14
0

Design a meeting scheduler with cancellations

System Design: Meeting Scheduling Platform (Onsite)

Context

Design a multi-tenant meeting scheduling system for an organization of any size (from startups to very large enterprises) operating across time zones. The system must support single and recurring meetings, rooms with constraints (capacity, equipment, location), and prevent double-booking of both people and rooms.

Functional Requirements

  1. Core APIs (HTTP/gRPC acceptable):
    • Create, update, cancel single or recurring meetings.
    • Prevent double-booking for attendees and rooms.
    • Query free/busy and return the earliest common slot across N participants with room constraints and time zones.
  2. Recurrence: iCal-style RRULEs, exceptions (single-instance edits), and partial-series updates/cancels.
  3. Notifications: Invitations, updates, and cancellations.

Data and Scale Requirements

  • Specify data model (tables/collections and key fields).
  • Choose storage (SQL/NoSQL) per dataset, with justification.
  • Propose indexing and sharding for multi-tenant scale.

Concurrency and Consistency

  • Describe conflict detection and concurrency control during create/update/cancel, including:
    • Optimistic locking, transactional boundaries, idempotency.
    • Algorithms for overlap detection.

Cancellation Flow

  • Detail how to remove meetings efficiently, propagate notifications, free resources, and maintain audit history.
  • Propose optimizations for O(log n) cancel operations (per calendar) and bulk cancellations.

Nonfunctional Requirements

  • State reasonable QPS and latency SLOs, caching strategy, consistency model (strong vs eventual), background jobs, failure handling and retries, deduplication, security and access control.
  • Provide back-of-the-envelope capacity estimates.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Uber•More Software Engineer•Uber Software Engineer•Uber System Design•Software Engineer System Design