Design Calendar Frontend State for Recurring Events

Quick Overview

Design frontend state and APIs for a calendar with bounded views, recurring series, and single-occurrence rescheduling. Separate normalized server data from UI state while handling recurrence overrides, time zones, optimistic updates, and races.

Design Calendar Frontend State for Recurring Events

Company: Snowflake

Role: Frontend Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

# Design Calendar Frontend State for Recurring Events Design the frontend architecture and API contract for a calendar application. It must support creating and deleting events, multiple calendar views, recurring event series, and rescheduling one occurrence without changing the rest of its series. Assume the backend can provide the required persistence; focus on API shape, component state, cached server state, and data flow. Explain how a visible date range is loaded and how a single-occurrence override is represented so it remains correct when the user switches views. ### Constraints & Assumptions - Views request bounded date ranges rather than loading an unbounded recurring series. - A recurring series has a recurrence rule, while one occurrence may be moved or canceled independently. - Times need an explicit time zone and stable event or occurrence identity. - Create, delete, and reschedule interactions may use optimistic UI but must reconcile with server responses. ### Clarifying Questions to Ask - Which views are required, and what date range does each view fetch? - When deleting or editing a recurring event, may the user choose one occurrence, this and future occurrences, or the entire series? - Are event times anchored to a local wall-clock time or a fixed instant when time-zone rules change? ```hint Keep the rule and exceptions distinct Moving one occurrence should create an override tied to its original occurrence identity rather than rewriting the whole series. ``` ```hint Treat the visible range as a cache key View mode and date range determine what instances the UI needs; selection and draft state should not be mixed into that server cache. ``` ### What a Strong Answer Covers - Series, occurrence, override, and cancellation identities. - Range-based APIs and normalized cached server state shared across views. - Separation of server data from ephemeral selection, form, and navigation state. - Optimistic mutation, rollback or reconciliation, race control, and cache invalidation. - Time-zone, recurrence-boundary, and daylight-saving edge cases. ### Follow-up Questions - How would “this and future occurrences” be represented without rewriting all generated instances? - What happens when two tabs edit the same series? - How would offline event creation synchronize after reconnecting?

Quick Answer: Design frontend state and APIs for a calendar with bounded views, recurring series, and single-occurrence rescheduling. Separate normalized server data from UI state while handling recurrence overrides, time zones, optimistic updates, and races.

|Home/System Design/Snowflake
Snowflake logo
Snowflake
Aug 3, 2026, 12:00 AM
mediumFrontend EngineerTechnical ScreenSystem Design
0
0

Design Calendar Frontend State for Recurring Events

Design the frontend architecture and API contract for a calendar application. It must support creating and deleting events, multiple calendar views, recurring event series, and rescheduling one occurrence without changing the rest of its series. Assume the backend can provide the required persistence; focus on API shape, component state, cached server state, and data flow.

Explain how a visible date range is loaded and how a single-occurrence override is represented so it remains correct when the user switches views.

Constraints & Assumptions

  • Views request bounded date ranges rather than loading an unbounded recurring series.
  • A recurring series has a recurrence rule, while one occurrence may be moved or canceled independently.
  • Times need an explicit time zone and stable event or occurrence identity.
  • Create, delete, and reschedule interactions may use optimistic UI but must reconcile with server responses.

Clarifying Questions to Ask Guidance

  • Which views are required, and what date range does each view fetch?
  • When deleting or editing a recurring event, may the user choose one occurrence, this and future occurrences, or the entire series?
  • Are event times anchored to a local wall-clock time or a fixed instant when time-zone rules change?

What a Strong Answer Covers Guidance

  • Series, occurrence, override, and cancellation identities.
  • Range-based APIs and normalized cached server state shared across views.
  • Separation of server data from ephemeral selection, form, and navigation state.
  • Optimistic mutation, rollback or reconciliation, race control, and cache invalidation.
  • Time-zone, recurrence-boundary, and daylight-saving edge cases.

Follow-up Questions Guidance

  • How would “this and future occurrences” be represented without rewriting all generated instances?
  • What happens when two tabs edit the same series?
  • How would offline event creation synchronize after reconnecting?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...