System requirements

Functional:

• user should be able to schedule meetings, inviting other participants(it could be individual or some group)
• User should be able to see his calendar(all the meeting details for a particular day), for the scope of the problem, lets have this scoped down till day
• User should be able to see the calendars of other employees
• User should be able to modify, update, check-status(of meeting), remove the meeting-invite from the calendar.

Non-Functional:

• It should be highly available, we are fine with eventual consistency as if some-one has scheduled or made any update for a meeting, it is fine that it takes some-time to reflect for others.
• It should be of low-latency for read operations(this is also of higher call-volume as compared to write/edit/update) operations
• I am keeping the notification service(where it alerts the user for their nearby upcoming meetings) as out of scope for v1 version.

Capacity estimation

• Lets assume we are building this for our organization with around 1 Million employees, lets assume that including all employees/email-groups, there are around 1.5 Million unique email-list(mapped to unique-ids).
• Lets assume the read to write ratio is around 10:1, so, if we assume that each employee checks its calendar once/twice a day, so read tps would be around 11TPS and write TPS would be around 1 TPS.
• Keeping the notification service out of scope for the v0 version.
• I am keeping the read/write servers separately to avoid affecting read-operations latency during write-operations.

API design

• POST: ScheduleAMeeting(caller_user_id, x-api-key, Meeting_Object)
  • caller_user_id is the one who schedules/organizes the meeting
  • x-api-key: this is used for throttling purposes
  • Meeting_Object: it has {Meeting_id, Meeting_name, start_timestamp, meeting_duration, List<UserID>)
    • List<UserId> is the userIds(it could be a group id for list-of-users as well) who we want to invite for the meeting
  • Response code is 201
• Get: ShowTheCalendars(caller_user_id, x-api-key, start_timestamp, end_timestamp, list<user_id>)
  • caller_user_id is the caller user_id
  • x-api-key: is same as above
  • {start_timestamp, end_timestamp}: show meetings for the user_id between these timestamps.
  • list<user_id>: Ids of the user for whom we want to show the meetings.
  • Response code is 200
  • Response payload: {Map<User_id, List<MeetingObjects>>}
• PUT: UpdateTheMeeting(user_id, x-api-key, UpdatedMeetingObject)
  • user_id: caller user_id(at lower level, we will allow the updates from the meeting organizer only, not from all members)
  • x-api-key: same as above
  • UpdatedMeetingObject: this will have the attributes for the updated meeting-object(we can't update the meeting-id, rest all we can update)
  • Response code is 200
• Get: ShowMeetingDetails(user_id, meeting_id):
  • Response code is 200,
  • Response payload is {MeetingObject}

Database design

• UserDetails:
  • user_id, email-address, user_name, list<groupEmails>
  • user_id is the index/primary key.
  • List<groupEmails> email-address for all the groups the user is associated with.
  • It would support operations like getUserDetails(), getGroupsForUser()
• GroupDetails:
  • group_id, group_email_address, userId
  • group_id is our partition key and userId is sort key
  • It would support operations like ,getAllUserIdsFor(group_id), removeUserFromGroup(groupId, userId)
• MeetingDetails:
  • MeetingID, MeetingName, List<UserId>, StartTime, Duration_in_minutes
  • MeetingId is the primary-key in this
  • List<UserId> would at max. go till 1M(I am assuming this could be loaded in-memory) such that it could be updated in-memory
• UserMeetingDetails:
  • UserId, Start_timeStamp, MeetingId
  • UserId would be primary-key and start_timeSTamp would be my sortKey
  • This would help to query like for this userId get me all the meetings with startTimestamp between <st> and <ed>, using this list<meetingID> I can leverage MeetingdEtails DB to get the meetingDetails.

High-level design

• Api-g: -> acts as a gatekeeper for us, does the reverse-proxy, authZ, authN and takes care of throttling.
• LB: -> load-balancer, segregates requests differently for read/write calendar service avoid read-servers to get affected when write-traffic is high(we aren't assuming it to be high though as the current scope)
• calendar-service: central-service which interacts with user to perform all kind of operations
• Kafka: for write-operations, we could leverage kafka to ack. that we have received the request and then later-on meeting-service would feed up on this and act-accordingly
• cache-server: For read kind of operations, we could cache the object {<userId, List<meeting_ids_for_the_current_day>}. We could cache it as per LRU eviction policy(most recent one), and with TTL of around 5 minutes as if some-one add a meeting invite for a particualr user, it should be fine if user gets to see it post 5 minutes(we don't expect someone to create a meeting in like next 2-3 minutes). We can also cache the meeting_details object({meeting_id, meeting_details}) with some small TTL of around 5-10 minutes.
• Meeting-Service: This service takes care of CRUD operations for the meetings-object.

Request flows

• ScheduleAMeeting(caller_user_id, x-api-key, Meeting_Object)

It calls the write-calendar-servers with caller_user_id and meeting_object(post authz/throttling by api-gateway),

The meetingObject has the information like {Meeting_id, Meeting_name, start_timestamp, meeting_duration, List)

It calls the group-details table to get the respective-user-ids for the group-id,

It updates the meetingDetails object with the above meetingObject and updates the UserMeetingDetails() for each user from the List to update the meeting-details for that.

• ShowTheCalendars(caller_user_id, x-api-key, start_timestamp, end_timestamp, list<user_id>)

It calls the right-calendar-servers with caller_user_id, assuming that authz, throttling is already taken care by api-gateway, It check the cache if the information is already there, if it isn't it hit the meetingService to get the response.

MeetingService will make a call to UserMeetingDetails() DB with primary key as each of the id in the list and sortKey as >= start_timestamp and <= end_timestamp and get the response like: Map< user_id, List>, then it makes call the MeetingDetails db to get the respective details(It can leverage Cache for this as well).

• UpdateTheMeeting(user_id, x-api-key, UpdatedMeetingObject)

It calls the write-calendar-servers with caller_user_id and meeting_object(post authz/throttling by api-gateway), It makes a call to meeting-service which updates the meetingDetails object(and can invalidate meeting-cache as well).

• ShowMeetingDetails(user_id, meeting_id):

It calls the right-calendar-servers with caller_user_id, assuming that authz, throttling is already taken care by api-gateway, It calls the meeting-service, which first check if the information is available in its cache or not(after authorizing the user). it yes, it returns. if no, it makes a call to meetingDetails db to get the required info.

Detailed component design

• Api-g: -> acts as a gatekeeper for us, does the reverse-proxy, authZ, authN and takes care of throttling.
• LB: -> load-balancer, segregates requests differently for read/write calendar service avoid read-servers to get affected when write-traffic is high(we aren't assuming it to be high though as the current scope)
• calendar-service: central-service which interacts with user to perform all kind of operations
• Kafka: for write-operations, we could leverage kafka to ack. that we have received the request and then later-on meeting-service would feed up on this and act-accordingly
• cache-server: For read kind of operations, we could cache the object {<userId, List<meeting_ids_for_the_current_day>}. We could cache it as per LRU eviction policy(most recent one), and with TTL of around 5 minutes as if some-one add a meeting invite for a particualr user, it should be fine if user gets to see it post 5 minutes(we don't expect someone to create a meeting in like next 2-3 minutes). We can also cache the meeting_details object({meeting_id, meeting_details}) with some small TTL of around 5-10 minutes.
• Meeting-Service: This service takes care of CRUD operations for the meetings-object.

Trade offs/Tech choices

• I am using key-value DB(could be DDB) as that would be highly scalable, my queries aren't complex, I am not wanting high consistency, hence key-value db suits the purpose.

Failure scenarios/bottlenecks

• Meeting-service/Calendar services could be the single-point-of-failure. To avoid this we can have multiple replicase of these(in master-slave or p2p fashion)
• Instead of going with TTL based caching we could have event-based cache-invalidation, such that for any update-call, we will invalidate the cache to avoid stale info.

Future improvements

• Our services interacts interally via means of Grpc clients with exponential back-off retry strategy in place..
• We could leverage the canary(prod-imitating accounts) to test the e2e flow, We will leverage metrics/dashboards/auto-alarms/tickets to detect any potential issue/deviation from the expected behaviour.
• I guess the current design we could expand easily to show 1-week, 1-month of meeting-details(as timestamp is sort-key)
• We are leveraging kafka to accomodate high write call-rate in future.
• For write-calls, we can associate an unique key in the header to support idempotency.