04QuestionsGoogle Calendar

04 · Worked prompt

Google Calendar

Design recurring events, invitations, time zones, conflict handling, reminders, and concurrent updates.

35 minInterview blueprint

INTERVIEW RUBRIC

What a passing answer must show

100 points · 45 minutes

20pts
Scope the problem
0–5 min
Prioritize the core flows, state the scale, and name the non-goals.
15pts
Define contracts
5–10 min
Identify durable entities, APIs, idempotency, and the source of truth.
30pts
Complete the diagram
10–25 min
Trace one write path and one read path. Label the commit boundary and async work.
20pts
Lead one deep dive
25–38 min
Choose the highest-risk trade-off and explain the mechanism, alternative, and cost.
15pts
Prove reliability
38–45 min
Walk a failure, recovery, metric, bottleneck, and evolution path.

DRAW THIS FIRST

One complete box-and-arrow design

Design recurring events, invitations, time zones, conflict handling, reminders, and concurrent updates.

Google Calendar system architecture. Series rules and exceptions are truth; occurrences and reminders are derived, versioned work. Request path: Calendar clients to Calendar API to Event service to Calendar DB. Asynchronous path: Calendar change log to Occurrence/reminder workers. Read path: Range query service to Occurrence index. External dependency: Notification providers. — Google Calendar · system architecture

DEFEND THE DIAGRAM

Explain every boundary before adding more boxes.

Series rules and exceptions are truth; occurrences and reminders are derived, versioned work.

INTERVIEW CONTRACT

Design recurring events, invitations, time zones, conflict handling, reminders, and concurrent updates.

CAPACITY QUESTIONS TO QUANTIFY

Global time zones · long-lived series · read-heavy views · reliable reminders. State average and peak load, stored bytes, bandwidth or open connections, and the growth horizon before choosing a partitioning strategy.

End-to-end walkthrough

Trace the architecture in this order.

01
Enter and classify the request
Calendar clients → Calendar API
Create, invite, range read enters over HTTPS / RPC. Calendar API handles identity, admission, routing, and request context; it deliberately does not own domain truth.
02
Validate, then cross the commit boundary
Calendar API → Event service → Calendar DB
Event service receives the command, checks invariants and retry identity, then uses transaction to update Calendar DB. The user-visible mutation is accepted only after this boundary succeeds.
03
Move replayable work off the request path
Event service → Calendar change log → Occurrence/reminder workers → Occurrence index
Event service emits publish after commit; Occurrence/reminder workers uses consume and project / update to build Occurrence index. Consumers must tolerate duplicate delivery and stale retries because this path is asynchronous.
04
Serve reads from the right authority
Calendar API → Range query service → Occurrence index / Calendar DB
Range query service uses time-range scan for the common, read-optimized path and strong read when correctness or repair requires authoritative state. The API must state the freshness promise instead of hiding it.
05
Contain the dependency boundary
Occurrence/reminder workers → Notification providers
send reminder crosses into Notification providers. Treat timeouts as ambiguous, use a deadline and idempotent retry or reconciliation, and keep the core state recoverable when the dependency is unavailable.

Ownership ledger

Why each box exists—and what it must defend.

Component	Owns	Why it exists	Interviewer probe
Calendar APIAuth + account routing	Identity, admission, routing	Protects the system edge and attaches trusted context before domain work begins.	Timeout budgets, quotas, regional routing
Event serviceTimezone + recurrence writes	Write invariants and retry identity	Serializes or conditionally applies state changes before acknowledging success.	Concurrent writes, deduplication, hot ownership
Calendar DBSeries, exceptions, invites	Authoritative durable state	Provides the one record used to resolve disputes, recover, and rebuild projections.	Partition key, replication, consistency
Calendar change logVersioned mutations	Durable asynchronous handoff	Absorbs bursts and lets slow or optional work retry independently of the request.	Ordering key, lag, retention, dead letters
Occurrence/reminder workersMaterialize + schedule	Replayable processing	Runs expensive, fan-out, or side-effecting work with leases and bounded retries.	Idempotency, poison work, autoscaling
Occurrence indexNear-term range reads	Rebuildable query state	Shapes data for the dominant reads without weakening the write-side invariant.	Freshness, versioning, rebuild time
Range query serviceExpand + merge occurrences	Read composition and freshness policy	Chooses authoritative or derived state and returns a stable client contract.	Fan-out, cache policy, partial results
Notification providersEmail, push, SMS	External capability, not local truth	Keeps a specialized or third-party concern behind a replaceable contract.	Ambiguous timeout, circuit breaking, fallback

Physical design

Name the database, shard key, indexes, and guarantees.

Database + storage: PostgreSQL/distributed SQL stores series, exceptions, invites, and reminders; a derived time index stores near-term occurrences.
Partitioning / sharding: Colocate by calendar_id/owner_account_id; partition occurrence projections by calendar and bounded time bucket.
Indexes: Range (calendar_id, start_time, end_time), invitations (invitee_id, status, start_time), and unique (series_id, occurrence_key).
Replication + consistency: Series, exceptions, and RSVP transitions are strong. Occurrences/reminders are versioned projections with bounded freshness.
Cache, queue + recovery: An outbox drives occurrence/reminder workers. Cache near-term ranges by calendar version and rebuild derived state after schema changes.
Capacity math: Estimate events/user, range QPS, shared-event fan-out, recurrence horizon, reminder throughput, and hot enterprise calendars.
Alternative rejected: Materializing every recurrence forever explodes rewrites; materialize a rolling horizon and expand distant ranges on demand.

Deep-dive candidates

Pick one risk and explain the mechanism, alternative, and cost.

Recurrence identity

Use a stable local occurrence key, not only a UTC timestamp

DST can move UTC while the human-intended 9am remains

Series edits

Split a series at a recurrence boundary for this-and-future updates

Mutating one rule destroys history and attendee expectations

Reminder correctness

Derive jobs from occurrence versions and cancel stale versions idempotently

A reminder is a materialized effect, not source of truth

Failure pressure test

Show detection, containment, recovery, and evidence.

Timezone rules change

Re-expand future occurrences from stored zone and local intent

events affected by tzdb update

Reminder worker retries

Dedupe occurrence, attendee, channel, version

duplicate reminder count

Concurrent RSVP

Conditional update on invitation version

conflict rate

Before you finish, explicitly cover

Functional requirements and non-goals
Peak traffic, storage, bandwidth, and growth
Entities, APIs, idempotency, and pagination
Source of truth and consistency promise
Partition key, replicas, caches, and hot spots
Retries, backpressure, failover, and reconciliation
Latency, saturation, correctness, and recovery metrics
Security, migration, cost, and multi-region evolution

SAY THIS WHILE YOU DRAW

A four-part talk track

Scope
“I’ll prioritize create one-time and recurring events and invite attendees and track rsvp.”
Scale
“The design changes around global time zones · long-lived series · read-heavy views · reliable reminders.”
Decision
“Store recurrence rules plus exceptions instead of materializing an unbounded future.”
Risk
“The first failure I want to pressure-test is: DST changes and series edits can produce wrong times or lost responses.”

Reference details

Open these only after you can explain the diagram above without reading.

01Requirements and state lifecycle4 requirements

Create one-time and recurring events
Invite attendees and track RSVP
Render correctly across time zones and DST
Schedule reliable reminders and handle series edits

Google Calendar · state lifecycle

state lifecycle

Each transition must be durable, observable, and safe to retry.

tentative

confirmed

cancelled

completed

02Data model and APIs4 entities · 3 interfaces

Core entities

EventSeriesseries_id, organizer, timezone, recurrence_rule, versionOwner: Calendar service

OccurrenceExceptionseries_id, local_key, override, statusOwner: Calendar service

Invitationevent_id, attendee_id, response, versionOwner: Invitation service

Reminderoccurrence_id, attendee_id, fire_at, stateOwner: Scheduler

External interfaces

POST /v1/calendars/{id}/events

Create a series with local-time semantics

PATCH /v1/events/{id}?scope=this_and_future

Split or update a recurrence series

POST /v1/events/{id}/responses

Version-check an attendee RSVP

03Deep dives and trade-offsChoose one

Recurrence identity

Use a stable local occurrence key, not only a UTC timestamp

DST can move UTC while the human-intended 9am remains

Series edits

Split a series at a recurrence boundary for this-and-future updates

Mutating one rule destroys history and attendee expectations

Reminder correctness

Derive jobs from occurrence versions and cancel stale versions idempotently

A reminder is a materialized effect, not source of truth

04Failures, recovery, and evidence3 scenarios

Timezone rules change

Re-expand future occurrences from stored zone and local intent

events affected by tzdb update

Reminder worker retries

Dedupe occurrence, attendee, channel, version

duplicate reminder count

Concurrent RSVP

Conditional update on invitation version

conflict rate

05What makes the answer seniorInterviewer signals

The key question is what the user meant locally, not how to store UTC
Explain this event, this-and-future, and whole-series semantics
Keep the unbounded future as a rule rather than infinite rows
Primary trade-off: Store recurrence rules plus exceptions instead of materializing an unbounded future.

BEFORE THE NEXT QUESTION

Can you redraw it from memory?

Name the source of truth.
Trace the write and read paths.
Defend one trade-off.
Recover from one failure.

Scope the problem

Define contracts

Complete the diagram

Lead one deep dive

Prove reliability

Write

Propagate

Read

Trace the architecture in this order.

Enter and classify the request

Validate, then cross the commit boundary

Move replayable work off the request path

Serve reads from the right authority

Contain the dependency boundary

Why each box exists—and what it must defend.

Name the database, shard key, indexes, and guarantees.

Pick one risk and explain the mechanism, alternative, and cost.

Recurrence identity

Series edits

Reminder correctness

Show detection, containment, recovery, and evidence.

Timezone rules change

Reminder worker retries

Concurrent RSVP

Reference details

Core entities

External interfaces

Recurrence identity

Series edits

Reminder correctness

Timezone rules change

Reminder worker retries

Concurrent RSVP

Can you redraw it from memory?