How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Uber.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Uber during technical interviews.

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

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

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.
Recurrence: iCal-style RRULEs, exceptions (single-instance edits), and partial-series updates/cancels.
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.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

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

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

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?

Quick Overview

Context

Functional Requirements

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.

Recurrence: iCal-style RRULEs, exceptions (single-instance edits), and partial-series updates/cancels.

Notifications: Invitations, updates, and 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.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.

If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.

Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

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

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

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?

Design a meeting scheduler with cancellations

Quick Overview

Design a meeting scheduler with cancellations

Design a meeting scheduler with cancellations

System Design: Meeting Scheduling Platform (Onsite)

Context

Functional Requirements

Data and Scale Requirements

Concurrency and Consistency

Cancellation Flow

Nonfunctional Requirements

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP

Design a meeting scheduler with cancellations

Quick Overview

Design a meeting scheduler with cancellations

Design a meeting scheduler with cancellations

System Design: Meeting Scheduling Platform (Onsite)

Context

Functional Requirements

Data and Scale Requirements

Concurrency and Consistency

Cancellation Flow

Nonfunctional Requirements

Constraints & Assumptions

Clarifying Questions to Ask

What a Strong Answer Covers

Follow-up Questions

Submit Your Answer to Earn 20XP