Core requirements

A user edits a recurring team meeting on a phone while riding the subway. Seconds later, every attendee expects the new time to appear on laptops, tablets, and watches, with no duplicate reminders, no stale copies, and no silent overwrite from someone else's edit.

That request already shows that this is not a simple CRUD application. Google Calendar behaves like a distributed scheduling system that stores long-lived event data, coordinates shared access, computes recurring occurrences, and propagates changes across many clients.

The hard part is that these concerns interact. A time zone shift changes how a recurrence expands. A permission change affects who can read a modified event. A write that succeeds in one region must not leave another device showing yesterday's state. Calendar logic is like a railway timetable. Even small inconsistencies ripple into missed connections.

In an interview, this framing changes the conversation. You first define scope, assumptions, and scale. Then you estimate traffic and storage so later decisions around databases, caches, and messaging follow from workload rather than guesswork.

This lesson stays at that preparation layer. It sets the minimum requirements, the main constraints, and the rough numbers. The next lesson will turn those inputs into the actual architecture.

Core requirements

Before drawing services, pin down what the system must do during a request life cycle. A client sends an event mutation, the backend validates identity and permissions, stores the canonical event state, schedules reminders, and distributes the change to readers on other devices.

The minimum functional scope includes the following capabilities.

• Event