Katkat
Back

Design a Scalable Calendar Service

LinkedInSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design calendar event storage and time-range reads, explain concurrent edits and scaling, and clarify recurrence and notification requirements.

Design a scalable calendar service. Explain its overall architecture, core components, and the design decisions that change as usage grows.

Requirements and Constraints

Start by defining the calendar behaviors your design supports. For a concrete baseline, assume users can create, edit, delete, and list events in a selected time range. Treat sharing, invitations, recurring events, and reminders as requirements to clarify before including them. This baseline is an explicit practice scope, not a claim about any existing calendar product's implementation.

No user count, peak request rate, event density, or availability target is supplied. Identify the workload information needed to justify your storage, partitioning, and caching decisions.

Clarifying Questions

  • Are calendars private, shared, or collaborative, and who may edit an event?
  • Are event times absolute instants, all-day dates, or local wall-clock recurrences?
  • How frequently do users list events compared with editing them, and which time ranges are common?
  • Must concurrent edits be rejected, merged, or accepted with an explicit conflict policy?

Hints

Hint 1

Start from a calendar's time-range read: A user normally opens a bounded part of a calendar. Decide how event storage and indexes support that query before proposing sharding or caching.

Follow-up questions

  • How would you represent a meeting recurring at the same local time across daylight-saving changes?
  • What happens when two users edit the same shared event from older versions?
  • Which changes would be needed if one shared calendar receives much more traffic than ordinary personal calendars?