Frontend System Design Interview Questions

Answer: Design the frontend architecture for a high-performance, infinite scrolling social News Feed displaying rich media posts (text, images, video), post creation, real-time engagement reactions, and smooth $60\text{ FPS}$ scrolling.

graph TD
    subgraph News Feed Frontend Architecture
    Header[Feed Header: 10 New Posts Pill] --> Composer[Post Composer: Optimistic Post]
    Composer --> VirtualList[Virtualized Feed List: Windowing]
    VirtualList --> TopSpacer[Top Spacer: Height = measuredHeight]
    VirtualList --> Card[Visible Feed Cards: 5-8 Active DOM Nodes]
    VirtualList --> BottomSpacer[Bottom Spacer: Height = measuredHeight]
    Card --> Media[Media Container: IntersectionObserver Video Autoplay]
    Card --> Actions[Action Bar: Optimistic Like with Rollback]
    VirtualList --> IO[Bottom Intersection Sentinel: Fetch Next Page]
    end

1. Requirements Exploration

• Functional Requirements:
  • Display a continuous feed of chronological/ranked posts containing author details, timestamp, markdown text, images, and videos.
  • Infinite scroll: automatically fetch the next page of posts as the user scrolls near the bottom.
  • Post composer: create a new post with instant optimistic feed insertion.
  • Engagement: like / react to a post with immediate local UI count update.
  • Real-time banner: notify the user when new posts are available ("10 new posts $\uparrow$") without abruptly jumping the scroll position.
• Non-Functional Requirements:
  • Smooth Performance: Maintain a solid $60\text{ FPS}$ during scrolling on mid-tier mobile devices; keep DOM node count bounded ($<30$ nodes) via List Virtualization.
  • Fast Initial Load: First Contentful Paint (FCP) $<1.5\text{s}$, Largest Contentful Paint (LCP) $<2.5\text{s}$.
  • Offline & Network Resilience: Cache recent feed posts in IndexedDB for immediate offline rendering; optimistic mutations with automatic retry and rollback.
  • Resource Optimization: Auto-play videos only when $\ge 50%$ visible in viewport using IntersectionObserver; pause immediately when scrolled away.

2. Component Architecture & Hierarchy

<FeedContainer>
  ├── <NewPostsFloatingBanner> ("10 New Posts" - Scrolls to top on click)
  ├── <PostComposer> (Rich text draft, image uploader, optimistic dispatch)
  ├── <VirtualizedFeedList>
  │     ├── <TopPhantomSpacer style={{ height: topPadding }} />
  │     ├── <FeedCard key={postId}>
  │     │     ├── <PostHeader> (Avatar, author name, timestamp, menu)
  │     │     ├── <PostContent> (Expandable text with "See more")
  │     │     ├── <PostMediaGallery> (Responsive grid / video player)
  │     │     └── <PostActionBar> (Like button, Comment count, Share)
  │     ├── <BottomPhantomSpacer style={{ height: bottomPadding }} />
  │     └── <InfiniteScrollSentinel /> (Observed by IntersectionObserver)
  └── <FeedLoadingSkeleton />

3. Data Model & Normalized Client Store

Maintain a normalized state store (Zustand / Redux) to prevent duplicate data across components:

interface NormalizedFeedState {
  entities: {
    posts: Record<string, PostEntity>;
    users: Record<string, UserEntity>;
    comments: Record<string, CommentEntity>;
  };
  feed: {
    postIds: string[];
    cursor: string | null;
    hasMore: boolean;
    isFetchingNextPage: boolean;
    newPostCount: number;
  };
}

interface PostEntity {
  id: string;
  authorId: string;
  createdAt: string;
  content: string;
  media: Array<{ type: 'image' | 'video'; url: string; aspectRatio: number }>;
  likeCount: number;
  isLikedByMe: boolean;
  commentCount: number;
}

4. Interface & API Design

• GET /api/v1/feed?cursor={cursor}&limit=10 $\to$ Returns { posts: PostEntity[], nextCursor: string | null, hasMore: boolean }
• POST /api/v1/posts $\to$ Payload { content: string, mediaIds: string[] }
• POST /api/v1/posts/{id}/like $\to$ Toggles like state with idempotency.

5. Optimizations & Deep Dive

1. List Virtualization (Dynamic Height Caching):
   • Maintain an estimated height per post card. Measure actual rendered heights asynchronously using a shared ResizeObserver and store in an in-memory prefix-sum array to compute exact top/bottom padding offsets in $O(\log N)$ time.
2. IntersectionObserver for Video Autoplay & Viewport Lazy Loading:

   const observer = new IntersectionObserver(
     (entries) => {
       entries.forEach((entry) => {
         const video = entry.target as HTMLVideoElement;
         if (entry.isIntersecting && entry.intersectionRatio >= 0.5) {
           video.play().catch(() => {});
         } else {
           video.pause();
         }
       });
     },
     { threshold: 0.5 }
   );
   

3. Optimistic UI Updates with Rollback:
   • When the user clicks "Like", immediately set isLikedByMe = true and increment likeCount += 1.
   • Dispatch the API call in the background. If the request fails after 3 retries, revert the count and show a toast notification.
4. Preserving Scroll Position on New Posts:
   • When new posts arrive via WebSockets, do not prepend them immediately to the top of the active list (which would cause a jarring layout shift for the user reading a post). Instead, increment newPostCount in a floating pill button ("10 new posts $\uparrow$") and prepend only when clicked.

---

Answer: Design a search and booking platform coordinating responsive filter bars, date-range calendar pickers, virtualized property listings, and interactive map pin clustering.

• Architecture Reference: Rearchitecting Airbnb's Frontend (Medium Engineering)
• Key Design Pillars:
  1. Bidirectional URL Synchronization: All filters (price range, amenities, date bounds, map coordinates ne_lat, sw_lng) are serialized directly into URL query parameters for shareability and browser back-button support.
  2. Spatial Map Pin Clustering (Supercluster): Aggregate thousands of property markers into cluster bubbles using a spatial QuadTree running in a Web Worker.
  3. Virtualized Date-Range Calendar: Render multi-month availability grids using CSS Grid windowing to eliminate off-screen DOM overhead.

---

Answer: Design a lightweight, responsive web ride-booking application supporting real-time GPS vehicle tracking, pickup point selection, route polyline animation, and surge pricing alerts.

• Architecture Reference (Video): Uber Frontend System Design Walkthrough
• Key Design Pillars:
  1. Driver Location Interpolation: Smooth driver car marker movement on WebGL / Mapbox maps using Hermite spline interpolation between 4-second GPS WebSocket ticks.
  2. Polyline Decoding: Decode Google Maps encoded route polylines on the client and render via Canvas/WebGL layers.
  3. Pickup Geocoding with Debounce: Autocomplete pickup addresses with session tokens to minimize third-party API billing.

---

Answer: Design an ultra-lightweight Progressive Web App (PWA) operating under unstable 2G/3G network connections with minimal data consumption and near-instant load times.

• Case Study Reference: Ola PWA Case Study (Google web.dev)
• Key Design Pillars:
  1. Tiny Initial Bundle Size ($<200\text{KB}$): Code splitting with dynamic import(), lightweight UI primitives, and zero heavy external libraries.
  2. Service Worker Cache-First Strategy: Cache app shell HTML, CSS, and icons via Service Workers (workbox-precaching) to ensure instant $0\text{ms}$ cold starts.
  3. Offline Request Outbox: Queue ride booking requests in IndexedDB when offline, automatically dispatching when the browser detects navigator.onLine === true.

---

Answer: Design a custom HTML5 video player supporting Media Source Extensions (MSE), adaptive bitrate streaming (HLS / DASH), buffer starvation management, and interactive scrubber previews.

• Architecture Reference: HTML5 Video at Netflix (Netflix Tech Blog)
• Key Design Pillars:
  1. Media Source Extensions (MSE): Fetch binary .m4s video/audio chunks over HTTP and append directly into the browser's SourceBuffer.
  2. Adaptive Bitrate Algorithm (ABR): Monitor network throughput and dropped frame rates; switch dynamically between 1080p, 720p, and 480p chunk streams seamlessly.
  3. Thumbnail Scrubbing Preview: Load image sprite sheets; on progress bar hover, calculate timestamp position and adjust background-position on a tooltip lens.

---

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.

---