Katkat
Back

Design Versioned IDE Settings for Users and Teams

CursorSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design a distributed, hierarchical configuration management service for an IDE that synchronizes versioned settings across individual users, multiple teams, and workspaces while supporting offline modifications and deterministic conflict resolution.

Scenario

Modern cloud-enabled IDEs allow developers to sync their settings (keybindings, editor configurations, AI model rules, plugins) across multiple machines and inherit organizational configurations. You need to design the configuration storage and synchronization system for an IDE platform supporting individual developers, teams, and enterprise organizations.

Requirements

Functional Requirements

  • Deterministic Hierarchy & Precedence: Settings can be defined at multiple scopes: System Default -> Organization -> Team -> Workspace/Repo -> User Account -> Local Machine. Scopes must resolve deterministically, allowing higher-priority scopes to override lower ones (or lock specific keys against user overrides).
  • Offline Editing & Conflict Resolution: Developers frequently work offline. Local edits must merge predictably when the client reconnects, detecting concurrent conflicts without corrupting settings or losing data.
  • Versioning & Rollback: Every setting scope maintains an immutable audit log of revisions, supporting point-in-time rollbacks and differential inspections.
  • Access Control & Membership: Setting modifications must respect role-based permissions (e.g., team admins vs. team members). Membership changes should immediately reflect in setting resolution.
  • Schema Evolution: Client installations span multiple legacy and new versions. The system must support backward and forward compatible schema changes (e.g., key deprecations, type migrations).

Non-Functional Requirements

  • Low Latency: Setting resolution on IDE startup or workspace load must complete in under 50 ms.
  • Eventual Consistency & Reliability: Live updates across open IDE instances should sync via notifications within 2 seconds. The client must handle duplicate, delayed, or out-of-order events idempotently.
  • Resilience: The client must always remain operational if the backend sync service is degraded or completely unreachable.

Scale Assumptions

  • 5,000,000 Daily Active Users (DAU), averaging 2 active devices each.
  • 500,000 teams and organizations.
  • Average configuration payload size per scope: ~50 KB JSON.
  • Read traffic: ~15,000 QPS at peak (heavily cached / read-heavy).
  • Write traffic: ~200 QPS at peak.

Key Discussion Points

  1. Data Model & Schema: How scopes, revisions, and key-level locks are represented in the database.
  2. Synchronization Protocol: Push vs. pull mechanisms, vector clocks or monotonic revision IDs, and handling stale/offline write reconciliations.
  3. Evaluation Engine: Does hierarchical resolution happen on the server, the client, or both?
  4. Failure Modes: Authoritative disaster recovery, partitioning, and schema validation failures.

Hints

Hint 1

Consider decoupling raw configuration storage (content-addressed or revision-based snapshots) from the scope hierarchy index to make rollbacks and branching straightforward.

Hint 2

Think about using monotonic version tokens or vector clocks per scope so clients can detect whether their offline edits branch from a stale state.

Hint 3

For schema evolution, consider storing settings as typed key-value pairs with semantic version constraints rather than a monolithic, unstructured JSON blob.

Follow-up questions

  • How would you handle an enterprise security policy where a team admin 'locks' a specific setting (e.g., telemetry or external API endpoints) so that workspace and user scopes cannot override it?
  • If two developers on the same team push conflicting changes to team settings while one was offline, what reconciliation strategy prevents unintentional overwrites?
  • How do you migrate configurations when a setting is renamed and its format is split from a single string to an array across clients running three different major versions of the IDE?