Requirements

Functional Requirements:

Create, update, cancel a meeting.

Setup recurrences.

Check availability.

Send notifications.

Non-Functional Requirements:

Highly available system

Consistent slot booking

Low latency APIs for create, update, cancel.

Atleast once notifications delivery

Handle burst traffic

Capacity Estimation

100 Mill DAU

10 events scheduled / day -> 10k schedule events/ sec (QPS)

Storage:

Recurrence ? -> 20 participants* 1 mill events * 10 recurrences -> 200 million * 1kb -> 200 GB (per day)

need to partion for years worth

API Design

POST v1/schedules -> 200: {CONFLICT, BOOKED}

{ name, start, end, recurrence}

PUT v1/schedules -> 200

{ name, start, end}

GET v1/schedules?start={}&granularity={month/day/year} - Page[EVents]

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Database Design

Entity: entityId, name, ...

Event: eventId, startTime, endTime, recurrence,

EventInstance: eventId (pk), pId, start, end, status.. [fan out limit??] OCC

Participants: pId, eventId

Access patterns ->

Query: particpant by start and end time

Index on pId and stat, end

confitional update/OCC on eventInstance. based on conflict for status.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.