Katkat
Back

Design a Scalable Calendar Service

UberFrontend Engineer · Technical Screen
MediumFrontend EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a distributed calendar system, focusing on data modeling for recurring events, time zone handling, and frontend state management for a high-concurrency scheduling UI.

Problem Statement

Design a scalable calendar service similar to Google Calendar or Outlook. The system needs to support millions of users, handle complex time-based queries, and provide a performant frontend experience.

Functional Requirements

  • Users can create, update, delete, and view events.
  • Support for recurring events (e.g., "every Monday at 9 AM").
  • View availability (free/busy) for other users.
  • Receive notifications/reminders before an event starts.

Non-Functional Requirements

  • High availability and low latency for read operations (viewing the calendar).
  • Data consistency is critical for meeting bookings (no double bookings).
  • Seamless synchronization across multiple time zones.

Deliverables

  1. API Design: Define the primary endpoints for managing events and retrieving user calendars.
  2. Data Model: Propose a database schema for events and recurrence rules. How do you store and expand recurring instances?
  3. Frontend Strategy: Describe how you would manage the local state for a performant calendar view, including handling "optimistic UI updates" and background sync.
  4. Scalability: How do you handle "hot" calendar users (e.g., a CEO's calendar with thousands of viewers)?

Hints

Hint 1

Consider storing recurring events as a base rule and generating instances lazily or using an RDBMS table to explode them, noting the trade-offs in query performance.

Hint 2

For global time zones, always store time in UTC on the server and handle the offset/location conversion on the client side based on the user's local settings.

Hint 3

To handle high-read traffic, consider using a caching layer (like Redis) to store the free/busy status or specific day views for active users.

Follow-up questions

  • How would you handle conflict detection (preventing double bookings) in a distributed system with multiple concurrent requests?
  • If we add a 'search events' feature, what changes would you make to your storage architecture to ensure sub-second search results?
  • How would you optimize the frontend rendering for a 'Month View' that contains hundreds of small events to ensure 60fps scrolling?