Frontend System Design Interview Questions — Hard

Answer: Building a collaborative editor requires concurrent multi-user editing, deterministic conflict resolution, local undo/redo stacks, and cursor presence.

graph TD
    subgraph Client Architecture
    Input[Keyboard Input] --> State[Document State Tree / AST]
    State --> CRDT[CRDT Engine: Yjs / Automerge]
    CRDT --> UndoMgr[Local Undo / Redo Manager]
    CRDT --> WSSync[WebSocket / WebRTC Sync Protocol]
    State --> Renderer[DOM / Canvas Virtualized Renderer]
    end

Core Architectural Decisions:

1. Conflict-Free Replicated Data Types (CRDTs) vs. OT:
   • OT (Operational Transformation): Requires a single centralized server to order all operations (Jupiter model).
   • CRDTs (State-of-the-Art - Yjs, Automerge): Peer-to-peer capable. Each character or node has a globally unique fractional ID (e.g., Lamport timestamp + Client ID). Any two clients can merge their states in any order and are mathematically guaranteed to converge to the exact same document without server intervention.
2. Local vs. Remote Undo/Redo Stacks:
   • Pressing Ctrl+Z must only undo your own past edits, never your teammate's simultaneous edits.
   • The Undo Manager tracks an inverse delta stack tagged with clientId === localUserId.
3. Rendering Engine (DOM ContentEditable vs. Custom Canvas):
   • ContentEditable (Notion, Medium): Fast to build, but browser inconsistencies in selection ranges and HTML cleanup make large documents buggy.
   • Custom Canvas / WebGL (Google Docs, Figma): Bypasses the DOM completely. Renders glyphs directly onto an HTML5 Canvas, achieving $60\text{ FPS}$ smooth scrolling on 500-page documents.

---

Answer: An infinite whiteboard must support millions of vector shapes, smooth $60\text{ FPS}$ panning/zooming, multi-pointer touch gestures, and spatial rendering.

graph TD
    ScreenCoord[Screen Coords: x_screen, y_screen] -->|Camera Matrix Inversion| WorldCoord[World Coords: x_world, y_world]
    WorldCoord --> RTree[R-Tree Spatial Index: Viewport Box]
    RTree --> VisibleShapes[Filtered Visible Shapes: Culling 99%]
    VisibleShapes --> WebGL[WebGL / 2D Canvas Renderer]

Mathematical & Spatial Pillars:

1. Camera Coordinate Transformation Matrix:
   • Convert between Screen Pixels and World Coordinates:
     • x_world = (x_screen - panX) / zoom
     • y_world = (y_screen - panY) / zoom
2. Spatial Indexing (R-Tree / QuadTree Viewport Culling):
   • Iterating through 50,000 shapes on every frame drops FPS to $5$.
   • Store all shape bounding boxes in an in-memory R-Tree (e.g., rbush).
   • On each render tick (requestAnimationFrame), query the R-Tree with the current visible screen bounding box:

     const visibleElements = tree.search(viewportBoundingBox);
     

   • Only render the elements returned ($\sim 20\text{ to }50$ shapes), achieving silky smooth $60\text{ FPS}$.
3. Multiplayer Cursor Interpolation:
   • Remote user mouse positions are broadcast via WebSockets at 20Hz.
   • The client uses Hermite / Bezier interpolation to animate remote cursors smoothly at 60Hz.

---

Answer: Applications like Linear achieve zero-latency interactions by performing all reads and writes against an in-memory / local SQLite database first, synchronizing changes to the server asynchronously.

sequenceDiagram
    autonumber
    actor User
    participant LocalDB as Local In-Memory DB (SQLite WASM / IndexedDB)
    participant MutationQueue as Outbox Mutation Queue
    participant SyncEngine as Background Sync Engine
    participant Server as Cloud Backend

    User->>LocalDB: 1. Create Issue (Write local)
    LocalDB-->>User: 2. Instant UI Update (0ms)
    LocalDB->>MutationQueue: 3. Append Mutation { id, client_time, delta }
    SyncEngine->>MutationQueue: 4. Read Pending Mutations
    SyncEngine->>Server: 5. POST /sync (Batch Mutations)
    Server-->>SyncEngine: 6. 200 OK + Server Timestamp
    SyncEngine->>MutationQueue: 7. Mark Mutations Confirmed

Key Architecture Principles:

1. Local Read/Write Autonomy:
   • Every user action executes synchronously against local IndexedDB / SQLite WASM. The UI updates with $0\text{ms}$ latency.
2. The Outbox Pattern & Persistent Mutation Queue:
   • Mutations are placed in a persistent Outbox queue. If the user goes offline (Airplane Mode) for 5 hours, mutations accumulate locally. When internet reconnects, the sync engine drains the outbox in chronological order.
3. Conflict Resolution via Client Lamport Clocks & LWW:
   • Each mutation is tagged with a logical Lamport timestamp: timestamp = Math.max(localClock, serverClock) + 1.
   • Conflicts on record fields are resolved using Last-Write-Wins (LWW) or column-level CRDT merging.

---

Answer: Server-Driven UI (SDUI) allows backend services to control the layout, components, and user flows of web and mobile clients dynamically without requiring client app updates or app store deployments.

graph TD
    Client[Web / Mobile App] -->|GET /api/v1/page/home| Server[SDUI Layout Engine]
    Server --> JSON[Component Schema Tree JSON]
    JSON --> Renderer[Client SDUI Dynamic Component Registry]
    Renderer --> Banner[<HeroBanner data={...} />]
    Renderer --> Carousel[<ProductCarousel data={...} />]
    Renderer --> Grid[<TwoColumnGrid data={...} />]

JSON Schema Structure:

{
  "type": "screen",
  "id": "checkout_screen_v2",
  "sections": [
    {
      "type": "BANNER",
      "props": { "title": "50% Off Flash Sale", "variant": "warning" }
    },
    {
      "type": "CAROUSEL",
      "props": {
        "items": [{ "id": 1, "name": "Item A" }],
        "onSelect": { "action": "NAVIGATE", "route": "/product/1" }
      }
    }
  ]
}

Client Renderer Implementation:

1. Component Registry:
   • A map binding schema type strings to native React components:

     const COMPONENT_MAP: Record<string, React.ComponentType<any>> = {
       BANNER: HeroBanner,
       CAROUSEL: ProductCarousel,
       GRID: TwoColumnGrid
     };
     

2. Fallback Degradation:
   • If the server sends a newly introduced component type that an older client build doesn't recognize, the client silently ignores it or renders a generic fallback container without crashing.

---

Answer:

graph TD
    DOM[User Types in Browser DOM] --> Normalizer[Input Normalizer & Selection Manager]
    Normalizer --> AST[Immutable Document AST State]
    AST --> PluginPipeline[Plugin Pipeline: Markdown, Mentions, Code Highlight]
    PluginPipeline --> Reconciler[Virtual DOM / Custom Reconciler]
    Reconciler --> RenderedDOM[Clean Sanitized HTML Output]

Internal Architecture:

1. Immutable Abstract Syntax Tree (AST):
   • Document content is stored as an immutable tree of Nodes (RootNode $\to$ ParagraphNode $\to$ TextNode with format bitmasks for Bold, Italic, Code).
2. Selection State Normalization:
   • Browser native window.getSelection() is notoriously inconsistent across Chrome, Safari, and Firefox.
   • The engine maintains an internal RangeSelection containing { anchor: { key, offset }, focus: { key, offset } } mapped to AST node keys rather than fragile DOM nodes.
3. Extensible Node Plugin Architecture:
   • Features like @mentions, tables, markdown shortcuts, and code syntax highlighting are isolated as transform plugins that intercept AST mutations before they hit the DOM.

---