November 21, 2021 7:00 PM PST
This document summarizes the mock system design interview focused on creating a calendar application. The discussion includes functional and non-functional requirements, system design considerations, and audience feedback.
Interview Overview
- Target Level: L4
- Duration: 45 minutes
- Topic Covered: Calendar
- Drawing Tool Used: Whimsical
Requirements
Functional Requirements
- View schedule
- Create events and add guests to meetings
- Respond to events (accept/reject/tentative)
Bonus Features
- Auto decline on current schedule
- Book recurring events
- User visibility of their weekly schedule
- Events created by the user
- Events as attendees
Non-Functional Requirements
- Support for 10,000 users in version 1
- Scale to 1 million users within 1 year
System Design
Database Choice
- Type: Relational database (chosen for ease of use, not scalability)
External APIs
- System design diagram
- Database schema
Additional Requirements
- Retrieve all calendars for a user given userID and time range
- Query to get event details based on event IDs and time constraints
Queries
- User hovers over an event to see details: issue another query
- Create an event: POST createEvent with userID, Calendar_ID, and a random key for duplicate requests
- Guest notifications: add notification service
- Attendee response: provide a link to the app with event information
Scalability Considerations
- Scale to 1 million users and 10 million calendars
- Read traffic: 100,000 QPS
- Write traffic: 10,000 QPS
- Recent 3 months of events stored in cache for performance
Replication Strategy
- Write to the database first, then update the cache
- Separate storage for historical events
Additional Design Considerations
- Public events visibility for users
- Fault tolerance and high availability
- Cache strategies and replication methods
Interviewer and Audience Feedback
Interviewer Feedback
- Basic functionality was covered, but time ran out for scalability and fault tolerance discussions.
- Emphasis on read/write patterns and high QPS vs low QPS.
- Importance of database sharding and horizontal scaling.
Audience Feedback
- SQL databases have many relations; NoSQL can be challenging for querying.
- Sharding and joins across shards are complex to design.
- Hot vs cold database considerations, including replication strategies.
- Notification services can be computed on the client device.
- Importance of database schema and scalability trade-offs.
- Discussion on sharding keys and maintaining performance with different query types.
General Observations
- The interviewee should control the flow of the discussion, starting from simple cases and gradually adding complexity.
- Monitoring, logging, and analytics are essential extensions of the core functionality.
- Suggestions for implementing reminders and notifications using delayed queues and client-side handling.
Conclusion
The interview highlighted the complexities of designing a scalable calendar system, emphasizing the need for clear requirements, effective communication, and an understanding of database design principles.