📝 Problem Description
Design a calendar application like Google Calendar. Users can create events, invite attendees, set reminders, and view calendars in different views (day, week, month). Handle recurring events, timezone management, and calendar sharing.
👤 Use Cases
1.
User wants to creates event so that event saved and attendees notified
2.
User wants to views calendar so that sees events in selected view
3.
Attendee wants to responds to invite so that RSVP recorded
4.
System wants to event time approaches so that reminder sent
✅ Functional Requirements
- •Create, read, update, delete events
- •Recurring events (daily, weekly, monthly, custom)
- •Invite attendees with RSVP
- •Multiple calendar views (day, week, month)
- •Reminders via push/email
- •Calendar sharing and permissions
- •Timezone support
- •Free/busy lookup
⚡ Non-Functional Requirements
- •Calendar load < 500ms
- •Event sync < 2 seconds
- •Support 1B users
- •99.99% availability
⚠️ Constraints & Assumptions
- •Timezone handling is complex
- •Recurring events expand to many instances
- •Cross-calendar operations
📊 Capacity Estimation
👥 Users
1B users, 100M DAU
💾 Storage
10TB (events, calendars)
⚡ QPS
Reads: 50K/sec, Writes: 5K/sec
📐 Assumptions
- • 1B users
- • Average 50 events per user per month
- • 10 calendar views per user per day
- • 20% events have attendees
💡 Key Concepts
CRITICAL
RRULE Patterns
Store recurring events as RFC 5545 RRULE patterns, expand on query.
CRITICAL
Timezone Handling
Store in UTC, convert on display using user timezone.
HIGH
Event Instances
Recurring events have a master + exceptions for modified occurrences.
MEDIUM
Free/Busy API
Query availability without exposing event details.
💡 Interview Tips
- 💡Start with the event data model
- 💡Discuss recurring events and RRULE
- 💡Emphasize timezone handling
- 💡Be prepared to discuss conflict detection
- 💡Know the iCalendar standard basics
- 💡Understand the notification/reminder system