Forem: ZeeshanAli-0704

Frontend System Design: Virtualization & Handling Large Data Sets

ZeeshanAli-0704 — Sun, 15 Mar 2026 17:27:03 +0000

Virtualization & Handling Large Data Sets

Render only what's visible — lists, tables, infinite scroll, canvas grids, and architecture patterns.

Why Virtualization
How Virtualization Works
Library Comparison and Decision Guide
Infinite Scrolling Patterns
Large Table Rendering
Canvas Based Rendering (Extreme Data)
Performance Optimization
Accessibility (A11y)
Architecture Decision Guide
Real World Case Studies
Common Pitfalls
Interview Questions
Quick Reference Card

⬆ Back to Top

Why Virtualization

Modern web applications routinely deal with large data sets — product catalogs with 50K items, analytics dashboards with 100K rows, chat logs spanning years. The natural instinct is to render everything into the DOM and let the browser handle it. But the browser's rendering pipeline was never designed for tens of thousands of nodes simultaneously. Every DOM node passes through style calculation → layout → paint → composite on every frame. When you have 50,000 nodes, the browser spends more time on off-screen elements than on what the user actually sees. Virtualization exists to solve this fundamental mismatch between data size and rendering capacity.

The Problem — DOM Is Expensive

10,000 rows × ~5 DOM nodes each = 50,000 DOM nodes

Each node costs:
  ├── Memory:  ~0.5–1 KB per node
  ├── Layout:  Browser calculates position for ALL nodes
  ├── Paint:   Renders ALL visible + off-screen nodes
  └── GC:      Tracks all references

Result: 50 MB+ memory, 2–5s initial render, scroll jank, input lag

Without vs With Virtualization

Without Virtualization              With Virtualization
┌──────────────┐                    ┌──────────────┐
│ Row 1        │ ← rendered         │              │ ← padding-top (spacer)
│ Row 2        │ ← rendered         │╔════════════╗│
│ Row 3        │ ← rendered         │║ Row 5      ║│ ← rendered (visible)
│ ...          │                    │║ Row 6      ║│ ← rendered (visible)
│ Row 9999     │ ← rendered         │║ Row 7      ║│ ← rendered (visible)
│ Row 10K      │ ← rendered         │╚════════════╝│
└──────────────┘                    │              │ ← padding-bottom (spacer)
                                    └──────────────┘
DOM: 10,000 nodes                   DOM: ~10 nodes + spacers
Memory: O(n)                        Memory: O(viewport) — constant!

Performance Numbers

Rows	DOM Nodes	Render Time	Scroll FPS	Memory
100	500	~20ms	60 fps	~5 MB
10,000	50,000	~2,000ms	20-30 fps	~80 MB
100,000	500,000	~15,000ms+	< 10 fps	~500 MB+
100K virtualized	~500	~50ms	60 fps	~10 MB

Key Insight: Virtualization keeps DOM node count near-constant regardless of data size.

⬆ Back to Top

How Virtualization Works

Virtualization (also called windowing) is the technique of only rendering elements currently visible in the viewport, plus a small overscan buffer, while maintaining the illusion of a full scrollable list. The browser's native scrollbar still behaves as if all items exist — the trick is that a tall "phantom" container (set to the total height of all items) creates the scrollbar, but actual DOM nodes are only created for the ~20–30 items the user can see.

This is conceptually similar to how a movie projector works: the audience sees a continuous stream of images, but only one frame is displayed at any given moment. The rest of the film reel exists but isn't being projected.

Core Math (Fixed Height)

The core algorithm is surprisingly simple for fixed-height items. Since every item has the same height, we can compute the exact position of any item with basic arithmetic — no measurement needed. The virtualizer listens to the scroll event, reads scrollTop, divides by itemHeight to find which item the user is looking at, then renders only a small window around that index.

Given:
  containerHeight = 600px,  itemHeight = 40px
  totalItems = 50,000,      scrollTop = 8,000px,  overscan = 5

Calculate:
  totalHeight = 50,000 × 40 = 2,000,000px       ← virtual scroll height
  startIndex  = floor(8000 / 40) = 200
  visibleCount = ceil(600 / 40) = 15
  endIndex    = 200 + 15 = 215

With overscan:
  renderStart = max(0, 200 - 5) = 195
  renderEnd   = min(50000, 215 + 5) = 220

→ Render items[195..220] = 25 DOM nodes instead of 50,000

Fixed vs Variable Height

Fixed-height virtualization is straightforward because offset = index × height gives O(1) random access to any item's position. Variable-height items are significantly harder. Since each item can be a different height (think tweets with images vs text-only), you can't use simple multiplication. Instead, you must maintain a prefix sum array — a running total of heights — so that offset[i] = sum of heights from item 0 to i-1. Finding which item is at a given scroll position then requires a binary search on this prefix sum array, giving O(log n) lookup.

The additional challenge with variable heights is that you often don't know the height until the item renders. Libraries solve this with an estimate-then-measure approach: provide an estimateSize for initial layout, render the items, measure their actual DOM height via getBoundingClientRect() or ResizeObserver, then correct the offsets.

Fixed Height:                       Variable Height:
┌────────────────┐  40px           ┌────────────────┐  30px
├────────────────┤  40px           ├────────────────┤  80px  ← expanded
├────────────────┤  40px           ├────────────────┤  120px ← has image
├────────────────┤  40px           ├────────────────┤  30px

offset = index × height            offset = prefixSum[index]
O(1) lookup                         O(log n) binary search on prefix sums

Architecture of a Virtualizer

Every virtualizer has the same fundamental structure: an outer scroll container (with overflow: auto) that detects scroll events, an inner container sized to the total virtual height of all items (creating the scrollbar), and a small set of rendered items positioned within that inner container. The space above and below rendered items is filled by spacers (padding, empty divs, or CSS transforms) to maintain the correct scroll position.

┌───────────────────────────────────────────────────────┐
│                  Scroll Container                      │
│  ┌─────────────────────────────────────────────────┐  │
│  │         Inner Container (total height)           │  │
│  │                                                  │  │
│  │  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐      │  │
│  │    Spacer Top (padding / transform)              │  │
│  │  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘      │  │
│  │  ┌─────────────────────────────────────────┐    │  │
│  │  │  Rendered Item (startIndex)             │    │  │
│  │  │  Rendered Item (startIndex + 1)         │    │  │
│  │  │  ...                                    │    │  │
│  │  │  Rendered Item (endIndex)               │    │  │
│  │  └─────────────────────────────────────────┘    │  │
│  │  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐      │  │
│  │    Spacer Bottom                                 │  │
│  │  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘      │  │
│  └─────────────────────────────────────────────────┘  │
│                   ▲ scrollTop                          │
└───────────────────────────────────────────────────────┘

Three Positioning Strategies

Once the virtualizer knows which items to render, it needs to position them at the correct scroll offset. There are three approaches, each with different performance characteristics. The key insight is about which phase of the rendering pipeline each approach triggers:

Layout phase (expensive): Browser recalculates geometry of all affected elements
Paint phase (moderate): Browser redraws pixels for affected areas
Composite phase (cheap): GPU moves already-painted layers — no CPU recalculation

transform: translateY() wins because it only triggers compositing — the browser promotes the element to its own GPU layer and just repositions it, skipping layout and paint entirely.

Strategy	How	Used By	Why
Padding	`paddingTop` / `paddingBottom` on inner container	Simple custom builds	Easy, but triggers layout on change
Absolute	`position: absolute; top: offset` per item	react-window	Precise, each item independently placed
Transform	`translateY(offset)` on wrapper	react-virtuoso	GPU-accelerated, no layout — only compositing

Positioning comparison:

Padding:                  Absolute:                  Transform:
┌────────────┐           ┌────────────┐             ┌────────────┐
│ paddingTop │           │ relative   │             │ relative   │
│╔══════════╗│           │   abs top:0│             │ translateY │
│║ items    ║│           │   abs top:X│             │  ┌──────┐  │
│╚══════════╝│           │   abs top:Y│             │  │items │  │
│ paddingBot │           │            │             │  └──────┘  │
└────────────┘           └────────────┘             └────────────┘
Triggers layout          Triggers layout            GPU compositing only ✅

Core Principles Summary

Principle	What It Means	Why It Matters
Viewport-only rendering	Only items visible (± overscan) exist in DOM	Keeps DOM node count constant O(viewport), regardless of data size — eliminates the root cause of slowness
Spacer/padding trick	Total scroll height preserved using padding or a sentinel div	Creates the native scrollbar illusion — browser thinks all items are rendered, user sees correct scroll thumb size and position
Scroll sync	`scrollTop / itemHeight` → data index mapping	Connects the physical scroll position to the logical data index — this is the core calculation that drives which items get rendered
Overscan	Extra items rendered above/below visible area	Prevents blank flashes during fast scrolling — items are pre-rendered just off-screen so they appear instantly when scrolled into view
Recycling	Some implementations reuse DOM nodes instead of creating/destroying	Reduces garbage collection pressure — instead of creating 20 new nodes and destroying 20 old ones per scroll, the same nodes get new content

⬆ Back to Top

Library Comparison and Decision Guide

Choosing a virtualization library is one of the most impactful architectural decisions for data-heavy UIs. The core trade-off is between simplicity (less control, more opinions) and flexibility (more control, more boilerplate). There are two fundamental API philosophies:

Component-based (react-window, react-virtuoso): You render a <FixedSizeList> or <Virtuoso> component that owns the scroll container, the positioning logic, and the rendering. You just provide an itemContent renderer. Less code, but the library controls the DOM structure.
Headless (TanStack Virtual): The library gives you a hook (useVirtualizer) that returns mathematical calculations — which items are visible, what their offsets are, total height. You own 100% of the markup and styling. More boilerplate, but total flexibility.

The right choice depends on your constraints: Do you need to match a custom design system? Use headless. Do you need grouped headers and infinite scroll working in 10 minutes? Use batteries-included.

Library Evolution

react-virtualized (2015) ← Legacy, large bundle, feature-rich
       │
react-window (2018)      ← Lighter rewrite by same author
       │
@tanstack/react-virtual  ← Framework-agnostic, headless, modern
       │
react-virtuoso (2019+)   ← Zero-config, dynamic heights, batteries-included

Comparison Table

Feature	react-window	react-virtuoso	TanStack Virtual
Bundle	~6 KB	~16 KB	~4 KB
API Style	Component	Component	Headless hook
Fixed-size items	✅	✅	✅
Variable-size	⚠️ must know sizes	✅ auto-measured	✅ via `measureElement`
Infinite scroll	Via addon	✅ built-in	Manual
Sticky headers	❌	✅ built-in	Manual
Table support	Grid component	✅ `TableVirtuoso`	Manual (headless)
Horizontal	✅ Grid	❌	✅
Bidirectional (chat)	❌	✅	Manual
SSR	⚠️ Limited	✅	✅
Frameworks	React only	React only	React, Vue, Solid, Svelte
Maintained (2024+)	Low	Active	Very active

Decision Flowchart

Need list virtualization?
│
├─ Fixed-height items, simple list?
│  └─ react-window ✅ (smallest, simplest)
│
├─ Dynamic heights, zero-config needed?
│  ├─ Need infinite scroll, grouped headers, tables?
│  │  └─ react-virtuoso ✅ (batteries included)
│  └─ Just simple dynamic list?
│     └─ react-virtuoso or TanStack Virtual
│
├─ Need full markup/styling control?
│  └─ @tanstack/react-virtual ✅ (headless)
│
├─ Not using React? (Vue, Solid, Svelte)
│  └─ @tanstack/virtual ✅ (framework-agnostic)
│
├─ Custom table with column virtualization?
│  └─ TanStack Virtual + TanStack Table ✅
│
└─ Chat UI with bidirectional scroll?
   └─ react-virtuoso ✅ (reversed mode)

Usage Syntax At a Glance

react-window — Component-based, sizes upfront:

<FixedSizeList height={600} itemCount={items.length} itemSize={50} overscanCount={5}>
  {({ index, style }) => <div style={style}>{items[index].name}</div>}
</FixedSizeList>

react-virtuoso — Zero-config, auto-measures:

<Virtuoso
  style={{ height: '600px' }}
  totalCount={items.length}
  itemContent={(index) => <div>{items[index].name}</div>}
/>

TanStack Virtual — Headless hook, you own the markup:

const virtualizer = useVirtualizer({
  count: items.length,
  getScrollElement: () => parentRef.current,
  estimateSize: () => 50,
});

// You render: virtualizer.getVirtualItems().map(row => ...)
// You position: transform: `translateY(${row.start}px)`

⬆ Back to Top

Infinite Scrolling Patterns

Infinite scrolling is a UX pattern where new data loads automatically as the user scrolls, eliminating explicit "next page" buttons. But it introduces two fundamental challenges:

When to fetch: The app must detect that the user is approaching the end of loaded content and trigger a network request before they see blank space. Too late and users see a loading spinner; too early and you waste bandwidth.
DOM growth: Without virtualization, infinite scroll creates an ever-growing DOM. A user who scrolls through 500 pages has 25,000 DOM nodes in memory. Combining infinite scroll with virtualization solves this — the data grows in memory but the DOM stays constant.

The gold standard in production is: cursor-based pagination on the API + useInfiniteQuery for caching + virtualization for rendering. This gives you bounded DOM, efficient network usage, and a seamless user experience.

Pattern Overview

Infinite Scroll Approaches:

1. Intersection Observer (Modern ✅ Recommended)
   └─ Sentinel element at bottom → fires callback when visible

2. Scroll Position (Legacy)
   └─ scrollTop + clientHeight >= scrollHeight - threshold

3. Virtualized + Infinite Scroll (Best for Large Lists ✅)
   └─ Combine virtualization + data fetching

4. Bidirectional (Chat UIs)
   └─ Load older messages at top, new at bottom
   └─ Maintain scroll position when prepending

Pattern 1: Intersection Observer

The Intersection Observer API is a browser-native mechanism for efficiently detecting when an element enters or exits the viewport (or any ancestor scroll container). Unlike scroll event listeners — which fire synchronously on every pixel of scroll and require manual math to determine element visibility — Intersection Observer is asynchronous and batched by the browser. The browser itself determines when elements cross visibility thresholds during its rendering cycle, making it significantly cheaper than polling scroll positions.

The pattern uses a sentinel element — a tiny 1px div placed after the last item. The observer watches this sentinel. The rootMargin property extends the detection zone (e.g., 200px below the viewport), so the fetch triggers before the user reaches the end — giving the network request time to complete before the user sees empty space.

How it works:

  ┌─────────────────────────┐
  │     Scroll Container     │
  │  ┌───────────────────┐  │
  │  │   Item 1          │  │
  │  │   ...             │  │  Visible Viewport
  │  │   Item 20         │  │
  │  └───────────────────┘  │
  │  ╔═══════════════════╗  │ ← rootMargin: 200px (pre-trigger zone)
  │  ╚═══════════════════╝  │
  │  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐  │
  │    Sentinel (1px div)   │ ← When enters rootMargin → fetchMore()
  │  └ ─ ─ ─ ─ ─ ─ ─ ─ ┘  │
  └─────────────────────────┘

Approach: Watch a 1px sentinel div. When it enters rootMargin zone, trigger fetch.

// Hook: useInfiniteScroll
const observer = new IntersectionObserver(
  ([entry]) => { if (entry.isIntersecting) fetchMore(); },
  { rootMargin: '200px', threshold: 0 }
);
observer.observe(sentinelRef.current);

// Component: Just place sentinel after items
{items.map(item => <div key={item.id}>{item.name}</div>)}
<div ref={sentinelRef} style={{ height: 1 }} />  {/* ← trigger */}

Why better than scroll events? No event listener overhead, no manual scroll math, built-in thresholding, more performant.

Pattern 2: Virtualized + Infinite Scroll (Gold Standard)

Approach: Virtualization for DOM + cursor-based pagination for data.

Data Flow:

  API (cursor-paginated)
       ↓
  useInfiniteQuery({ queryKey, queryFn, getNextPageParam })
       ↓
  allItems = pages.flatMap(p => p.data)
       ↓
  Virtualizer (only renders ~20-30 visible items)
       ↓
  When last virtual item visible → fetchNextPage()

react-virtuoso — Built-in:

<Virtuoso
  data={items}
  endReached={loadMore}   // ← fires when scrolled near bottom
  itemContent={(index, item) => <Item data={item} />}
  components={{ Footer: () => loading ? <Spinner /> : null }}
/>

TanStack Virtual + TanStack Query — Manual wiring:

const { data, fetchNextPage, hasNextPage } = useInfiniteQuery({ ... });
const allItems = data?.pages.flatMap(p => p.data) ?? [];

const virtualizer = useVirtualizer({
  count: hasNextPage ? allItems.length + 1 : allItems.length, // +1 loader row
  ...
});

// In useEffect: when last virtualItem.index >= allItems.length → fetchNextPage()

Pattern 3: Bidirectional Scroll (Chat UIs)

Bidirectional scrolling is the hardest infinite scroll pattern. In a chat app, old messages load at the top when the user scrolls up, while new messages appear at the bottom in real-time. The critical challenge is scroll position stability: when you prepend 50 older messages above the current viewport, the browser naturally shifts everything down by the combined height of those new items, causing the viewport to "jump" — the message the user was reading disappears.

The solution is the firstItemIndex pattern: instead of array indices starting at 0, you start with a large synthetic index (like 10,000). When older messages are prepended, you decrement firstItemIndex. The virtualizer uses this to compute stable offsets, effectively "inserting" items above the viewport without shifting visible content.

Challenge — Prepending messages without scroll jump:

  Before prepend:               After prepend (WRONG):
  ┌─────────────────┐          ┌─────────────────┐
  │  Message 50     │ ← here   │  Message -49 ▲  │ ← viewport jumps!
  │  Message 51     │          │  Message -48    │
  └─────────────────┘          └─────────────────┘

  After prepend (CORRECT — scroll position preserved):
  ┌─────────────────┐
  │  Message -49     │ ← added above (off-screen)
  │  ...             │
  │  Message 50      │ ← still visible ✅
  └─────────────────┘

Approach: Use firstItemIndex pattern — start with large index, decrement on prepend:

<Virtuoso
  data={messages}
  firstItemIndex={firstItemIndex}           // Start at 10000, decrement on prepend
  initialTopMostItemIndex={messages.length - 1}  // Start at bottom
  startReached={loadOlderMessages}          // Called when scrolled to top
  followOutput="smooth"                     // Auto-scroll on new messages
/>

Cursor-Based vs Offset-Based Pagination

How you paginate your API directly affects the reliability of infinite scroll. Offset-based (?offset=200&limit=50) is simple but fragile — if items are inserted or deleted between requests, items get skipped or duplicated because the offset now points to a different position. Cursor-based (?cursor=abc123&limit=50) uses an opaque pointer (typically the last item's ID or a timestamp) to resume exactly where the previous page left off, regardless of insertions or deletions. For any real-time feed (social, chat, notifications), cursor-based is essential.

Aspect	Cursor-Based	Offset-Based
Consistency	✅ Stable with real-time data	❌ Skips/duplicates on insert/delete
Performance	✅ O(1) seek with index	❌ O(n) for large offsets
Jump to page	❌ Not possible	✅ Easy
Use when	Infinite scroll, feeds	Paginated tables

Cursor: GET /items?cursor=abc123&limit=50  → { data, nextCursor }
Offset: GET /items?offset=200&limit=50     → { data, total }

⬆ Back to Top

Large Table Rendering

Tables amplify the virtualization problem because data is two-dimensional. A list with 100K items has one axis to virtualize; a table with 100K rows × 50 columns has two axes. The cell count grows multiplicatively, not additively. This means you often need both a row virtualizer (vertical, based on scrollTop) and a column virtualizer (horizontal, based on scrollLeft) working simultaneously, rendering only the rectangular intersection of visible rows and visible columns.

Additionally, tables have unique UX requirements: sticky headers must remain visible while scrolling vertically, sticky columns (like an ID or name column) must remain visible while scrolling horizontally, and the corner cell where both sticky axes meet needs the highest z-index so it sits above everything.

The Challenge — 2D Virtualization

100,000 rows × 50 columns = 5,000,000 cells!

With Row Virtualization only (20 visible rows):
  20 × 50 = 1,000 cells → manageable

With Row + Column Virtualization (20 rows × 10 cols):
  200 cells → fast! ✅

Row Virtualization

┌──────────────────────────────────────────────────────┐
│  Col A    │  Col B    │  Col C    │  ...  │  Col Z   │
├───────────┼───────────┼───────────┼───────┼──────────┤
│  (padding-top: from hidden rows above)               │
├───────────┼───────────┼───────────┼───────┼──────────┤
│  Row 45   │  data     │  data     │  ...  │  data    │ ← Rendered
│  Row 46   │  data     │  data     │  ...  │  data    │ ← Rendered
│  ...      │  ...      │  ...      │  ...  │  ...     │
│  Row 64   │  data     │  data     │  ...  │  data    │ ← Rendered
├───────────┼───────────┼───────────┼───────┼──────────┤
│  (padding-bottom: from hidden rows below)            │
└──────────────────────────────────────────────────────┘

Column Virtualization

Full table: │ Col 1 │ Col 2 │ Col 3 │ ··· │ Col 50 │

Viewport (columns 5–15 visible):
              ┌─────────────────────────────┐
  padding-left│ Col 5 │ Col 6 │ ··· │Col 15│ padding-right
              └─────────────────────────────┘
                        ▲
                  scrollLeft

Approach: TanStack Table + TanStack Virtual

The modern standard for building production virtualized tables is to separate table logic from rendering logic. TanStack Table handles column definitions, sorting state, filtering, row selection, column resizing — all the data operations. TanStack Virtual handles which rows and columns are visible given the current scroll position. Neither library renders any DOM — they both return data/calculations that you render yourself. This separation gives you full control over markup, styling, and behavior while letting each library focus on what it does best.

Architecture:

  TanStack Table → column defs, sorting, filtering, selection
       ↓
  rows = table.getRowModel().rows
       ↓
  Row Virtualizer  → which rows to render (based on scrollTop)
  Col Virtualizer  → which cols to render (based on scrollLeft)
       ↓
  Render intersection: visible rows × visible columns
  + padding cells for unrendered columns
  + spacer rows for unrendered rows

// Two virtualizers working together
const rowVirtualizer = useVirtualizer({
  count: rows.length,
  getScrollElement: () => parentRef.current,
  estimateSize: () => 40,
});

const colVirtualizer = useVirtualizer({
  horizontal: true,
  count: visibleColumns.length,
  getScrollElement: () => parentRef.current,
  estimateSize: (i) => visibleColumns[i].getSize(),
});

// Render: only intersection of virtualRows × virtualCols
// + paddingLeft/paddingRight cells for hidden columns
// + spacer <tr> for hidden rows above/below

Sticky Headers & Columns

Sticky positioning is one of CSS's most powerful features for data grids. position: sticky creates an element that behaves like relative positioning until it reaches a scroll threshold, then switches to behaving like fixed — all without JavaScript. The key implementation detail is z-index layering: the sticky header needs z-index: 2 (above scrolling rows), sticky columns need z-index: 1, and the corner cell (where sticky header meets sticky column) needs z-index: 3 so it sits above both. All sticky elements must have an opaque background — otherwise scrolling content bleeds through underneath them.

Normal scroll:                     Sticky header:
┌─────────────────┐               ┌─────────────────┐
│  Header Row     │ ← scrolls up  │  Header Row     │ ← stays fixed ✅
├─────────────────┤               ├─────────────────┤
│  Row 1          │               │  Row 50         │
│  Row 2          │               │  Row 51         │
└─────────────────┘               └─────────────────┘

Sticky column (horizontal scroll):
┌──────────┬──────────┬──────────┬──────────┐
│ Name     │ Col 5    │ Col 6    │ Col 7    │
│ (sticky) │          │          │          │  ← Col 1-4 scrolled out
├──────────┼──────────┼──────────┼──────────┤
│ Alice    │ data     │ data     │ data     │
│ Bob      │ data     │ data     │ data     │
└──────────┴──────────┴──────────┴──────────┘
  ▲ stays fixed

CSS approach:

/* Sticky header */
thead th { position: sticky; top: 0; z-index: 2; background: white; }

/* Sticky first column */
td:first-child, th:first-child { position: sticky; left: 0; z-index: 1; background: white; }

/* Corner cell (both axes) */
thead th:first-child { z-index: 3; }  /* Above both sticky header & column */

⬆ Back to Top

Canvas Based Rendering (Extreme Data)

When even virtualized DOM can't keep up — millions of cells, real-time streaming updates, complex conditional formatting — canvas rendering bypasses the DOM entirely. Instead of creating DOM nodes that the browser must manage through its rendering pipeline (style → layout → paint → composite), you draw pixels directly onto a <canvas> element using its 2D drawing API (fillRect, fillText, strokeRect).

The trade-off is fundamental: you gain raw speed (the browser doesn't track individual cells, no layout recalculation, no style resolution) but you lose everything the DOM provides for free — text selection, accessibility, event delegation, CSS styling, form elements, and SEO. You must manually implement hit-testing ("which cell did the user click?"), keyboard navigation, clipboard operations, and accessibility overlays. This is why canvas grids are reserved for extreme cases where DOM virtualization is genuinely insufficient.

When DOM vs Canvas

DOM Rendering (Virtualized)         Canvas Rendering
├── < 100K cells                    ├── > 100K cells
├── Rich interactions (forms)       ├── Display-heavy (read-only)
├── A11y required                   ├── Real-time data (trading, monitoring)
├── SEO needed                      ├── High update frequency
└── Standard table features         └── GPU-accelerated drawing

How Canvas Grids Work

A canvas grid treats the entire visible area as a single <canvas> element and draws cell content as pixels using the Canvas 2D API (ctx.fillText, ctx.fillRect, ctx.strokeRect). On scroll, the grid reads the new scroll position, calculates which rows/columns are visible (the same math as DOM virtualization), clears the canvas, and redraws only the visible cells in a single requestAnimationFrame callback.

The key architectural challenges are: event handling (canvas receives a single click event with clientX/clientY coordinates that must be translated to (row, col) via math), text editing (an invisible <input> element is overlaid on the canvas, positioned over the active cell), and accessibility (an ARIA grid overlay with visually hidden DOM nodes must mirror the visible canvas content for screen readers).

┌──────────────────────────────────────────┐
│          Canvas Grid Architecture         │
│                                           │
│  ┌────────────────────────────────────┐  │
│  │          <canvas>                   │  │
│  │   Painted pixels (NOT DOM nodes)    │  │
│  │   ┌─────┬─────┬─────┬─────┐       │  │
│  │   │ A1  │ B1  │ C1  │ D1  │       │  │
│  │   ├─────┼─────┼─────┼─────┤       │  │
│  │   │ A2  │ B2  │ C2  │ D2  │       │  │
│  │   └─────┴─────┴─────┴─────┘       │  │
│  └────────────────────────────────────┘  │
│                                           │
│  Events: Manual hit-testing               │
│    (clientX, clientY) → (row, col)        │
│  Scroll: requestAnimationFrame repaint    │
│  Edit:   Overlay <input> over cell        │
└──────────────────────────────────────────┘

Approach: Calculate visible range from scroll position → draw only visible cells on canvas → manual hit-testing for interactions → overlay native <input> for editing.

Canvas Libraries

Library	Use Case	Scale
Glide Data Grid	React canvas grid	1M+ cells
AG Grid (Enterprise)	Hybrid DOM/Canvas	Enterprise apps
Handsontable	Excel-like grid	Spreadsheets
PixiJS / Konva	Custom visualizations	Custom

Canvas vs DOM Trade-offs

Aspect	DOM (Virtualized)	Canvas
Max cells	~100K	Millions
Accessibility	Native	Must implement manually
Text selection	Native	Manual clipboard
Rich content	Any HTML/CSS	Must paint everything
Event handling	DOM events	Manual hit testing
Complexity	Low-Medium	High

⬆ Back to Top

Performance Optimization

Virtualization alone gets you 80% of the way to a smooth experience, but the remaining 20% comes from fine-tuning the rendering pipeline. The core issue: even though the virtualizer limits DOM nodes to ~20–30, each scroll event can still trigger re-renders, layout recalculations, and garbage collection. These micro-costs accumulate at 60fps (one frame every 16.6ms), and a single slow frame causes visible jank.

The optimization strategy is to minimize work at every level: (1) reduce how often React re-renders (memoization), (2) reduce what the browser recalculates per frame (CSS containment, transform positioning), (3) reduce GC pressure (stable keys, avoid inline allocations), and (4) move expensive work off the main thread (Web Workers for sorting/filtering).

Overscan Tuning

Overscan is the number of extra items rendered above and below the visible area. It's a direct trade-off: more overscan means fewer blank flashes during fast scrolling (items are pre-rendered off-screen), but too much overscan defeats the purpose of virtualization by keeping too many DOM nodes alive. The sweet spot depends on row complexity — simple text rows need less overscan than rows with images and interactive controls.

Too little (0):              Right (3-10):              Too much (50):
┌──────────────┐            ┌──────────────┐           ┌──────────────┐
│              │ ← blank!   │▒▒▒▒▒▒▒▒▒▒▒▒│ ← buffer  │▒▒▒▒▒▒▒▒▒▒▒▒│
│╔════════════╗│            │╔════════════╗│            │▒▒▒▒▒▒▒▒▒▒▒▒│
│║  Visible   ║│            │║  Visible   ║│            │╔════════════╗│
│╚════════════╝│            │╚════════════╝│            │╚════════════╝│
│              │ ← blank!   │▒▒▒▒▒▒▒▒▒▒▒▒│ ← buffer  │▒▒▒▒▒▒▒▒▒▒▒▒│
└──────────────┘            └──────────────┘           └──────────────┘
Fast but flickers           Smooth scrolling ✅        Defeats purpose

Scenario	Recommended Overscan
Simple text rows	3–5 items
Complex row renderers	5–10 items
Fast scroll (mobile)	10–20 items or 200–400px

Key Optimization Techniques

These techniques are ordered by impact-to-effort ratio. The first few are simple CSS/React changes that provide large gains; the later ones require more effort but handle edge cases.

Technique	Impact	Approach
`React.memo` on row components	High	Prevent re-renders on scroll
`useMemo` for data transforms	Medium	Avoid recomputing filtered/sorted data
`transform: translateY()` not `top`	Medium	GPU compositing, no layout trigger
`contain: layout style paint`	High	Isolate layout recalc per row
Reserve space for images	High	Set explicit `width`/`height` to avoid layout shift
`{ passive: true }` scroll listeners	Medium	Prevent scroll jank
`requestAnimationFrame` scroll batching	Medium	Batch scroll state updates
Web Worker for data processing	High	Offload filtering/sorting from main thread
`content-visibility: auto`	High	Browser-native lazy rendering (non-virtualized)
Avoid inline objects/functions in render	Medium	Prevents child re-renders

Scroll Performance Pattern

Scroll events fire at 60+ times per second. If each event calls setState, React schedules a re-render for every event — potentially 60+ re-renders per second. requestAnimationFrame batching ensures only one state update per visual frame, matching the browser's actual repaint rate. Production libraries like TanStack Virtual handle this internally using observeElementOffset, so you typically don't need to implement this yourself.

// ❌ Bad: setState on every scroll → re-render every frame
const handleScroll = (e) => setScrollTop(e.currentTarget.scrollTop);

// ✅ Better: Batch with requestAnimationFrame
const rafRef = useRef(null);
const handleScroll = useCallback((e) => {
  if (rafRef.current) cancelAnimationFrame(rafRef.current);
  rafRef.current = requestAnimationFrame(() => {
    setScrollTop(e.currentTarget.scrollTop);
  });
}, []);

// ✅ Best: Libraries (TanStack Virtual) handle this internally

⬆ Back to Top

Accessibility (A11y)

Virtualization creates a fundamental tension with accessibility. Screen readers rely on the DOM to understand content — they traverse DOM nodes to announce content, count items, and navigate. But virtualization removes most items from the DOM to improve performance. A screen reader visiting a virtualized list with 10,000 items would only "see" 20–30 DOM nodes and have no knowledge of the other 9,970+.

The solution is ARIA attributes that communicate the logical structure of the list (total count, each item's position) without requiring all items to be in the DOM. Combined with keyboard navigation that programmatically scrolls to items on arrow key presses, screen reader users can navigate the full list even though most items aren't rendered.

Challenge

Screen readers can only see items currently in the DOM. Off-screen virtualized items are invisible.

ARIA Attributes Approach

aria-rowcount on the container tells the screen reader the total number of items in the list, even though most aren't in the DOM. aria-rowindex on each rendered item tells the screen reader where this item sits in the full list (using 1-based indexing). Together, these attributes let the screen reader announce things like "Item 156 of 10,000" — giving the user full positional awareness despite only ~20 items existing in the DOM.

Container:
  role="list"
  aria-label="Search results"
  aria-rowcount={totalItems}           ← total count

Each item:
  role="listitem"
  aria-rowindex={index + 1}            ← 1-based position
  aria-setsize={totalItems}            ← total count
  aria-posinset={index + 1}            ← position in set

Keyboard Navigation

Keyboard navigation in virtualized lists requires extra work because the target item might not exist in the DOM yet. When the user presses Arrow Down to move to the next item, you must: (1) update the focused index in state, (2) tell the virtualizer to scrollToIndex so the target item gets rendered, and (3) set focus on the newly rendered DOM node. This three-step process — state update, scroll, focus — must happen in sequence, and the focus step often needs a requestAnimationFrame delay to wait for the item to actually render.

Key	Action
`↓` Arrow Down	Move focus to next item + `scrollToIndex`
`↑` Arrow Up	Move focus to prev item + `scrollToIndex`
`Home`	Jump to first item
`End`	Jump to last item
`Page Up/Down`	Scroll by page

A11y Checklist

The key principle is: tell the screen reader what it can't see. Use ARIA to communicate the full logical structure, keyboard handlers to enable navigation, and live regions to announce dynamic changes.

Requirement	How
Total count announced	`aria-rowcount` on container
Item position	`aria-rowindex`, `aria-posinset`, `aria-setsize`
Keyboard navigation	Arrow keys + `scrollToIndex`
Focus management	`tabIndex`, scroll-to-focused
Loading states	`aria-live="polite"` region
Table semantics	`<table>`, `<thead>`, `role="grid"`

⬆ Back to Top

Architecture Decision Guide

The biggest mistake teams make is reaching for virtualization too early (adding complexity to a 100-item list) or too late (discovering at scale that their non-virtualized table is unusable). The thresholds below are based on real-world measurements across typical React applications. Below ~200 items, the browser handles rendering efficiently and virtualization adds unnecessary complexity. Between 200-5K, simple virtualization provides a massive improvement. Beyond 5K, you need to combine virtualization with strategic data fetching. Beyond 100K in a table context, you need 2D virtualization. And at 1M+ cells, even virtualized DOM may not keep up — that's canvas territory.

Choosing the Right Pattern

How many items?

  < 200 items
  └─ Plain rendering. No virtualization needed.
     (CSS content-visibility: auto can help)

  200 – 5,000 items
  └─ Simple virtualization
     ├─ Fixed heights → react-window
     └─ Dynamic heights → react-virtuoso

  5,000 – 100,000 items
  └─ Virtualization + infinite scroll
     ├─ react-virtuoso (built-in endReached)
     └─ TanStack Virtual + TanStack Query

  100,000+ items (tables)
  └─ Row + Column virtualization
     ├─ TanStack Table + TanStack Virtual
     └─ AG Grid, Glide Data Grid

  1,000,000+ cells (extreme)
  └─ Canvas-based rendering
     └─ Glide Data Grid, custom canvas

Full Architecture for Data-Heavy App

The modern production stack for data-heavy applications follows a clear separation of concerns: data fetching (TanStack Query manages caching, pagination, and deduplication), data operations (TanStack Table handles sorting, filtering, column state), rendering optimization (TanStack Virtual calculates which items to render), and DOM output (your components render only the visible intersection). Each layer is independently testable and replaceable.

┌─────────────────────────────────────────────────────────┐
│                 Frontend Architecture                    │
│                                                          │
│  Search/Filter (debounced 300ms) + Sort Controls         │
│           │                                              │
│           ▼                                              │
│  ┌─────────────────────────────────────┐                │
│  │  TanStack Query (useInfiniteQuery)  │                │
│  │  Pages loaded on demand             │  Cursor-based  │
│  │  maxPages: 10 (memory limit)        │  pagination    │
│  └──────────────┬──────────────────────┘                │
│                 │ allItems = pages.flatMap(p => p.data)  │
│                 ▼                                        │
│  ┌─────────────────────────────────────┐                │
│  │  TanStack Table                     │                │
│  │  (columns, sorting, filtering)      │                │
│  └──────────────┬──────────────────────┘                │
│                 │ rows = table.getRowModel().rows        │
│                 ▼                                        │
│  ┌─────────────────────────────────────┐                │
│  │  TanStack Virtual                   │                │
│  │  Row virtualizer + Col virtualizer  │                │
│  │  Renders ~20-30 visible rows        │                │
│  └──────────────┬──────────────────────┘                │
│                 ▼                                        │
│  ┌─────────────────────────────────────┐                │
│  │  DOM: <table>                       │                │
│  │  Sticky <thead> (position: sticky)  │                │
│  │  Virtualized <tbody> (translateY)   │                │
│  └─────────────────────────────────────┘                │
└─────────────────────────────────────────────────────────┘

⬆ Back to Top

Real World Case Studies

These case studies show how real products solve virtualization challenges. The common thread is that each product hit a specific scale threshold where naive DOM rendering failed, and their solution was tailored to their specific constraints — dynamic heights for feeds, bidirectional scroll for chat, canvas for real-time finance.

Twitter/X Feed

Problem: Infinite feed with variable-height tweets
Solution:
  ├── Virtualized list (dynamic height measurement)
  ├── Intersection Observer for infinite loading
  ├── Cursor-based pagination (tweet ID as cursor)
  ├── Height pre-estimation + correction after paint
  └── Scroll position restoration on back-nav

Google Sheets

Problem: 1M+ cells, real-time collaboration, complex formatting
Solution:
  ├── Canvas-based rendering (only way at 1M+ scale)
  ├── Overlay <input> for cell editing
  ├── Only repaints dirty regions (not full canvas)
  ├── Web Worker for formula calculation
  └── ARIA grid overlay for screen readers

Slack Messages

Problem: Bidirectional scroll (old up, new down)
Solution:
  ├── react-virtuoso with reversed mode
  ├── firstItemIndex pattern for prepend stability
  ├── Auto-scroll on new messages (followOutput)
  └── "Jump to latest" button when scrolled up

Bloomberg Terminal

Problem: Real-time streaming data, thousands of instruments
Solution:
  ├── Canvas grid (DOM can't handle per-second updates)
  ├── Cell-level dirty tracking (repaint only changed cells)
  ├── WebSocket for streaming prices
  ├── Double-buffering canvas (avoid flicker)
  └── requestAnimationFrame batching

⬆ Back to Top

Common Pitfalls

Virtualization looks straightforward in demos but has subtle failure modes in production. Most pitfalls fall into three categories: measurement errors (wrong heights cause scroll position drift), React rendering issues (unnecessary re-renders kill scroll performance), and memory management (data grows unbounded). Understanding these patterns saves hours of debugging.

Pitfall	Symptom	Fix
Wrong item heights	Scroll jumping, gaps	Accurate `estimateSize`, use `measureElement`
Array index as key	Items swap/flash on scroll	Use stable IDs (`item.id`)
Unbounded data growth	Memory grows over time	Page eviction, `maxPages` in TanStack Query
No overscan	Blank flashes on fast scroll	Set overscan to 5–10
Inline functions in render	Unnecessary re-renders	`React.memo`, extract components
`overflow: hidden` parent	Scroll doesn't work	Ensure `overflow: auto` on scroll container
Dynamic content (images)	Layout shift after render	Reserve space with explicit dimensions
SSR mismatch	Hydration errors	`initialItemCount`, server render first N items

Memory Management for Infinite Scroll

Virtualization solves the DOM problem (only ~20 nodes in the DOM at any time) but doesn't solve the data problem. If a user scrolls through 500 pages of results, all 25,000 items are still in JavaScript memory even though only 20 are rendered. For most applications this is fine — JavaScript objects are lightweight compared to DOM nodes. But for very long sessions or memory-constrained devices, you need page eviction: keep only N pages of data in memory (e.g., maxPages: 10 in TanStack Query), and re-fetch evicted pages if the user scrolls back to them. This adds complexity but bounds total memory usage.

Problem: items array grows unbounded as user scrolls

  Page 1:   50 items   → fine
  Page 50:  2,500      → acceptable
  Page 500: 25,000     → memory problem!

Solutions:
  1. Virtualization handles DOM ✅ (only ~20 nodes)
  2. Limit data in memory:
     - TanStack Query: maxPages: 10
     - Custom: keep pages [current-5, current+2], evict rest
     - Re-fetch evicted pages if user scrolls back

⬆ Back to Top

Interview Questions

Virtualization is a common system design interview topic because it tests multiple skills simultaneously: understanding of browser rendering (why the DOM is expensive), algorithmic thinking (prefix sums, binary search for variable heights), API design (cursor vs offset pagination), and architectural judgment (when to use what tool). The questions below progress from conceptual understanding to system design.

Q1: What is virtualization and why is it needed?

Virtualization (windowing) = render only visible items + small overscan buffer. Needed because DOM is expensive — 10K+ nodes cause high memory, slow render, scroll jank. Keeps DOM count near-constant (~20–50 nodes) regardless of data size → O(1) render cost.

Q2: How does a virtualizer calculate which items to render?

Fixed height: startIndex = floor(scrollTop / itemHeight), visibleCount = ceil(containerHeight / itemHeight), add overscan. Total height = totalItems × itemHeight.

Variable height: Maintain prefix sum array of heights. Binary search on prefix sum to find startIndex for given scrollTop. Measure items post-render, update sizes dynamically.

Q3: How would you implement infinite scroll with virtualization?

Cursor-based API (?cursor=abc&limit=50)
useInfiniteQuery manages paginated cache
Flatten pages → single items array
Virtualizer renders visible items only
When last virtual item visible → fetchNextPage()
maxPages to limit memory

Q4: How do you handle column virtualization?

Two separate virtualizers:

Row virtualizer (vertical): which rows based on scrollTop
Column virtualizer (horizontal): which cols based on scrollLeft

Render only the intersection. Padding cells for non-rendered columns. TanStack Table + TanStack Virtual is the standard approach.

Q5: What are the accessibility challenges?

Screen readers can't see off-screen items. Solutions: aria-rowcount (total), aria-rowindex / aria-posinset (position), keyboard nav with scrollToIndex, aria-live for loading states, semantic <table> elements.

Q6: When would you use canvas over DOM virtualization?

Canvas when: 1M+ cells, real-time streaming data, high update frequency, read-only display.
Avoid canvas when: rich interactions, accessibility required, SEO needed, team lacks canvas expertise.

Q7: How do you prevent scroll position jumping?

Reserve space for media (explicit width/height)
Accurate estimateSize close to actual
Use measureElement to correct post-render
CSS contain: layout style paint on rows
Skeleton loading matching expected height

Q8: Design a virtualized grid — 100K rows, 50 columns, sortable, filterable.

API (cursor-paginated) → TanStack Query (cache + fetch)
  ↓
TanStack Table (column defs, sorting, filtering)
  ↓
Row Virtualizer + Column Virtualizer (TanStack Virtual)
  ↓
DOM <table>: sticky <thead>, virtualized <tbody>

Key decisions:
  - Server-side sort/filter (100K too much for client)
  - Row virtualizer: ~20-30 visible rows
  - Col virtualizer: ~8-10 visible columns
  - Fixed row height (40px) for predictability
  - Sticky header + sticky first column
  - Debounced filter (300ms) → new query
  - maxPages for memory management

Q9: How does "scroll to item" work with variable heights?

Virtualizer maintains offset map (prefix sum). To scroll to index N:

scrollTop = prefixSum[N] (start align)
Center: scrollTop = prefixSum[N] - containerHeight/2 + itemHeight/2
If unmeasured, use estimates → render → measure → correct position

APIs:
  react-window:   listRef.current.scrollToItem(index, 'center')
  react-virtuoso: virtuosoRef.current.scrollToIndex({ index, align: 'center' })
  TanStack:       virtualizer.scrollToIndex(index, { align: 'center' })

Q10: Compare `transform: translateY()` vs `position: absolute; top:`

Aspect	`translateY()`	`absolute + top`
Rendering	GPU compositing only	Triggers layout
Performance	Faster ✅	Slower
Used by	react-virtuoso, TanStack Virtual	react-window
Why better	Skips layout & paint phases, only compositing step

⬆ Back to Top

Quick Reference Card

Virtualization = render only visible items + overscan buffer
  ├── Math: startIndex = floor(scrollTop / itemHeight)
  ├── Position: translateY (GPU) > absolute top > padding
  └── DOM stays O(viewport), never O(n)

Libraries:
  react-window   → simple, fixed-size, ~6KB
  react-virtuoso → zero-config, dynamic, batteries, ~16KB
  TanStack Virtual → headless, any framework, ~4KB

Infinite Scroll:
  Intersection Observer + sentinel div (simple)
  Virtualized + useInfiniteQuery (production)
  Bidirectional + firstItemIndex (chat)

Tables:
  Row + Column virtualization for 2D
  TanStack Table (logic) + TanStack Virtual (rendering)
  Sticky: position: sticky + z-index layering

Canvas: 1M+ cells, real-time, read-only heavy
When NOT to virtualize: < 200 items

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Performance Monitoring & Observability

ZeeshanAli-0704 — Sun, 15 Mar 2026 17:24:41 +0000

Performance Monitoring & Observability

A Complete Frontend System Design Guide — Theory, Patterns & Interview Focus

You can build the most elegant UI in the world, but if it takes 5 seconds to load or janks on every scroll, users leave. Performance monitoring isn't a one-time audit — it's a continuous feedback loop that tells you when things are slow, why they're slow, and for whom.

This guide covers Core Web Vitals, identifying and fixing bottlenecks, monitoring strategies, error tracking, performance budgets, and the tools & techniques (Chrome DevTools, Lighthouse, RUM) that make all of it actionable — all from a conceptual, interview-ready perspective.

Core Web Vitals What They Are and Why They Matter
Identifying Performance Bottlenecks
Fixing Performance Issues A Systematic Approach
Chrome DevTools and Available Tools
Real User Monitoring (RUM) vs Synthetic Monitoring
Error Tracking and Logging
Performance Budgets
The Three Pillars of Observability
Tradeoffs Gotchas and Common Pitfalls
Interview Questions and Answers ⬆ Back to Top

Core Web Vitals What They Are and Why They Matter

Core Web Vitals are a set of user-centric performance metrics defined by Google. Since June 2021, they are Google ranking signals, making them critical for both UX and SEO. They answer three fundamental questions about user experience:

┌──────────────────────────────────────────────────────────┐
│                   Core Web Vitals                         │
│                                                           │
│   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐   │
│   │     LCP     │   │     INP     │   │     CLS     │   │
│   │  (Loading)  │   │(Responsive) │   │ (Stability) │   │
│   │             │   │             │   │             │   │
│   │ "How fast   │   │ "How fast   │   │ "How stable │   │
│   │  does the   │   │  does it    │   │  is the     │   │
│   │  main       │   │  react to   │   │  visual     │   │
│   │  content    │   │  my input?" │   │  layout?"   │   │
│   │  appear?"   │   │             │   │             │   │
│   └─────────────┘   └─────────────┘   └─────────────┘   │
└──────────────────────────────────────────────────────────┘

The 75th Percentile Rule

Google evaluates Core Web Vitals at the 75th percentile of all page visits. This means 75% of your users must have a "good" experience for you to pass. If your median LCP is 2.0s but your p75 is 3.5s, you fail the assessment.

LCP — Largest Contentful Paint

What it measures: The time from page load start to when the largest visible content element (hero image, heading text, video poster) finishes rendering in the viewport.

Rating	Time
Good	≤ 2.5s
Needs Improvement	2.5s – 4.0s
Poor	> 4.0s

LCP candidate elements: <img>, <video> poster, elements with background-image, and block-level text elements like <h1>, <p>.

What causes poor LCP and how to fix it:

Cause	Why It's Slow	Fix
Slow server response (high TTFB)	Server takes too long to return HTML	CDN, edge caching, optimize backend queries
Render-blocking CSS/JS	Large CSS/JS files block the parser and delay paint	Inline critical CSS, defer non-critical CSS/JS
Slow resource loading	Hero image is unoptimized (2MB PNG)	Compress images, use WebP/AVIF, responsive `srcset`
Client-side rendering	SPA waits for JS → API → render cycle	Use SSR/SSG, stream HTML from server
Lazy-loaded LCP element	Hero image has `loading="lazy"` — browser delays it	Never lazy-load above-the-fold content
No resource prioritization	Browser treats LCP image same as everything else	Use `fetchpriority="high"` on the LCP image, `<link rel="preload">`
Redirect chains	Multiple 301/302 redirects before actual page	Minimize redirects — each adds a full round trip

INP — Interaction to Next Paint

What it measures: INP measures the latency of all user interactions (clicks, taps, key presses) throughout the page's lifetime, and reports a value representing the worst interaction latency. It replaced FID in March 2024.

Rating	Time
Good	≤ 200ms
Needs Improvement	200ms – 500ms
Poor	> 500ms

Why INP replaced FID:

Aspect	FID (Deprecated)	INP (Current)
What's measured	Delay of first input only	All interactions throughout page life
Scope	Single event	Full session
Includes processing time?	No — only input delay	Yes — input delay + processing + presentation delay
Real-world coverage	Misses 99% of interactions	Comprehensive

The three phases of an interaction:

┌───────────────┬─────────────────────┬──────────────────────┐
│  Input Delay  │  Processing Time    │  Presentation Delay  │
│  (main thread │  (event handlers    │  (render, layout,    │
│   was busy)   │   executing)        │   paint, composite)  │
└───────────────┴─────────────────────┴──────────────────────┘
               ← ──── Total INP Latency ──── →

Input Delay: User clicked but the main thread was blocked by another task — the event handler is queued.
Processing Time: How long your event handler code takes to execute.
Presentation Delay: After handler finishes, how long until the browser paints the visual update.

What causes poor INP and how to fix it:

Cause	Why It's Slow	Fix
Long tasks on main thread	Heavy JS blocks the thread during interaction	Break tasks with `scheduler.yield()` or `setTimeout` chunking
Large DOM size	10,000+ nodes — layout/style recalculation is expensive	Virtualize long lists, simplify DOM structure
Expensive re-renders	Framework re-renders entire component tree	Memoize components, colocate state, use selectors
Forced synchronous layout	Reading layout props after writes causes "layout thrashing"	Batch DOM reads before writes
Third-party scripts	Ad/analytics scripts competing for main thread	Load async, defer, or move to Web Workers
No yielding in long handlers	Single handler runs 300ms without breaks	Yield to browser between chunks of work

CLS — Cumulative Layout Shift

What it measures: CLS quantifies how much visible content shifts unexpectedly during the page's lifetime. It measures visual stability — content jumping around without user interaction.

Rating	Score
Good	≤ 0.1
Needs Improvement	0.1 – 0.25
Poor	> 0.25

How CLS is calculated:

Layout Shift Score = Impact Fraction × Distance Fraction

Impact Fraction: Percentage of viewport affected by the shift
Distance Fraction: Greatest distance any element moved (as fraction of viewport)

CLS groups shifts into session windows (bursts within 1 second, max 5-second window). The largest session window is reported.

What causes poor CLS and how to fix it:

Cause	Why It Shifts	Fix
Images without dimensions	Image loads and pushes content down	Always set `width`/`height` or use CSS `aspect-ratio`
Ads/embeds without reserved space	Ad slot loads a 300px banner, pushing everything	Reserve space with min-height/aspect-ratio placeholders
Dynamically injected content	Cookie banner or notification pushes page down	Use `transform` animations, fixed/sticky positioning
Web font swap (FOUT)	Fallback font renders → web font loads → text reflows	Use `font-display: optional`, preload fonts, use `size-adjust`
Client-side rendering	Skeleton loads, then real content arrives with different dimensions	SSR/SSG, skeleton screens with correct dimensions
CSS animations using layout properties	Animating `top`/`left`/`width`/`height` triggers layout	Use `transform` (`translateY`, `scale`) — no layout cost

Supplementary Metrics Worth Knowing

Beyond the three Core Web Vitals, these metrics provide additional context:

Metric	What It Measures	Good Threshold
TTFB (Time to First Byte)	Server responsiveness — time until first byte of HTML arrives	≤ 800ms
FCP (First Contentful Paint)	Time until first text/image is painted on screen	≤ 1.8s
TTI (Time to Interactive)	Time until page is fully interactive (no long tasks blocking)	≤ 3.8s
TBT (Total Blocking Time)	Total time the main thread was blocked between FCP and TTI	≤ 200ms
Speed Index	How quickly visible content is populated (visual completeness)	≤ 3.4s

Interview insight: TTFB is not a Core Web Vital, but it's the root cause of most LCP issues. If TTFB is 2 seconds, your LCP can never be below 2 seconds. Always check TTFB first when debugging LCP.

⬆ Back to Top

Identifying Performance Bottlenecks

The hardest part of performance work isn't fixing issues — it's finding them. Here's a systematic approach to identifying bottlenecks across the loading, rendering, and interaction lifecycle.

The Performance Investigation Funnel

Step 1: What's the symptom?
         │
         ├── Page loads slowly        → Focus on loading metrics (LCP, TTFB, FCP)
         ├── Page feels janky/laggy   → Focus on interaction metrics (INP, TBT)
         ├── Content jumps around     → Focus on stability metrics (CLS)
         └── Specific action is slow  → Focus on that interaction's trace
         │
Step 2: Where is the bottleneck?
         │
         ├── Server response (TTFB)   → Backend/CDN issue
         ├── Resource downloading     → Large assets, no compression, no CDN
         ├── Render blocking          → CSS/JS blocking first paint
         ├── Main thread busy         → Heavy JS execution, long tasks
         ├── Layout thrashing         → DOM reads/writes interleaved
         └── Memory leaks             → Memory growing over time
         │
Step 3: Why is it slow?
         │
         Use Chrome DevTools to profile and trace the root cause

The Six Categories of Frontend Bottlenecks

┌──────────────────────────────────────────────────────────────────┐
│                Frontend Performance Bottlenecks                   │
│                                                                   │
│  ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────────┐  │
│  │  Network   │ │  Parsing   │ │  Rendering │ │  JavaScript  │  │
│  │            │ │  & Loading │ │  & Layout  │ │  Execution   │  │
│  │ • TTFB     │ │ • Large    │ │ • Complex  │ │ • Long tasks │  │
│  │ • Large    │ │   HTML     │ │   selectors│ │ • Unoptimized│  │
│  │   payloads │ │ • Render-  │ │ • Forced   │ │   frameworks │  │
│  │ • No CDN   │ │   blocking │ │   sync     │ │ • Memory     │  │
│  │ • No       │ │   resources│ │   layout   │ │   leaks      │  │
│  │   compress │ │ • Too many │ │ • Excessive│ │ • No code    │  │
│  │ • DNS/TLS  │ │   requests │ │   repaints │ │   splitting  │  │
│  └────────────┘ └────────────┘ └────────────┘ └──────────────┘  │
│                                                                   │
│  ┌────────────┐ ┌──────────────────────────────────────────────┐ │
│  │  Memory    │ │           Third-Party Scripts                 │ │
│  │            │ │                                               │ │
│  │ • Detached │ │ • Analytics, ads, chat widgets, tag managers │ │
│  │   DOM nodes│ │ • Competing for main thread time             │ │
│  │ • Event    │ │ • Blocking critical rendering                │ │
│  │   listener │ │ • Uncontrolled payload sizes                 │ │
│  │   leaks    │ │                                               │ │
│  └────────────┘ └──────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘

How to Identify Each Bottleneck Type

1. Network Bottlenecks

Symptoms: High TTFB, slow resource loading, waterfalls with large gaps.

How to find:

Chrome DevTools → Network panel → Sort by "Time" column → Look for requests > 1s
Check the Waterfall column — see if resources are loading sequentially instead of parallel
Look at TTFB (green bar in waterfall) — if it's large, the problem is server-side
Check Size column — large uncompressed assets are a red flag
Filter by "JS" or "CSS" — check if too many files are being loaded

Signs in the waterfall:
| Pattern | What It Means |
|---|---|
| Long green bar (TTFB) | Server is slow to respond |
| Long blue bar (download) | Asset is too large |
| Resources loading one after another | No parallelism — likely dependency chain or HTTP/1.1 |
| Many small requests | Consider bundling or using HTTP/2 multiplexing |
| Resources from many different domains | High DNS/TLS overhead per domain |

2. Render-Blocking Resources

Symptoms: Long gap between TTFB and FCP. Page is white for too long.

How to find:

Lighthouse audit → "Eliminate render-blocking resources" — lists every CSS/JS file that blocks rendering
DevTools → Performance panel → Record → Look for long "Parse HTML" → "Recalculate Style" → "Layout" before first paint
DevTools → Coverage tab (Ctrl+Shift+P → "Show Coverage") — shows what percentage of each CSS/JS file is actually used on this page

Key insight: A CSS file is render-blocking by default. A <script> tag without async/defer is parser-blocking. Both delay first paint.

3. Main Thread / JavaScript Bottlenecks

Symptoms: Poor INP, janky scrolling, slow interactions, high TBT.

How to find:

DevTools → Performance panel → Record an interaction → Look for Long Tasks (red-flagged bars > 50ms)
The "Main" thread flame chart shows exactly which functions are consuming time
Bottom-Up tab → Sort by "Self Time" to find the most expensive individual functions
Call Tree tab → Shows the call hierarchy, find root causes
Check for "Recalculate Style" and "Layout" entries — signs of layout thrashing

What Long Tasks look like:

Main Thread Timeline
─────────────────────────────────────────────
│▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│ 120ms Long Task (red flag!)
│   ▓▓▓│ 20ms task
│ ▓▓▓▓▓▓▓▓▓│ 60ms Long Task
│▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│ 200ms Long Task (very bad!)
─────────────────────────────────────────────
Any task > 50ms is a "Long Task" that blocks interactions

4. Layout & Rendering Bottlenecks

Symptoms: CLS issues, janky animations, slow scroll.

How to find:

DevTools → Performance panel → Look for frequent "Layout" entries (purple bars) — each is a forced reflow
DevTools → Rendering tab → Enable "Layout Shift Regions" — flashes blue on areas that shift
DevTools → Rendering tab → Enable "Paint flashing" — green flashes show what's being repainted
DevTools → Layers panel — shows which elements have their own compositing layer

Layout thrashing pattern: Reading then writing to DOM repeatedly forces the browser to recalculate layout between each read-write pair. The fix is to batch all reads first, then all writes.

5. Memory Issues

Symptoms: Page gets slower over time, eventually crashes. Tab's memory in Task Manager keeps growing.

How to find:

DevTools → Memory panel → Take heap snapshots at different points → Compare for growing objects
DevTools → Performance Monitor (real-time) → Watch "JS heap size" and "DOM Nodes" over time
Chrome Task Manager (Shift+Esc) → Check if your tab's memory keeps growing

Common causes:
| Cause | What Happens | Fix |
|---|---|---|
| Detached DOM nodes | Removed elements still referenced in JS | Null references when removing elements |
| Event listeners not cleaned up | Each re-render adds new listeners without removing old ones | Use removeEventListener, or cleanup in React's useEffect return |
| Growing arrays/maps | Data accumulates without bounds | Set limits, use LRU eviction |
| Closures retaining large scope | Functions hold references to outer scope variables | Be mindful of what closures capture |
| setInterval without clearInterval | Timers keep running even after component unmounts | Always clear in cleanup/teardown |

6. Third-Party Script Issues

Symptoms: Everything seems optimized but Lighthouse still shows poor scores. Long Tasks you don't recognize.

How to find:

DevTools → Performance panel → Look at Long Tasks → Check if the source URL is a third-party domain
DevTools → Network panel → Filter by "Third-party" → Check sizes and timing
Lighthouse → "Reduce the impact of third-party code" audit
Use the web-vitals attribution build to see if third-party scripts cause poor INP/LCP
Chrome → chrome://inspect/#devices → Check Service Workers for third-party scripts

⬆ Back to Top

Fixing Performance Issues A Systematic Approach

Once you've identified the bottleneck, here's a structured approach to fixing each category:

Loading Performance Fixes (Improve LCP, TTFB, FCP)

Problem	Fix	Impact
High TTFB	Deploy CDN, enable edge caching, optimize backend queries, use streaming SSR	High
Large JS bundles	Code splitting (route-based), tree shaking, lazy imports for below-fold features	High
Large images	Compress, use WebP/AVIF, responsive `srcset`, proper sizing	High
Render-blocking CSS	Inline critical CSS (above-fold styles), defer rest with `media="print"` hack or async loading	High
Render-blocking JS	Add `defer` or `async` attribute, move scripts to bottom of body	Medium
No resource hints	`<link rel="preload">` for LCP image, `<link rel="preconnect">` for critical origins	Medium
Too many HTTP requests	Bundle small files, use HTTP/2 (automatic multiplexing), use image sprites or SVG sprites	Medium
No compression	Enable Brotli or Gzip on server/CDN	Medium
Redirect chains	Eliminate unnecessary 301/302 redirects	Low-Medium

Interaction Performance Fixes (Improve INP, TBT)

Problem	Fix	Impact
Long event handlers	Break into async chunks with `scheduler.yield()` or `setTimeout(fn, 0)`	High
Heavy computation	Move to Web Worker (runs off main thread)	High
Framework over-rendering	Memoize components (`React.memo`, `useMemo`), colocate state closer to where it's used	High
Large DOM	Virtualize long lists (react-window, TanStack Virtual), simplify nested structures	Medium
Layout thrashing	Batch DOM reads before writes, use `requestAnimationFrame` for DOM mutations	Medium
Frequent forced reflows	Avoid reading layout properties (`offsetHeight`, `getBoundingClientRect`) inside write loops	Medium
Third-party scripts	Load non-essential scripts with `defer`/`async`, use `Partytown` to run them in a Web Worker	Medium

Visual Stability Fixes (Improve CLS)

Problem	Fix	Impact
Images without dimensions	Always set `width`/`height` attributes or CSS `aspect-ratio`	High
Dynamic content insertion	Reserve space with placeholders, use `min-height` on containers	High
Font swapping	Use `font-display: optional` (no shift) or `size-adjust` to match fallback metrics	Medium
Injected ads/embeds	Reserve exact space with aspect-ratio containers	Medium
CSS animations using layout properties	Use `transform` and `opacity` only — they skip layout and paint phases	Medium
Late-loading above-fold content	Prioritize critical content loading, SSR/SSG	Medium

The Fix Priority Framework

When multiple issues exist, prioritize by impact × effort:

                        High Impact
                            │
         ┌──────────────────┼──────────────────┐
         │                  │                  │
         │   QUICK WINS     │   BIG PROJECTS   │
         │   (Do first)     │   (Plan & do)    │
         │                  │                  │
         │  • Preload LCP   │  • SSR/SSG       │
Low ─────│  • Image formats │  • Code splitting│───── High
Effort   │  • Add defer/    │  • Web Workers   │  Effort
         │    async         │  • Virtualization │
         │  • Set img dims  │  • Architecture  │
         │                  │    changes       │
         │   FILL-INS       │   AVOID          │
         │   (Do if time)   │   (Low ROI)      │
         │                  │                  │
         │  • DNS prefetch  │  • Rewriting in  │
         │  • Minor CSS     │    new framework │
         │    cleanup       │  • Over-          │
         │                  │    optimization  │
         └──────────────────┼──────────────────┘
                            │
                        Low Impact

⬆ Back to Top

Chrome DevTools and Available Tools

Chrome DevTools — Your Primary Performance Tool

Chrome DevTools has several panels specifically designed for performance investigation. Understanding which panel to use for which problem is crucial.

DevTools Panel	What It Shows	When to Use
Performance	Flame chart of main thread activity, Long Tasks, network waterfall, screenshots	Profiling specific interactions, diagnosing INP/TBT, finding expensive functions
Network	All network requests, waterfall timing, sizes, headers	Debugging loading issues, finding large assets, checking compression/caching
Lighthouse	Full page audit — Performance, Accessibility, SEO, Best Practices scores	Quick overall health check, getting actionable recommendations
Memory	Heap snapshots, allocation timelines, garbage collection	Debugging memory leaks, finding detached DOM nodes
Coverage	Shows how much of each CSS/JS file is actually used	Finding dead code to remove or defer
Rendering	Layout shift visualization, paint flashing, layer borders, FPS meter	Debugging CLS, finding unnecessary repaints, checking compositing
Application	Storage (Cache, IndexedDB, localStorage), Service Workers	Debugging caching strategies, checking storage usage
Performance Monitor	Real-time CPU, heap size, DOM nodes, event listeners, style recalculations	Quick live overview of performance health

How to Use the Performance Panel (Step by Step)

The Performance panel is the most powerful tool for diagnosing bottlenecks:

Open DevTools → Performance tab
Click Record (or Ctrl+E) → Perform the slow action → Stop recording
Read the flame chart top-down:
- Network row — shows when resources loaded
- Frames row — shows frame rate (red = dropped frames)
- Main row — the flame chart of all main thread activity
- Red corners on tasks = Long Tasks (> 50ms) — these are your targets
Click on a Long Task → See the call stack in the Bottom-Up / Call Tree tabs
Bottom-Up tab (sort by Self Time) → Find which functions consumed the most time
Summary tab → Shows time breakdown: Scripting, Rendering, Painting, Idle

What to look for in the flame chart:

Pattern	Meaning	Fix
Wide yellow blocks	Long JavaScript execution	Break up tasks, optimize algorithm, Web Worker
Wide purple blocks	Layout/style recalculation	Reduce DOM complexity, batch DOM writes
Wide green blocks	Paint/composite	Reduce painted area, promote to GPU layer
Many narrow purple + yellow alternating	Layout thrashing	Batch reads before writes
Large red-cornered blocks	Long Tasks blocking interactions	Yield to browser between chunks

How to Use the Network Panel Effectively

Technique	How	What It Reveals
Sort by Size	Click "Size" column header	Largest assets to optimize
Sort by Time	Click "Time" column header	Slowest requests
Check Waterfall	Look at the colored bars	Where time is spent (DNS, TLS, TTFB, download)
Use Throttling	Change "No throttling" to "Slow 3G" or "Fast 3G"	How your site feels on slow networks
Check Disable cache	Tick the checkbox	See first-visit experience
Filter by type	Click JS, CSS, Img, Font, etc.	Focus on specific resource types
Check gzip/Brotli	Compare "Size" vs "Content" columns	Is compression enabled?
Right-click → "Block request URL"	Block specific scripts	Test impact of removing third-party scripts

How to Use the Coverage Tab

Ctrl+Shift+P → Type "Show Coverage" → Enter
Click the reload button in the Coverage panel
See a list of all CSS/JS files with percentage used

Usage	What It Means	Action
< 30% used	Heavy dead code	Extract critical portion, lazy-load the rest
30-70% used	Some dead code	Consider code splitting per route
> 70% used	Mostly needed	Focus optimization elsewhere

How to Use the Rendering Tab for CLS

Ctrl+Shift+P → "Show Rendering"
Enable "Layout Shift Regions" — blue rectangles flash where layout shifts occur
Slowly scroll and interact with the page — watch for unexpected blue flashes
Enable "Paint Flashing" — green rectangles show what's being repainted (excessive repaints = performance drain)

The Full Toolkit Beyond Chrome DevTools

Tool	Type	Best For
Lighthouse (in DevTools or CLI)	Lab / Synthetic	Quick audit, actionable recommendations, scores
PageSpeed Insights	Lab + Field (CrUX)	Checking real-user data alongside lab results
WebPageTest	Lab (real devices)	Detailed waterfall analysis, filmstrip view, multi-step testing
Chrome UX Report (CrUX)	Field (28-day rolling)	Google's official real-user performance data per origin
Google Search Console	Field (CrUX)	SEO impact of Core Web Vitals, URL-level reports
`web-vitals` JS library	Field (RUM)	Custom RUM collection in your own analytics pipeline
Bundle analyzers (`webpack-bundle-analyzer`, `source-map-explorer`)	Build-time	Visualizing what's in your JS bundles, finding bloat
`size-limit` / `bundlesize`	CI/CD	Enforcing bundle size budgets in pull requests
Sentry Performance	RUM + Tracing	Real-user performance monitoring with error correlation
Datadog RUM / New Relic Browser	RUM	Enterprise-grade real-user monitoring with dashboards
DebugBear / SpeedCurve / Calibre	Synthetic + Field	Continuous monitoring with historical trends

Lab vs Field Data — Critical Distinction

Aspect	Lab Data	Field Data
Source	Simulated on controlled device	Real users in production
Tools	Lighthouse, WebPageTest, DevTools	CrUX, web-vitals, Datadog, Sentry
Reproducible	Yes — same conditions every run	No — varies per user
Covers real diversity	No — fixed device/network	Yes — all devices, networks, locations
When available	Anytime (dev, CI/CD)	Only after deployment with real traffic
Use for debugging	Yes — drill into specific issues	Harder — aggregated data
Use for Google ranking	No — Google uses field data only	Yes — CrUX field data drives ranking

Interview insight: Google uses field data (CrUX) for ranking, not lab data. Lighthouse can be 100/100 but if real users on slow phones have poor LCP, your ranking still suffers. That's why RUM matters.

⬆ Back to Top

Real User Monitoring (RUM) vs Synthetic Monitoring

Synthetic Monitoring

Runs automated tests against your site from controlled environments — specific devices, networks, and locations — on a scheduled basis or in CI/CD.

┌──────────────────────────────────────────────────┐
│              Synthetic Monitoring                  │
│                                                   │
│  Scheduled Agent ──→ Load Page ──→ Collect Metrics│
│  (headless browser)  (controlled    (LCP, FCP,    │
│                       conditions)    waterfall)    │
│                                                   │
│  ✅ Same device, network, location every time      │
│  ✅ Reproducible — great for regression detection  │
│  ❌ Doesn't represent real user diversity          │
└──────────────────────────────────────────────────┘

When it runs: Scheduled intervals (hourly/daily), CI/CD pipeline (every PR), or on-demand audits.

Real User Monitoring (RUM)

Collects performance data from actual users as they interact with your site. Every page load, every interaction, every error — from real devices, networks, and locations.

┌──────────────────────────────────────────────────┐
│           Real User Monitoring (RUM)              │
│                                                   │
│  Real User ──→ Loads Page ──→ Browser APIs        │
│  (varied device,  (real network   collect data    │
│   location,        conditions)    automatically)  │
│   browser)              │                         │
│                         ▼                         │
│               Beacon/Fetch ──→ Analytics Backend  │
│               (send data home)  (aggregate, dash) │
│                                                   │
│  ✅ Represents EVERY real user's experience        │
│  ✅ Catches long-tail issues (slow 3G in India)   │
│  ❌ Noisy data — requires percentile analysis     │
└──────────────────────────────────────────────────┘

Head-to-Head Comparison

Dimension	Synthetic	RUM
Data source	Simulated agents	Real users in production
Environment	Controlled (fixed device/network)	Diverse (every user's real conditions)
Consistency	Highly reproducible	Noisy, varies per user
Coverage	Only pages/flows you configure	Every page every user visits
Catches regressions	Proactively (before users see them)	Reactively (after deployment)
Third-party impact	May miss real behavior	Captures actual third-party impact
Geographic coverage	Limited test locations	Global (wherever users are)
Cost	Fixed per test run	Scales with traffic volume

When to Use Which

Scenario	Best Approach	Why
Pre-deployment regression check	Synthetic	Catch issues before users see them
Understand p75/p95 user experience	RUM	Real data from real users
Monitor uptime & availability	Synthetic	Runs even when no users are online
Debug by region/device/connection	RUM	Segment by real user dimensions
A/B test performance impact	RUM	Measure real-world impact
CI/CD quality gate	Synthetic	Automated, deterministic pass/fail
Catch long-tail issues (5% on slow 3G)	RUM	Won't show in synthetic at all

The Ideal Strategy — Use Both

Development ──→ CI/CD Pipeline ──→ Production

Lighthouse        Lighthouse CI       RUM (all users)
in DevTools       assertions          │
(manual)          (fail build if      ├─ Dashboards (p75/p95)
                   LCP > 2.5s)       ├─ Segment by region, device
                                      ├─ Alerts on regressions
                  Scheduled           └─ Correlate with errors
                  Synthetic
                  (hourly)

Key insight: Synthetic catches regressions early (before users see them). RUM shows the real impact on actual users. Together, they provide complete visibility.

How RUM Data Collection Works (Conceptual)

The core pattern for collecting real user performance data:

Instrument the page — add the web-vitals library (or equivalent) to every page
Collect metrics — CWV values fire when available (LCP on navigation, CLS on page hide, INP on page hide)
Buffer events — batch multiple metrics together to reduce network calls
Send via sendBeacon — navigator.sendBeacon() is the recommended method because it survives page unload (the user leaving the page). Regular fetch() might be cancelled.
Enrich with context — attach user agent, connection type (navigator.connection.effectiveType), device memory, geographic info (from server), and page URL
Aggregate on the backend — compute p50, p75, p95 per route, per device type, per connection speed, per region
Alert on threshold breaches — if p75 LCP crosses 2.5s, alert the team

Why sendBeacon? When a user clicks a link or closes the tab, the browser cancels pending fetch() requests. sendBeacon() is specifically designed to survive page transitions — it queues the request and the browser completes it even after navigation.

⬆ Back to Top

Error Tracking and Logging

Errors in production are inevitable. The difference between a minor issue and a catastrophe is how quickly you detect, diagnose, and resolve them.

Why Frontend Error Tracking Matters

90% of frontend errors go unreported by users — they just leave
JavaScript errors can completely break an SPA's functionality
Silent failures (API errors swallowed by catch blocks) go unnoticed without tracking
Cross-browser issues — an error in Safari might not reproduce in Chrome
Third-party scripts throw errors outside your control

Without error tracking, you're flying blind — relying on user complaints to discover issues that may have been happening for days.

Types of Frontend Errors

Error Type	Example	How It's Caught
Unhandled exceptions	`TypeError: Cannot read property 'x' of undefined`	`window.onerror` or `window.addEventListener('error')`
Unhandled promise rejections	Failed `fetch()` without `.catch()`	`window.addEventListener('unhandledrejection')`
Network errors	API returns 500, CORS failure, timeout	`fetch` wrapper or Axios interceptor
Resource load failures	CSS/JS/image 404	`window.addEventListener('error', fn, true)` (capture phase — resource errors don't bubble)
Framework/render errors	Error during React render crashes component tree	Error Boundaries (React), `Vue.config.errorHandler` (Vue)
Custom business logic	User can't checkout, payment fails	Manual error capture call in application logic

How Error Tracking Tools Work (Conceptual)

Error Occurs in Browser
         │
         ▼
┌──────────────────────┐
│  Error Tracking SDK  │
│  (e.g., Sentry)      │
│                       │
│  1. Capture the error │
│  2. Extract stack     │
│     trace             │
│  3. Collect context:  │
│     • Breadcrumbs     │
│       (user actions   │
│       leading up)     │
│     • Browser/OS/     │
│       device info     │
│     • User identity   │
│     • Current URL     │
│     • Console logs    │
│  4. Apply source maps │
│     (minified →       │
│      readable code)   │
│  5. Send to backend   │
└──────────┬────────────┘
           │
           ▼
┌──────────────────────┐
│  Error Tracking       │
│  Backend              │
│                       │
│  1. Deduplicate —     │
│     group similar     │
│     errors into one   │
│     "issue"           │
│  2. Link to release/  │
│     commit that       │
│     introduced it     │
│  3. Track frequency   │
│     and affected      │
│     user count        │
│  4. Send alerts       │
│     (Slack, PagerDuty)│
└──────────────────────┘

Key Error Tracking Concepts

Concept	What It Means	Why It Matters
Issue grouping	Thousands of the same `TypeError` get grouped into one "issue"	Without grouping, you'd see 10,000 separate errors instead of one issue affecting 10,000 users
Breadcrumbs	Automatic trail of user actions before the error (clicks, navigations, API calls, console logs)	Shows you what the user did that led to the error — like a flight recorder
Source maps	Map minified production code back to original source	Without them, stack traces show `a.js:1:42305` instead of `CartTotal.tsx:42`
Release tracking	Tag errors with the deployment version (`v1.2.3`)	Know exactly which deploy introduced the regression
Suspect commits	Tool identifies which Git commit likely caused the error	Go from "we have a bug" to "this commit changed the broken code" in seconds
Session replay	Video-like recording of the user's session (DOM changes, clicks, scrolls)	See exactly what the user experienced — invaluable for reproducing bugs
Sampling	Only capture a percentage of events (e.g., 10% of performance traces)	Control costs — you don't need 100% of identical errors

Error Tracking Tools Comparison

Feature	Sentry	LogRocket	Datadog
Primary focus	Error tracking & alerting	Session replay & debugging	Full-stack observability
Error grouping	Excellent	Basic	Good
Session replay	Yes (built-in)	Best-in-class	Yes
Source maps	Yes	No	Yes
Release tracking	Yes (suspect commits)	No	Yes
Performance (RUM)	Yes	Basic	Yes
Alerting	Advanced (Slack, PagerDuty, rules)	Basic	Advanced
Best for	Error detection & alerting	Understanding user experience	Full-stack teams

Practical recommendation: Use an error tracker (like Sentry) with session replay for error-specific sessions. The combination of "what broke" (stack trace) + "what the user saw" (replay) is the fastest path to diagnosing production issues.

Alert Tiers — The Traffic Light System

Not all errors are equal. Structure your alerts to avoid alert fatigue:

Tier	Condition	Alert Channel	Response
P0 — Critical	Error rate > 5% of sessions, payment/auth flow broken	PagerDuty → On-call engineer	< 15 min
P1 — High	New error in critical flow, > 100 events/hour	Slack #incidents	< 1 hour
P2 — Medium	New error in non-critical flow, < 100 events/hour	Slack #frontend-errors	< 1 day
P3 — Low	Cosmetic errors, third-party script errors	Weekly digest email	Next sprint

Structured Logging Principles

Effective frontend logging follows these principles:

Always include context — timestamp, URL, user ID, session ID, error severity
Use structured format — JSON objects, not string concatenation. Structured logs are searchable and aggregatable.
Include breadcrumbs — log navigation events, API calls, and user actions so you can reconstruct what happened
Sanitize sensitive data — never log passwords, tokens, credit card numbers, or PII
Use sendBeacon for delivery — survives page unload, won't block the main thread
Set severity levels — debug, info, warn, error, fatal — filter by level in production
Sample in production — you don't need 100% of logs. Sample info at 10%, capture all error and fatal.

⬆ Back to Top

Performance Budgets

A performance budget is an agreed-upon set of limits on metrics that affect user experience. Like a financial budget, it forces trade-off conversations and prevents the gradual performance degradation that happens in every growing project.

The Boiling Frog Problem

Without budgets, performance degrades invisibly:

Sprint 1:   Bundle = 150 KB   ← "Fast enough"
Sprint 5:   Bundle = 220 KB   ← "Just one more library..."
Sprint 10:  Bundle = 380 KB   ← "When did this get slow?"
Sprint 15:  Bundle = 550 KB   ← "We need a performance sprint"

With a budget (200 KB limit):
Sprint 5:   Bundle = 195 KB   ← ⚠️ Warning: approaching budget
Sprint 6:   PR adds 15 KB    ← ❌ BUILD FAILS — exceeds 200 KB
            → Developer must optimize or justify before merging

Types of Performance Budgets

Budget Type	What It Limits	Examples
Quantity-based	Number/size of resources	Max 170 KB JS (gzipped), max 50 KB CSS, max 5 third-party scripts
Timing-based	User-centric timing metrics	LCP ≤ 2.5s, FCP ≤ 1.5s, TTI ≤ 3.5s
Score-based	Audit tool scores	Lighthouse Performance ≥ 90, Accessibility ≥ 95

Recommended Budget Template

Category	Metric	Budget	Enforcement
Loading	LCP	≤ 2.5s	Lighthouse CI assertion
Interactivity	INP	≤ 200ms	RUM alerting
Stability	CLS	≤ 0.1	Lighthouse CI assertion
JS bundle	Main bundle (gzipped)	≤ 170 KB	CI size check tool
CSS	Total CSS (gzipped)	≤ 50 KB	CI size check tool
Images	Hero/LCP image	≤ 100 KB	CI check or manual review
Fonts	Total web fonts	≤ 75 KB, max 2 families	Manual review
Third-party	Total third-party JS	≤ 50 KB	Lighthouse audit
Total page	Total page weight	≤ 500 KB	Lighthouse CI
Lighthouse	Performance score	≥ 90	Lighthouse CI assertion

How to Enforce Performance Budgets

Level	Tool / Method	What It Does
IDE	"Import Cost" VS Code extension	Shows bundle size impact of every import inline as you code
Build	Webpack `performance.hints: 'error'` / Vite `chunkSizeWarningLimit`	Fails build if bundles exceed configured size
CI/CD	`bundlesize` or `size-limit`	Checks gzipped bundle sizes against budgets on every PR
CI/CD	Lighthouse CI assertions	Runs Lighthouse on every PR, fails if metrics exceed thresholds
Production	RUM alerting	Alerts when real-user p75 metrics cross budget thresholds

How to Set Performance Budgets

Benchmark current state — run Lighthouse and record your current metrics
Check competitors — benchmark 2-3 competitors for the same metrics
Set goals 20% better than current — or match Google's "Good" thresholds as minimum
Get team buy-in — budgets without enforcement are just wishes
Enforce in CI/CD — automated enforcement removes debates on every PR
Review quarterly — adjust budgets as the app evolves

⬆ Back to Top

The Three Pillars of Observability

Frontend observability goes beyond performance — it's about having complete visibility into what your application is doing in production.

The Three Pillars

Pillar	What It Captures	Frontend Examples
Metrics	Numeric measurements over time	LCP values, error rates, API latency, JS heap size
Logs	Discrete events with context	Errors, user actions, state changes, API responses
Traces	End-to-end request flow across services	User click → API call → backend processing → response → UI update

Why all three matter — they answer different questions:

Metrics tell you SOMETHING is wrong:
  → "Error rate spiked to 5% at 14:30"

Logs tell you WHAT went wrong:
  → "TypeError: Cannot read property 'price' of null in CartTotal.tsx:42"

Traces tell you WHERE in the chain it broke:
  → "User click → /api/cart (200 OK, but price=null) → CartTotal render → crash"

The Frontend Observability Pipeline

┌───────────────────────────────────────────────────────────┐
│                        Browser                             │
│                                                            │
│  Performance APIs ──→ web-vitals ──→ RUM Collector         │
│  Error events     ──→ Sentry SDK ──→ Error Tracker         │
│  User actions     ──→ Session Replay ──→ Replay Store      │
│  Custom events    ──→ Analytics SDK ──→ Event Stream        │
│                                                            │
└────────────────────────┬──────────────────────────────────┘
                         │ (sendBeacon / fetch)
                         ▼
┌───────────────────────────────────────────────────────────┐
│                   Ingestion Layer                          │
│            (API Gateway / Event Queue)                     │
└──────┬──────────────┬──────────────┬──────────────────────┘
       │              │              │
┌──────▼─────┐ ┌──────▼─────┐ ┌─────▼────────┐
│  Metrics   │ │   Logs     │ │   Traces     │
│  Store     │ │   Store    │ │   Store      │
└──────┬─────┘ └──────┬─────┘ └──────┬───────┘
       │              │              │
┌──────▼──────────────▼──────────────▼───────────────────────┐
│              Visualization & Alerting                       │
│                                                             │
│  • Dashboards (p75/p95 by route, device, region)           │
│  • Alerts (Slack/PagerDuty on threshold breaches)          │
│  • SLO tracking (99.5% of loads with LCP < 2.5s)          │
└─────────────────────────────────────────────────────────────┘

Distributed Tracing for Frontend

Distributed tracing connects a user interaction in the browser to all the backend services involved. It works by propagating a trace ID across service boundaries:

Browser (frontend span)
  └─→ trace-id header ──→ API Gateway (span)
      └─→ Order Service (span)
          └─→ Payment Service (span)
              └─→ Database query (span)

Full trace: Click → Validate → API → Payment → DB → Response → UI Update

This is how you answer "why was this checkout call slow for this user?" — you see the entire chain with timing for each step. Tools like Sentry Tracing, Datadog APM, and OpenTelemetry enable this.

⬆ Back to Top

Tradeoffs Gotchas and Common Pitfalls

Common Mistakes

Pitfall	What Goes Wrong	Prevention
Optimizing without measuring	Guessing where slowness is → wasting effort on wrong things	Always profile first — measure, then optimize
Measuring median instead of p75	Median hides long-tail issues that affect 25%+ of users	Google uses p75. Always track p75 and p95.
Lab-only testing	Lighthouse is 100 but real users on slow phones have poor experience	Combine Lighthouse (lab) with RUM (field)
No performance budget	Performance degrades gradually with every sprint	Set budgets, enforce in CI/CD
Alert fatigue	Too many alerts → team ignores all of them	Tier alerts (P0-P3), filter known noise
Not uploading source maps	Production stack traces are unreadable minified code	Upload source maps to your error tracker on every deploy
Over-sampling in RUM	Sending every metric from every user = high cost, no extra value	Sample performance traces at 10-20%, capture all errors at 100%
Ignoring third-party scripts	Your code is fast but GTM + ads + chat widgets add 500ms	Audit third-party impact regularly, use Lighthouse's third-party audit
Testing on developer machines only	Fast MacBook Pro ≠ budget Android phone on 3G	Use CPU/network throttling in DevTools, test on real devices
Chasing Lighthouse score	100/100 Lighthouse doesn't mean real users are happy	Lighthouse is a starting point. RUM is the truth.

Platform-Specific Considerations

Platform	Consideration
Mobile (general)	Always test with CPU throttling (4x–6x slowdown). Median phones are much slower than dev machines.
iOS Safari	No Background Sync, no Periodic Sync, limited Service Worker support. Test on real iOS devices — simulators don't accurately reflect performance.
Low-end Android	2-4 GB RAM, slow CPUs. These are your p75/p95 users. Budget Android phones represent the majority of global web traffic.
Slow networks	Always test on "Fast 3G" and "Slow 3G" throttling. Most of the world isn't on fast broadband.
High-DPI displays	Serving 2x/3x images without responsive sizing burns bandwidth and hurts LCP.

⬆ Back to Top

Interview Questions and Answers

Q1: What are Core Web Vitals and why do they matter?

A: Core Web Vitals are three Google-defined metrics that measure real-world user experience:

LCP (Largest Contentful Paint) — loading speed. Measures when the largest content element is rendered. Target: ≤ 2.5s.
INP (Interaction to Next Paint) — responsiveness. Measures how quickly the page responds to user interactions. Target: ≤ 200ms.
CLS (Cumulative Layout Shift) — visual stability. Measures unexpected layout shifts. Target: ≤ 0.1.

They matter because: (1) Google uses them as SEO ranking signals since June 2021, (2) they're measured at the 75th percentile of real user data, and (3) they directly correlate with user engagement metrics like bounce rate and conversion.

Q2: Why did INP replace FID?

A: FID (First Input Delay) only measured the delay of the first interaction, and it only captured input delay (not processing or presentation time). This meant:

It missed slow interactions later in the page lifecycle (e.g., a button that becomes slow after data loads)
A page could have great FID but terrible responsiveness on the 10th interaction
It didn't account for how long event handlers took to execute

INP measures all interactions throughout the entire page lifecycle and captures the full latency (input delay + processing time + presentation delay). It reports the worst interaction, giving a much more comprehensive picture of responsiveness.

Q3: How would you improve LCP on a slow-loading page?

A: I'd follow a systematic approach:

Check TTFB first — if the server takes 2s to respond, LCP can never be under 2s. Fix with CDN, caching, backend optimization.
Identify the LCP element — use DevTools Performance panel or web-vitals attribution to find which element is the LCP candidate.
Preload the LCP resource — if it's an image, add <link rel="preload"> and fetchpriority="high". If it's text, ensure fonts are preloaded.
Remove render-blocking resources — inline critical CSS, defer non-critical CSS/JS.
Never lazy-load the LCP element — loading="lazy" on the hero image is a common mistake.
Optimize the resource itself — compress images to WebP/AVIF, use responsive srcset, proper sizing.
Consider SSR/SSG — if the page is client-side rendered, the LCP has to wait for JS → fetch → render. Server rendering eliminates that chain.

Q4: How would you improve INP?

A: INP issues come from three phases — I'd diagnose which phase is the problem:

Input Delay is high → The main thread was busy when the user interacted. Break up Long Tasks, defer non-critical work, reduce third-party script impact.
Processing Time is high → Event handlers take too long. Optimize the handler, yield to the browser with scheduler.yield() between chunks, move heavy computation to a Web Worker.
Presentation Delay is high → The visual update after the handler is expensive. Reduce DOM complexity, avoid layout thrashing, simplify CSS selectors.

I'd use the web-vitals attribution build to identify which interaction is the slowest and which phase dominates, then profile that specific interaction in DevTools Performance panel.

Q5: How do you prevent CLS?

Always set dimensions on images/videos — use width/height attributes or CSS aspect-ratio so the browser reserves space before loading
Reserve space for dynamic content — ads, embeds, cookie banners should have min-height or aspect-ratio containers
Use font-display: optional for web fonts — prevents font swap layout shifts entirely (or use size-adjust to match fallback font metrics)
Use transform for animations — never animate top, left, width, height (layout triggers). transform and opacity skip layout and paint entirely.
SSR/SSG — avoid the client-side rendering pattern where skeleton → data → layout shift

Q6: What's the difference between RUM and Synthetic monitoring?

A: Synthetic monitoring runs automated tests from controlled environments (fixed device, network, location). It's reproducible, proactive (catches issues before users see them), and great for CI/CD quality gates. But it doesn't represent real user diversity.

RUM (Real User Monitoring) collects data from actual users in production — real devices, real networks, real locations. It catches long-tail issues (the 5% of users on slow 3G in India), captures third-party script impact, and shows actual user experience. But it's reactive (data only after deployment) and noisy (requires percentile analysis).

Best practice: Use both together. Synthetic in CI/CD to prevent regressions. RUM in production to validate real impact. Google uses field data (RUM/CrUX) for ranking, not lab data.

Q7: What is a performance budget and how do you enforce it?

A: A performance budget is an agreed-upon threshold for metrics that a page must not exceed — like a financial budget for performance. Examples: max 170 KB JS (gzipped), LCP ≤ 2.5s, Lighthouse Performance ≥ 90.

Without budgets, performance degrades gradually as features are added — the "boiling frog" problem.

Enforcement happens at multiple levels:

IDE level — "Import Cost" extension shows bundle size impact while coding
Build level — Webpack/Vite config fails the build on oversized bundles
CI/CD level — bundlesize or size-limit checks bundle sizes on every PR; Lighthouse CI asserts metric thresholds
Production level — RUM dashboards alert when p75 metrics cross budgets

The key is automated enforcement — budgets without CI/CD checks are just suggestions that get ignored.

Q8: How would you investigate a report that "the app is slow"?

A: I'd follow the investigation funnel:

Quantify "slow" — which metric is poor? Check RUM dashboards for LCP/INP/CLS p75. Is it a loading problem, interaction problem, or visual stability problem?
Segment the data — is it slow for all users or specific segments? Filter by device type, connection speed, geographic region, browser, OS. Often "slow" affects budget phones on 3G, not developer MacBooks.
Reproduce locally — try to reproduce with DevTools throttling (CPU 4x slowdown + Fast 3G). Record a Performance trace.
Analyze the trace — look for Long Tasks (red flags), heavy Layout/Style recalculations (purple), large network requests. Use Bottom-Up view to find expensive functions.
Check third-parties — are third-party scripts (analytics, ads, chat widgets) contributing to main thread blocking?
Prioritize fixes — use the impact × effort matrix. Quick wins first (preload LCP, add image dimensions, defer scripts), then bigger architectural changes (code splitting, SSR, Web Workers).
Validate the fix — deploy, monitor RUM for p75 improvement, confirm with users.

Q9: What are the three pillars of observability and how do they apply to frontend?

Metrics — numeric measurements over time. Frontend: Core Web Vitals (LCP, INP, CLS), error rates, API latency, JS heap size. Used for dashboards and alerting.
Logs — discrete events with context. Frontend: error stack traces with breadcrumbs, user action logs, API request/response details. Used for debugging specific issues.
Traces — end-to-end request flows across services. Frontend: tracing from user click → API call → backend processing → database → response → UI update, with timing at each step. Used for diagnosing latency in distributed systems.

Metrics tell you something is wrong. Logs tell you what went wrong. Traces tell you where in the chain it broke.

In practice: web-vitals + analytics for metrics, Sentry for logs + errors, Sentry Tracing or OpenTelemetry for traces.

Q10: How do you prevent cache from growing unbounded in a Service Worker?

A: Three approaches:

Entry limit — keep max N items per cache (e.g., 100 images). Evict oldest on overflow (FIFO/LRU).
TTL (Time-to-Live) — add a timestamp when caching. On read, check age and delete expired entries.
Version cleanup — on Service Worker activate, delete all caches not in the current version's allow-list.

Q11: What's the difference between lab data and field data?

A: Lab data (Lighthouse, WebPageTest) runs on a simulated device with fixed conditions. It's reproducible and great for debugging, but doesn't represent real user diversity. Field data (CrUX, RUM) is collected from actual users in production — real devices, networks, and locations. It's noisy but represents the truth.

Critical distinction: Google uses field data (CrUX) for SEO ranking, not lab data. You can score 100 on Lighthouse but still fail Google's assessment if real users on slow phones have poor metrics.

Q12: How would you set up error tracking for a production React app?

A: The core components:

Global error handlers — window.onerror for uncaught exceptions, unhandledrejection listener for promise rejections, capture-phase error listener for resource failures
React Error Boundaries — wrap critical routes/features with Error Boundaries to catch render errors and show fallback UI
Error tracking service (e.g., Sentry) — captures errors with full context: stack trace, breadcrumbs (user actions leading to error), user info, browser/OS, release version
Source maps — upload on every deploy so stack traces show original source, not minified code
Alert tiers — P0 (critical flows broken → PagerDuty), P1 (new error in important flow → Slack), P2-P3 (lower severity → digest)
Noise filtering — ignore known harmless errors (ResizeObserver loop limit exceeded, browser extension errors)
Session replay on errors — automatically record sessions where errors occur for easy reproduction

Q13: What tools would you use for a complete frontend performance monitoring strategy?

Stage	Tool	Purpose
Development	Chrome DevTools (Performance, Network, Lighthouse panels)	Profile and debug locally
IDE	Import Cost extension	See bundle size impact of imports
Build	Bundle analyzer (webpack-bundle-analyzer)	Visualize what's in the bundle
CI/CD	Lighthouse CI + `size-limit`/`bundlesize`	Automated regression prevention
Production — RUM	`web-vitals` library + analytics backend	Real user Core Web Vitals
Production — Errors	Sentry (with session replay)	Error tracking, alerting, debugging
Production — Field data	CrUX / PageSpeed Insights	Google's official field data
Ongoing	Scheduled synthetic tests (WebPageTest, DebugBear)	Baseline monitoring, competitor benchmarking

Q14: A page has good lab scores but poor field metrics. Why?

A: This is a very common scenario. Possible reasons:

User diversity — lab tests on fast machines; real users on budget phones with slow CPUs and 3G connections
Third-party scripts — lab might not fully load all third-party scripts (analytics, ads, chat widgets) that compete for main thread time in production
Geographic distance — lab test from a server close to CDN; real users far from CDN edge nodes experience high TTFB
Caching state — lab tests with warm cache; many real users are first-time visitors with cold cache
Dynamic content — lab tests might get different content (fewer ads, no personalization, no A/B test variants)
Long-tail interactions — lab tests the initial load; real users interact for minutes, hitting slow INP interactions later
Browser/OS diversity — lab uses latest Chrome; real users include older Safari, Firefox, webviews with different JS engines

Fix: Segment RUM data by device type, connection speed, and geography to find which user cohorts have poor experience, then optimize for those conditions.

For related topics, see companion articles: **Critical-Rendering-Path.md, **css-js-ui-optimization.md, **network-optimization.md, **image-optimization.md, and **Web_Worker_SharedWorker_and_Service_Worker.md.

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Logging, Analytics & Feature Flags

ZeeshanAli-0704 — Sun, 15 Mar 2026 17:22:11 +0000

Logging, Analytics & Feature Flags — A Complete Frontend Guide

"If you can't observe it, you can't improve it. Logging, analytics, and feature flags form the operational backbone of every production frontend — they tell you what users do, when things break, and how to ship safely."

This guide covers analytics architecture (event tracking, funnel tracking), A/B testing infrastructure, feature flag systems (LaunchDarkly, Unleash), session replay & heatmaps, frontend error tracking & debugging, and where / how to store and ship logs at scale.

Analytics Architecture
A B Testing Infrastructure
Feature Flag Systems
Session Replay and Heatmaps
Frontend Error Tracking and Debugging
Frontend Logging Where to Hold Logs and How
Putting It All Together Unified Observability
Decision Matrix and Quick Reference
Key Interview Takeaways
Further Reading and Resources

⬆ Back to Top

Analytics Architecture

1.1 Why Frontend Analytics Matter

Analytics answer three critical questions in system design:

Question	What It Drives
What are users doing?	Product decisions, UX improvements
Where are users dropping off?	Funnel optimization, revenue impact
Is the new feature working?	A/B test evaluation, rollout decisions

Without analytics, every product decision is a guess. In a frontend system design interview, analytics is the feedback loop that validates your design choices.

1.2 Event Tracking — Design & Implementation

Event Taxonomy

A well-designed event taxonomy is the foundation of good analytics. Every event should answer: Who did what, where, and when?

┌──────────────────────────────────────────────────────┐
│                Event Schema                           │
│                                                       │
│  {                                                    │
│    "event":      "product_added_to_cart",             │
│    "timestamp":  "2026-03-13T10:30:00.000Z",          │
│    "userId":     "u_abc123",                          │
│    "sessionId":  "s_xyz789",                          │
│    "properties": {                                    │
│      "productId":    "SKU-1234",                      │
│      "productName":  "Wireless Headphones",           │
│      "price":        79.99,                           │
│      "currency":     "USD",                           │
│      "category":     "Electronics",                   │
│      "quantity":     1                                │
│    },                                                 │
│    "context": {                                       │
│      "page":         "/product/SKU-1234",             │
│      "referrer":     "/search?q=headphones",          │
│      "device":       "mobile",                        │
│      "browser":      "Chrome 120",                    │
│      "os":           "Android 14",                    │
│      "viewport":     "390x844",                       │
│      "network":      "4g",                            │
│      "locale":       "en-US"                          │
│    }                                                  │
│  }                                                    │
└──────────────────────────────────────────────────────┘

Naming Convention

Use a consistent object_action pattern:

✅ Good (consistent, greppable):
  page_viewed
  product_added_to_cart
  checkout_started
  payment_completed
  search_performed
  filter_applied

❌ Bad (inconsistent, hard to query):
  viewPage
  AddToCart
  user clicked checkout
  pay_done

Analytics Service Implementation

// src/analytics/analyticsService.ts

interface EventProperties {
  [key: string]: string | number | boolean | null;
}

interface EventContext {
  page: string;
  referrer: string;
  device: 'mobile' | 'tablet' | 'desktop';
  sessionId: string;
  userId?: string;
}

interface AnalyticsEvent {
  event: string;
  timestamp: string;
  properties: EventProperties;
  context: EventContext;
}

class AnalyticsService {
  private queue: AnalyticsEvent[] = [];
  private flushInterval: number;
  private maxQueueSize: number;
  private endpoint: string;

  constructor(config: {
    endpoint: string;
    flushIntervalMs?: number;
    maxQueueSize?: number;
  }) {
    this.endpoint = config.endpoint;
    this.flushInterval = config.flushIntervalMs ?? 5000;  // Flush every 5s
    this.maxQueueSize = config.maxQueueSize ?? 20;

    // Periodic flush
    setInterval(() => this.flush(), this.flushInterval);

    // Flush on page unload
    window.addEventListener('visibilitychange', () => {
      if (document.visibilityState === 'hidden') {
        this.flush();
      }
    });
  }

  track(event: string, properties: EventProperties = {}): void {
    const analyticsEvent: AnalyticsEvent = {
      event,
      timestamp: new Date().toISOString(),
      properties,
      context: this.getContext(),
    };

    this.queue.push(analyticsEvent);

    // Auto-flush if queue is full
    if (this.queue.length >= this.maxQueueSize) {
      this.flush();
    }
  }

  private async flush(): Promise<void> {
    if (this.queue.length === 0) return;

    const batch = [...this.queue];
    this.queue = [];

    try {
      // Use sendBeacon for reliability (survives page unload)
      const blob = new Blob([JSON.stringify(batch)], { type: 'application/json' });
      const sent = navigator.sendBeacon(this.endpoint, blob);

      if (!sent) {
        // Fallback to fetch with keepalive
        await fetch(this.endpoint, {
          method: 'POST',
          body: JSON.stringify(batch),
          headers: { 'Content-Type': 'application/json' },
          keepalive: true,
        });
      }
    } catch (error) {
      // Put events back in queue (with limit to prevent memory leak)
      this.queue = [...batch.slice(-this.maxQueueSize), ...this.queue];
      console.warn('Analytics flush failed, events re-queued', error);
    }
  }

  private getContext(): EventContext {
    return {
      page: window.location.pathname,
      referrer: document.referrer,
      device: this.getDeviceType(),
      sessionId: this.getSessionId(),
      userId: this.getUserId(),
    };
  }

  private getDeviceType(): 'mobile' | 'tablet' | 'desktop' {
    const w = window.innerWidth;
    if (w < 768) return 'mobile';
    if (w < 1024) return 'tablet';
    return 'desktop';
  }

  private getSessionId(): string {
    let sid = sessionStorage.getItem('analytics_sid');
    if (!sid) {
      sid = crypto.randomUUID();
      sessionStorage.setItem('analytics_sid', sid);
    }
    return sid;
  }

  private getUserId(): string | undefined {
    // Pull from your auth layer
    return (window as any).__AUTH_USER__?.id;
  }
}

// Singleton
export const analytics = new AnalyticsService({
  endpoint: '/api/analytics/events',
  flushIntervalMs: 5000,
  maxQueueSize: 20,
});

React Integration — Custom Hook

// src/analytics/useTrack.ts
import { useEffect, useCallback } from 'react';
import { analytics } from './analyticsService';

// Automatic page-view tracking
export function usePageView(pageName: string) {
  useEffect(() => {
    analytics.track('page_viewed', { page_name: pageName });
  }, [pageName]);
}

// Manual event tracking
export function useTrack() {
  return useCallback(
    (event: string, properties?: Record<string, any>) => {
      analytics.track(event, properties ?? {});
    },
    []
  );
}

// Usage in a component
function ProductPage({ product }) {
  usePageView('product_detail');
  const track = useTrack();

  const handleAddToCart = () => {
    track('product_added_to_cart', {
      productId: product.id,
      price: product.price,
    });
    addToCart(product);
  };

  return <button onClick={handleAddToCart}>Add to Cart</button>;
}

Declarative Tracking with Data Attributes

For large apps, declarative tracking reduces boilerplate:

// Attach tracking metadata to any element
<button
  data-track="product_added_to_cart"
  data-track-product-id={product.id}
  data-track-price={product.price}
  onClick={addToCart}
>
  Add to Cart
</button>

// Global click listener (set up once)
document.addEventListener('click', (e) => {
  const target = (e.target as HTMLElement).closest('[data-track]');
  if (!target) return;

  const event = target.getAttribute('data-track')!;
  const properties: Record<string, string> = {};

  // Collect all data-track-* attributes
  for (const attr of target.attributes) {
    if (attr.name.startsWith('data-track-') && attr.name !== 'data-track') {
      const key = attr.name.replace('data-track-', '').replace(/-/g, '_');
      properties[key] = attr.value;
    }
  }

  analytics.track(event, properties);
});

1.3 Funnel Tracking

A funnel tracks a sequence of user steps toward a goal (e.g., purchase). Drop-off at any step represents lost revenue or engagement.

E-Commerce Funnel Example

Step 1: page_viewed        (page: /products)         100% ████████████████████
Step 2: product_viewed     (productId: SKU-123)       60% ████████████
Step 3: product_added_to_cart                          25% █████
Step 4: checkout_started                               15% ███
Step 5: payment_info_entered                           12% ██▌
Step 6: order_completed                                 8% █▋

Drop-off analysis:
  Step 1→2: 40% lose interest (improve recommendations)
  Step 2→3: 58% don't add to cart (improve product page, pricing)
  Step 3→4: 40% abandon cart (add urgency, simplify UX)
  Step 4→5: 20% hesitate at payment (add trust signals, payment options)
  Step 5→6: 33% fail to complete (optimize payment flow, error handling)

Funnel Tracking Implementation

// src/analytics/funnel.ts

interface FunnelStep {
  name: string;
  event: string;
  timestamp?: number;
}

class FunnelTracker {
  private funnels: Map<string, FunnelStep[]> = new Map();

  /**
   * Define a funnel with named steps
   */
  defineFunnel(funnelName: string, steps: string[]) {
    this.funnels.set(
      funnelName,
      steps.map((event) => ({ name: event, event }))
    );
  }

  /**
   * Record a funnel step completion
   */
  recordStep(funnelName: string, eventName: string, properties: Record<string, any> = {}) {
    const funnel = this.funnels.get(funnelName);
    if (!funnel) return;

    const stepIndex = funnel.findIndex((s) => s.event === eventName);
    if (stepIndex === -1) return;

    analytics.track('funnel_step_completed', {
      funnel_name: funnelName,
      step_name: eventName,
      step_index: stepIndex,
      total_steps: funnel.length,
      ...properties,
    });
  }
}

// Usage
const funnelTracker = new FunnelTracker();

funnelTracker.defineFunnel('checkout', [
  'cart_viewed',
  'checkout_started',
  'shipping_entered',
  'payment_entered',
  'order_completed',
]);

// In your component:
funnelTracker.recordStep('checkout', 'checkout_started', { cartTotal: 149.99 });

1.4 Analytics Pipeline Architecture

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   Browser     │    │   Ingestion   │    │   Stream      │    │   Storage     │
│               │    │   Layer       │    │   Processing  │    │   & Query     │
│ analytics.js  │───>│              │───>│              │───>│              │
│               │    │  API Gateway  │    │  Kafka /     │    │  ClickHouse  │
│ sendBeacon()  │    │  or Collector │    │  Kinesis     │    │  BigQuery    │
│ fetch()       │    │  Endpoint     │    │              │    │  Snowflake   │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
                                              │
                                              ▼
                                     ┌──────────────┐    ┌──────────────┐
                                     │  Real-time    │    │  Dashboard    │
                                     │  Aggregation  │───>│  & Alerts     │
                                     │  (Flink/      │    │  (Grafana,    │
                                     │   Spark)      │    │   Amplitude)  │
                                     └──────────────┘    └──────────────┘

Key design decisions:

Decision	Recommendation	Why
Transport	`navigator.sendBeacon` + `fetch` fallback	Survives page unload
Batching	Batch events, flush every 5s or 20 events	Reduces network requests
Schema	Strict typed schema with validation	Prevents garbage data
Sampling	100% for critical events, 10–50% for high-volume	Cost management
Buffering	Queue in memory; IndexedDB for offline	No data loss
Backend	Kafka/Kinesis → ClickHouse/BigQuery	Handles billions of events

1.5 Popular Analytics Platforms Compared

Platform	Type	Strengths	Weaknesses	Cost Model
Google Analytics 4	Full-stack	Free, deep Google integration	Complex setup, data sampling	Free / GA360 paid
Amplitude	Product analytics	Best funnel & cohort analysis	Expensive at scale	Event volume
Mixpanel	Product analytics	Great UX, real-time	Limited raw data access	Event volume
Segment	Customer Data Platform	Unified tracking, 300+ integrations	Expensive, adds latency	Monthly tracked users
PostHog	All-in-one (open-source)	Self-hostable, feature flags + analytics	Younger ecosystem	Events or self-host
Plausible	Privacy-first	No cookies, GDPR-compliant, simple	Limited features	Pageviews
Custom (ClickHouse)	Build-your-own	Full control, no vendor lock-in	Engineering cost	Infrastructure

⬆ Back to Top

A B Testing Infrastructure

2.1 How A/B Tests Work on the Frontend

User visits page
      │
      ▼
┌─────────────────────┐
│ Experiment SDK       │
│ evaluates user into  │
│ variant              │
│                      │
│ hash(userId +        │
│   experimentId)      │
│   % bucketCount      │──── Deterministic: same user always
│                      │     gets same variant
│ → Variant A (50%)    │
│ → Variant B (50%)    │
└──────┬──────────────┘
       │
       ▼
┌──────────────────┐        ┌──────────────────┐
│ Variant A        │        │ Variant B        │
│ (Control)        │        │ (Treatment)      │
│                  │        │                  │
│ Blue "Buy" btn   │        │ Green "Buy" btn  │
│                  │        │                  │
│ Track: exposure  │        │ Track: exposure  │
│ Track: clicks    │        │ Track: clicks    │
│ Track: purchase  │        │ Track: purchase  │
└──────────────────┘        └──────────────────┘
       │                           │
       └─────────┬─────────────────┘
                 ▼
      ┌──────────────────┐
      │ Analytics         │
      │                   │
      │ Compare metrics   │
      │ per variant with  │
      │ statistical       │
      │ significance      │
      └──────────────────┘

2.2 Client-Side vs Server-Side A/B Testing

Aspect	Client-Side	Server-Side
Where it runs	Browser (JS SDK)	Server / Edge / CDN
Flicker risk	Yes — content shifts after JS loads	No — correct variant served
Performance	Extra JS + SDK overhead	Zero client-side cost
Personalization	Limited (must wait for JS)	Full (server has all user data)
Ease of setup	Easy (drop-in SDK)	Requires backend integration
SEO impact	Can cause CLS issues	None
Examples	Google Optimize, Optimizely (client)	LaunchDarkly, Unleash, Statsig

Modern Trend: Server-side / Edge-side evaluation with a lightweight client SDK that receives the decision — no flicker, no performance cost.

2.3 Implementation Patterns

Pattern 1: Feature-Flag-Driven A/B Tests

The cleanest approach — A/B tests are just feature flags with analytics:

// Uses the same feature flag system (Section 3)
import { useFeatureFlag } from '@org/feature-flags';
import { analytics } from '@org/analytics';
import { useEffect } from 'react';

function CheckoutButton() {
  const variant = useFeatureFlag('checkout_button_experiment');
  // Returns: 'control' | 'green_button' | 'urgency_copy'

  // Track exposure (user saw the experiment)
  useEffect(() => {
    analytics.track('experiment_exposure', {
      experiment: 'checkout_button_experiment',
      variant,
    });
  }, [variant]);

  // Track conversion
  const handleClick = () => {
    analytics.track('experiment_conversion', {
      experiment: 'checkout_button_experiment',
      variant,
      action: 'checkout_clicked',
    });
    proceedToCheckout();
  };

  switch (variant) {
    case 'green_button':
      return <button className="btn-green" onClick={handleClick}>Buy Now</button>;
    case 'urgency_copy':
      return <button className="btn-blue" onClick={handleClick}>Buy Now — Only 3 Left!</button>;
    default:
      return <button className="btn-blue" onClick={handleClick}>Buy Now</button>;
  }
}

Pattern 2: Component-Level Experiments

// src/experiments/Experiment.tsx
interface ExperimentProps {
  name: string;
  children: Record<string, React.ReactNode>;  // variant → component
}

function Experiment({ name, children }: ExperimentProps) {
  const variant = useFeatureFlag(name);

  useEffect(() => {
    analytics.track('experiment_exposure', { experiment: name, variant });
  }, [name, variant]);

  return <>{children[variant] ?? children['control']}</>;
}

// Usage
<Experiment name="hero_redesign">
  {{
    control: <HeroV1 />,
    variant_a: <HeroV2WithVideo />,
    variant_b: <HeroV3Minimal />,
  }}
</Experiment>

2.4 Avoiding Flicker (FOOC)

Flash of Original Content (FOOC): User briefly sees the control variant before the experiment SDK assigns them to the treatment.

Timeline WITHOUT anti-flicker:
  0ms: HTML loads → shows control
  200ms: Experiment SDK loads
  300ms: SDK assigns variant B
  301ms: Page re-renders with variant B  ← USER SEES FLICKER ⚠️

Timeline WITH anti-flicker:
  0ms: HTML loads → body is hidden (opacity: 0)
  200ms: Experiment SDK loads
  300ms: SDK assigns variant, reveals body
  301ms: User sees correct variant from the start  ✅

Anti-flicker snippet (in <head>):

<script>
  // Hide body until experiment SDK resolves (max 2 seconds)
  document.documentElement.style.opacity = '0';
  setTimeout(() => {
    document.documentElement.style.opacity = '1';
  }, 2000); // Safety timeout — never block rendering forever
</script>

⚠️ Better approach: Use server-side or edge-side evaluation so the correct variant is served from the start — zero flicker, zero CLS impact.

2.5 Statistical Considerations

Concept	What It Means	Implication
Sample size	Enough users to detect a meaningful difference	Don't call experiments early
Statistical significance	p-value < 0.05 (95% confidence)	Avoid false positives
Minimum Detectable Effect (MDE)	Smallest improvement worth detecting	Drives sample size calculation
Duration	Run for at least 1–2 full business cycles (weeks)	Captures weekday/weekend variance
Multiple comparisons	Testing 5 variants inflates false positive rate	Use Bonferroni correction
Novelty effect	Users interact more with "new" things	Wait for effect to stabilize

⬆ Back to Top

Feature Flag Systems

3.1 What Are Feature Flags?

Feature flags (also called feature toggles) are runtime switches that control which features are visible/enabled without deploying new code.

Traditional deploy:
  Code change → Build → Deploy → Feature is live for ALL users

With feature flags:
  Code change → Build → Deploy → Feature is OFF by default
                                       │
                                       ▼
                              Enable for 5% of users (canary)
                              Enable for internal team (dogfood)
                              Enable for beta users
                              Enable for 100% (full rollout)
                              Instantly disable if buggy (kill switch)

3.2 Types of Feature Flags

Type	Lifetime	Purpose	Example
Release flag	Days–Weeks	Gate unfinished features	`new_checkout_flow`
Experiment flag	Weeks	A/B tests	`hero_redesign_experiment`
Ops flag	Permanent	Kill switches, load shedding	`disable_recommendations`
Permission flag	Permanent	Entitlement/plan gating	`premium_feature_export`

3.3 Feature Flag Architecture

┌───────────────────────────────────────────────────────────────────┐
│                    Feature Flag System                             │
│                                                                    │
│  ┌──────────────┐    ┌──────────────────┐    ┌─────────────────┐  │
│  │  Admin UI /   │    │  Flag Evaluation  │    │  Client SDKs    │  │
│  │  Dashboard    │───>│  Service (API)    │───>│  (JS, React,    │  │
│  │              │    │                   │    │   Node, etc.)   │  │
│  │ Create flags  │    │ Rules engine:     │    │                 │  │
│  │ Set targeting │    │ - User segments  │    │ Evaluates flags  │  │
│  │ Define rules  │    │ - % rollout      │    │ locally or via   │  │
│  │ Kill switch   │    │ - Env (prod/stg) │    │ SSE stream       │  │
│  └──────────────┘    │ - Custom attrs   │    └─────────────────┘  │
│                       └──────────────────┘                         │
│                              │                                     │
│                              ▼                                     │
│                    ┌──────────────────┐                            │
│                    │  Flag Store       │                            │
│                    │  (Redis / DB)     │                            │
│                    │                   │                            │
│                    │  Caches evaluated │                            │
│                    │  flag values for  │                            │
│                    │  fast reads       │                            │
│                    └──────────────────┘                            │
└───────────────────────────────────────────────────────────────────┘

Evaluation Flow:

1. App starts → SDK fetches all flag definitions (bootstrap)
2. SDK caches flags in memory
3. SDK opens SSE / WebSocket connection for real-time updates
4. Component calls useFeatureFlag('new_checkout')
5. SDK evaluates locally:
   - Is user in target segment? (e.g., country === 'US')
   - Does user fall within rollout percentage?
   - Is the flag enabled for this environment?
6. Returns boolean / string variant
7. On flag change → SSE pushes update → SDK re-evaluates → component re-renders

3.4 LaunchDarkly — Deep Dive

LaunchDarkly is the market-leading feature flag platform. Here's how it works:

Architecture

┌───────────────┐     ┌──────────────────────┐     ┌────────────────┐
│  LaunchDarkly  │     │  Streaming edge       │     │  Your App       │
│  Dashboard     │────>│  (LD Relay / CDN)     │────>│  (LD SDK)       │
│                │     │                       │     │                 │
│  Flag config   │     │  SSE stream delivers  │     │  Local eval,    │
│  is pushed to  │     │  flag changes in      │     │  no latency     │
│  edge in ~200ms│     │  real-time             │     │  per flag check │
└───────────────┘     └──────────────────────┘     └────────────────┘

React SDK Integration

// src/index.tsx
import { LDProvider } from 'launchdarkly-react-client-sdk';

const ldConfig = {
  clientSideID: 'YOUR_CLIENT_SIDE_ID',
  context: {
    kind: 'user',
    key: 'user-123',
    name: 'Jane Doe',
    email: 'jane@example.com',
    custom: {
      plan: 'premium',
      company: 'Acme Inc',
      country: 'US',
    },
  },
};

function Root() {
  return (
    <LDProvider {...ldConfig}>
      <App />
    </LDProvider>
  );
}

// src/components/Feature.tsx
import { useFlags, useLDClient } from 'launchdarkly-react-client-sdk';

function DashboardPage() {
  const { newDashboardLayout, enableExport, darkModeExperiment } = useFlags();
  const ldClient = useLDClient();

  // Track custom event for experiments
  const handleExport = () => {
    ldClient?.track('export_clicked', { format: 'csv' });
    exportData();
  };

  return (
    <div className={darkModeExperiment === 'dark' ? 'dark-theme' : 'light-theme'}>
      {newDashboardLayout ? <DashboardV2 /> : <DashboardV1 />}
      {enableExport && <button onClick={handleExport}>Export</button>}
    </div>
  );
}

Targeting Rules Examples

Flag: new_checkout_flow
  Default: false

  Rules (evaluated top-to-bottom):
    1. IF user.email ENDS WITH "@mycompany.com"  →  true   (internal dogfood)
    2. IF user.plan == "beta"                     →  true   (beta testers)
    3. IF user.country IN ["US", "CA"]            →  true (25% rollout)
    4. ELSE                                       →  false  (everyone else)

3.5 Unleash — Open-Source Alternative

Unleash is the leading open-source feature flag system. Self-hostable, API-compatible, and great for teams that want full control.

Setup

# Docker Compose for self-hosting
docker compose up -d  # Runs Unleash server + PostgreSQL

# Or use hosted: Unleash Cloud

React Integration

// src/index.tsx
import { FlagProvider } from '@unleash/proxy-client-react';

const config = {
  url: 'https://your-unleash-proxy.com/api/frontend',
  clientKey: 'your-proxy-client-key',
  refreshInterval: 15,  // seconds
  appName: 'my-web-app',
  context: {
    userId: 'user-123',
    properties: { plan: 'premium', country: 'US' },
  },
};

function Root() {
  return (
    <FlagProvider config={config}>
      <App />
    </FlagProvider>
  );
}

// src/components/Feature.tsx
import { useFlag, useVariant } from '@unleash/proxy-client-react';

function ProductPage() {
  const isNewLayout = useFlag('new_product_layout');
  const priceVariant = useVariant('price_experiment');

  return (
    <div>
      {isNewLayout ? <ProductLayoutV2 /> : <ProductLayoutV1 />}
      {priceVariant.name === 'show_discount' && <DiscountBadge />}
    </div>
  );
}

3.6 LaunchDarkly vs Unleash vs Custom

Aspect	LaunchDarkly	Unleash	Custom (DIY)
Hosting	SaaS only	Self-host or Cloud	Self-host
Cost	$$$$ (per seat + MAU)	Free (OSS) / $$ (Cloud)	Engineering time
Real-time updates	SSE (< 200ms)	Polling (15s default)	Build it
Targeting rules	Rich UI, segments, % rollout	Good, extensible	Build it
A/B experiments	Built-in (Experimentation add-on)	Via Unleash Analytics	Build it
SDKs	25+ (best-in-class)	15+ (good quality)	Build it
Audit log	Full	Full	Build it
TypeScript types	Auto-generated	Manual	Manual
Best for	Enterprise, large teams	Mid-size, privacy-conscious	Simple needs

3.7 Best Practices & Flag Hygiene

┌──────────────────────────────────────────────────────────┐
│                  Feature Flag Lifecycle                    │
│                                                           │
│  CREATE   →   DEVELOP   →   ROLLOUT   →   CLEANUP        │
│  Name it      Gate code     Canary (5%)   Remove flag     │
│  Document     Write tests   Expand (25%)  Remove dead     │
│  Set owner    Ship behind   Full (100%)   code paths      │
│               flag          Monitor       Archive in DB   │
└──────────────────────────────────────────────────────────┘

Rules:

Rule	Why
Every flag has an owner	Someone is responsible for cleanup
Set expiry dates	Flags lingering for months become tech debt
Limit active flags	> 50 active flags = cognitive overload
Test both paths	Flag on AND flag off must work
No nested flags	`if (flagA && flagB && !flagC)` → unmaintainable
Monitor flag usage	Alert on stale flags (not evaluated in 30 days)
Use naming conventions	`release_`, `experiment_`, `ops_`, `perm_`

// Bad: flag cleanup debt
if (useFeatureFlag('new_checkout_v2')) {
  if (useFeatureFlag('checkout_experiment_q3')) {
    if (!useFeatureFlag('disable_stripe_v4')) {
      return <CheckoutV2WithStripeV5 />;
    }
  }
}

// Good: single flag, clean code
const checkoutVersion = useFeatureFlag('checkout_version'); // 'v1' | 'v2' | 'v3'
return <Checkout version={checkoutVersion} />;

⬆ Back to Top

Session Replay and Heatmaps

4.1 How Session Replay Works

Session replay tools record DOM mutations, mouse movements, scroll events, and network requests to recreate a user's session as a video — without actually recording a video.

Browser (User's session)
  │
  ├── MutationObserver → captures DOM changes
  ├── mousemove / click / scroll → captures interactions
  ├── Performance Observer → captures resource timing
  ├── Console proxy → captures console.log / console.error
  ├── Network proxy → captures XHR / fetch requests & responses
  │
  ▼
┌──────────────────────────┐
│  Serialized Event Stream  │
│                           │
│  [                        │
│    { type: 'snapshot',    │   // Initial full DOM snapshot
│      data: <DOM tree> },  │
│    { type: 'mutation',    │   // Incremental DOM change
│      data: <diff> },      │
│    { type: 'mouse',       │   // Mouse position
│      data: {x, y} },      │
│    { type: 'input',       │   // User typed (masked)
│      data: '****' },      │
│    ...                    │
│  ]                        │
└──────────┬───────────────┘
           │
           ▼  Compressed & batched
┌──────────────────────┐
│  Replay Backend       │
│  (stores as events,   │
│   replays by          │
│   re-applying events  │
│   to a virtual DOM)   │
└──────────────────────┘

Key Library: rrweb — the open-source engine behind most session replay tools.

// Using rrweb directly
import { record } from 'rrweb';

const events: any[] = [];

const stopRecording = record({
  emit(event) {
    events.push(event);

    // Batch and send every 50 events
    if (events.length >= 50) {
      sendToBackend(events.splice(0));
    }
  },
  maskAllInputs: true,            // Mask password, email, etc.
  blockSelector: '.pii-block',    // Don't capture these elements
  maskTextSelector: '.pii-mask',  // Replace text with ***
});

4.2 Heatmaps — Click, Scroll, Move

Type	What It Shows	Use Case
Click heatmap	Where users click (hot = frequent)	Find dead clicks, misclicked areas
Scroll heatmap	How far users scroll (% visible)	Determine fold line, content priority
Move heatmap	Where mouse hovers (≈ attention)	Eye-tracking proxy
Rage click map	Repeated rapid clicks on same element	Find broken UI, frustration

Click Heatmap Visualization:

  ┌────────────────────────────────┐
  │  HEADER / NAV BAR              │  🔴🔴🔴 (nav links heavily clicked)
  ├────────────────────────────────┤
  │                                │
  │  Hero Banner                   │  🟡 (moderate clicks)
  │  [CTA Button]                  │  🔴🔴🔴🔴 (highest clicks)
  │                                │
  ├────────────────────────────────┤
  │                                │
  │  Product Grid                  │  🟡🟡 (moderate)
  │  Card 1  Card 2  Card 3       │
  │                                │
  ├────────────────────────────────┤
  │                                │
  │  Footer                        │  🔵 (few clicks — most users
  │                                │       don't scroll this far)
  └────────────────────────────────┘

  Scroll depth:  ███████████████  100% (top)
                 ████████████     80%
                 █████████        60%
                 ██████           40%
                 ███              20%  (only 20% reach footer)

4.3 Privacy & PII Concerns

Risk	Mitigation
Passwords / CC numbers	`maskAllInputs: true` — replaces with `***`
Sensitive text	Apply `.pii-mask` CSS class or selector-based masking
PII in URLs	Strip query params before recording
GDPR / CCPA	Get user consent before recording; honor Do Not Track
Data retention	Auto-delete replays after 30–90 days
Employee data	Exclude internal users from recording

4.4 Tools Compared

Tool	Session Replay	Heatmaps	Analytics	Error Tracking	Pricing
Hotjar	✅	✅ Click, Scroll, Move	Basic	❌	Free tier / $$
FullStory	✅ (best)	✅	✅	✅	$$$$
LogRocket	✅	❌	✅	✅ (Redux, network)	$$$
PostHog	✅	✅	✅	❌	Free (self-host) / $$
Microsoft Clarity	✅	✅ Click, Scroll	Basic	❌	Free
Mouseflow	✅	✅ Full suite	✅ Funnels	❌	$$
Heap	✅	❌	✅ (auto-capture)	❌	$$$

💡 Microsoft Clarity is a great free option for session replay + heatmaps. It uses rrweb under the hood and integrates with Google Analytics.

⬆ Back to Top

Frontend Error Tracking and Debugging

5.1 Types of Frontend Errors

┌──────────────────────────────────────────────────────────────┐
│                  Frontend Error Taxonomy                      │
│                                                               │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐ │
│  │ JavaScript       │  │ Network          │  │ Resource     │ │
│  │ Runtime Errors   │  │ Errors           │  │ Errors       │ │
│  │                  │  │                  │  │              │ │
│  │ TypeError        │  │ API 4xx/5xx      │  │ Image 404    │ │
│  │ ReferenceError   │  │ Timeout          │  │ Script fail  │ │
│  │ RangeError       │  │ Network offline  │  │ CSS fail     │ │
│  │ SyntaxError      │  │ CORS blocked     │  │ Font fail    │ │
│  │ Unhandled        │  │ SSL errors       │  │ Chunk load   │ │
│  │ Promise reject   │  │                  │  │ error        │ │
│  └─────────────────┘  └─────────────────┘  └──────────────┘ │
│                                                               │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐ │
│  │ Framework        │  │ Performance      │  │ User         │ │
│  │ Errors           │  │ Errors           │  │ Errors       │ │
│  │                  │  │                  │  │              │ │
│  │ React render     │  │ Memory leak      │  │ Rage clicks  │ │
│  │ error            │  │ Long task (>50ms)│  │ Dead clicks  │ │
│  │ Hydration        │  │ Layout thrashing │  │ Form errors  │ │
│  │ mismatch         │  │ Jank (dropped    │  │ Navigation   │ │
│  │ State mismatch   │  │ frames)          │  │ frustration │ │
│  └─────────────────┘  └─────────────────┘  └──────────────┘ │
└──────────────────────────────────────────────────────────────┘

5.2 Capturing Errors — The Complete Picture

Global Error Handlers

// src/errorTracking/globalHandlers.ts

// 1. Uncaught JS errors
window.addEventListener('error', (event) => {
  // event.error    → Error object
  // event.message  → Error message
  // event.filename → Script URL
  // event.lineno   → Line number
  // event.colno    → Column number

  reportError({
    type: 'uncaught_error',
    message: event.message,
    stack: event.error?.stack,
    source: event.filename,
    line: event.lineno,
    column: event.colno,
  });
});

// 2. Unhandled Promise rejections
window.addEventListener('unhandledrejection', (event) => {
  reportError({
    type: 'unhandled_promise_rejection',
    message: event.reason?.message || String(event.reason),
    stack: event.reason?.stack,
  });
});

// 3. Resource loading errors (images, scripts, stylesheets)
window.addEventListener('error', (event) => {
  const target = event.target as HTMLElement;
  if (target.tagName) {
    reportError({
      type: 'resource_error',
      tag: target.tagName.toLowerCase(),
      src: (target as HTMLImageElement).src || (target as HTMLScriptElement).src,
    });
  }
}, true);  // ← Must use capture phase for resource errors

// 4. Console error proxy
const originalConsoleError = console.error;
console.error = (...args) => {
  reportError({
    type: 'console_error',
    message: args.map(String).join(' '),
  });
  originalConsoleError.apply(console, args);
};

Network Error Tracking

// Intercept fetch to track API errors
const originalFetch = window.fetch;

window.fetch = async (...args) => {
  const startTime = performance.now();
  const [url, options] = args;

  try {
    const response = await originalFetch(...args);
    const duration = performance.now() - startTime;

    if (!response.ok) {
      reportError({
        type: 'api_error',
        url: typeof url === 'string' ? url : url.toString(),
        method: options?.method || 'GET',
        status: response.status,
        statusText: response.statusText,
        duration,
      });
    }

    // Track slow APIs
    if (duration > 3000) {
      reportError({
        type: 'slow_api',
        url: typeof url === 'string' ? url : url.toString(),
        duration,
      });
    }

    return response;
  } catch (error) {
    reportError({
      type: 'network_error',
      url: typeof url === 'string' ? url : url.toString(),
      message: (error as Error).message,
    });
    throw error;
  }
};

5.3 Error Tracking with Sentry

Sentry is the most popular frontend error tracking platform.

Setup

// src/index.ts
import * as Sentry from '@sentry/react';

Sentry.init({
  dsn: 'https://examplePublicKey@o0.ingest.sentry.io/0',

  // Release & environment
  release: 'my-app@2.3.1',
  environment: process.env.NODE_ENV,

  // Performance monitoring
  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration({
      maskAllText: false,
      blockAllMedia: false,
    }),
  ],

  // Sample rates
  tracesSampleRate: 0.1,        // 10% of transactions for perf monitoring
  replaysSessionSampleRate: 0.1, // 10% of sessions get replay
  replaysOnErrorSampleRate: 1.0, // 100% of error sessions get replay

  // Filter noise
  ignoreErrors: [
    'ResizeObserver loop limit exceeded',
    'Non-Error promise rejection captured',
    /^Loading chunk \d+ failed/,
  ],

  // PII protection
  beforeSend(event) {
    // Strip PII from error events
    if (event.request?.url) {
      event.request.url = stripSensitiveParams(event.request.url);
    }
    return event;
  },

  // Breadcrumbs — trail of events leading to an error
  beforeBreadcrumb(breadcrumb) {
    // Don't track breadcrumbs from analytics scripts
    if (breadcrumb.category === 'xhr' &&
        breadcrumb.data?.url?.includes('analytics')) {
      return null;
    }
    return breadcrumb;
  },
});

React Error Boundary Integration

import * as Sentry from '@sentry/react';

// Sentry-powered Error Boundary
const SentryErrorBoundary = Sentry.withErrorBoundary(App, {
  fallback: ({ error, resetError }) => (
    <div className="error-page">
      <h1>Something went wrong</h1>
      <p>Our team has been notified. Please try again.</p>
      <button onClick={resetError}>Try Again</button>
    </div>
  ),
  showDialog: true,  // Show Sentry feedback dialog
});

// Or wrap specific components
function ProductPage() {
  return (
    <Sentry.ErrorBoundary fallback={<ProductErrorFallback />}>
      <ProductDetail />
    </Sentry.ErrorBoundary>
  );
}

Manual Error Capture with Context

// Capture errors with rich context
try {
  await processPayment(order);
} catch (error) {
  Sentry.withScope((scope) => {
    // Add structured context
    scope.setTag('payment_provider', 'stripe');
    scope.setTag('order_type', 'subscription');
    scope.setLevel('critical');

    scope.setContext('order', {
      orderId: order.id,
      amount: order.total,
      currency: order.currency,
      items: order.items.length,
    });

    scope.setContext('user_journey', {
      steps_completed: ['cart', 'shipping', 'payment'],
      time_in_checkout: '3m 22s',
    });

    // Set user (without PII)
    scope.setUser({
      id: user.id,
      segment: user.plan,  // Not email — PII
    });

    Sentry.captureException(error);
  });
}

Sentry — What Gets Captured Automatically

Data	Source	How
Stack trace	`window.onerror`	Auto (with source maps)
Breadcrumbs	Console, clicks, navigation, XHR	Auto
User interactions	Clicks, inputs, navigation	Auto (breadcrumb trail)
HTTP requests	Fetch/XHR	Auto (BrowserTracing)
Performance spans	Page load, route change	Auto (BrowserTracing)
Session replay	DOM mutations, mouse, scroll	Auto (Replay integration)
Device info	User-Agent, viewport, OS	Auto
Release info	`release` config	Manual (set in CI)

5.4 Source Maps for Production Debugging

Minified production code produces useless stack traces:

// Minified error (useless):
TypeError: Cannot read property 'a' of undefined
  at e.value (main.abc123.js:1:24589)

// With source maps (useful):
TypeError: Cannot read property 'name' of undefined
  at ProductCard.render (src/components/ProductCard.tsx:42:18)

Source Map Strategy

┌──────────────────────────────────────────────────────────┐
│                Source Map Strategies                       │
│                                                           │
│  Option 1: Upload to Sentry (RECOMMENDED)                 │
│  ─────────────────────────────────────────                │
│  • Source maps uploaded during CI/CD build                 │
│  • NOT served to browsers (private)                       │
│  • Sentry un-minifies stack traces server-side            │
│  • No performance or security impact                      │
│                                                           │
│  Option 2: Hidden source maps                             │
│  ─────────────────────────────────────────                │
│  • devtool: 'hidden-source-map' in Webpack                │
│  • .map files generated but no //# sourceMappingURL       │
│  • Deployed to restricted storage (S3 with IAM)           │
│  • Error tracking service fetches them server-side        │
│                                                           │
│  Option 3: Source maps behind auth (NOT RECOMMENDED)      │
│  ─────────────────────────────────────────                │
│  • Anyone with Chrome DevTools can see your source code   │
│                                                           │
│  ❌ Option 4: No source maps in prod                      │
│  • Debugging is impossible                                │
│  • NEVER do this                                          │
└──────────────────────────────────────────────────────────┘

Uploading Source Maps to Sentry (CI/CD)

# .github/workflows/deploy.yml
- name: Build
  run: npm run build
  env:
    GENERATE_SOURCEMAP: true

- name: Upload Source Maps to Sentry
  run: |
    npx @sentry/cli releases new ${{ github.sha }}
    npx @sentry/cli releases files ${{ github.sha }} \
      upload-sourcemaps ./build/static/js \
      --url-prefix '~/static/js'
    npx @sentry/cli releases finalize ${{ github.sha }}

- name: Delete source maps from deploy bundle
  run: find ./build -name '*.map' -delete

- name: Deploy (without source maps)
  run: aws s3 sync ./build s3://my-app-bucket

5.5 Error Boundaries (React)

Error boundaries catch render-time errors and prevent the entire app from crashing.

// src/components/ErrorBoundary.tsx
import React, { Component, ErrorInfo, ReactNode } from 'react';

interface Props {
  children: ReactNode;
  fallback?: ReactNode | ((props: { error: Error; reset: () => void }) => ReactNode);
  onError?: (error: Error, errorInfo: ErrorInfo) => void;
  level?: 'page' | 'section' | 'widget';
}

interface State {
  hasError: boolean;
  error: Error | null;
}

class ErrorBoundary extends Component<Props, State> {
  state: State = { hasError: false, error: null };

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    // Report to error tracking
    this.props.onError?.(error, errorInfo);

    console.error(`[ErrorBoundary:${this.props.level}]`, error, errorInfo);
  }

  reset = () => {
    this.setState({ hasError: false, error: null });
  };

  render() {
    if (this.state.hasError) {
      if (typeof this.props.fallback === 'function') {
        return this.props.fallback({
          error: this.state.error!,
          reset: this.reset,
        });
      }
      return this.props.fallback ?? <DefaultErrorFallback onRetry={this.reset} />;
    }
    return this.props.children;
  }
}

// Granular boundaries at different levels
function App() {
  return (
    <ErrorBoundary level="page" fallback={<FullPageError />}>
      <Header />
      <main>
        <ErrorBoundary level="section" fallback={<SectionError />}>
          <ProductGrid />
        </ErrorBoundary>
        <ErrorBoundary level="widget" fallback={<WidgetError />}>
          <Recommendations />
        </ErrorBoundary>
      </main>
    </ErrorBoundary>
  );
}

Error Boundary Placement Strategy:

┌────────────────────────────────────────┐
│  Page-Level Boundary                    │  ← Catches catastrophic failures
│                                         │     Shows "Something went wrong" page
│  ┌──────────────────────────────────┐  │
│  │  Section-Level Boundary           │  │  ← Catches section failures
│  │                                   │  │     Shows fallback, rest of page works
│  │  ┌──────────┐  ┌──────────┐      │  │
│  │  │ Widget   │  │ Widget   │      │  │  ← Catches widget failures
│  │  │ Boundary │  │ Boundary │      │  │     Shows placeholder, section works
│  │  └──────────┘  └──────────┘      │  │
│  └──────────────────────────────────┘  │
└────────────────────────────────────────┘

5.6 Structured Error Context

Always enrich errors with context so debugging is fast:

// src/errorTracking/errorReporter.ts

interface ErrorReport {
  // Error details
  type: string;
  message: string;
  stack?: string;

  // Context
  userId?: string;
  sessionId: string;
  page: string;
  route: string;
  component?: string;

  // Environment
  release: string;
  environment: string;
  browser: string;
  os: string;
  viewport: string;
  network: string;

  // Timing
  timestamp: string;
  pageLoadTime?: number;
  sessionDuration?: number;

  // Breadcrumbs (last N actions before error)
  breadcrumbs: Array<{
    type: 'click' | 'navigation' | 'api' | 'console' | 'state';
    message: string;
    timestamp: string;
    data?: Record<string, any>;
  }>;

  // App state snapshot (sanitized)
  state?: {
    cart?: { itemCount: number };
    auth?: { isLoggedIn: boolean; plan: string };
    flags?: Record<string, boolean>;
  };
}

⬆ Back to Top

Frontend Logging Where to Hold Logs and How

6.1 Client-Side Log Collection

Frontend logs are fundamentally different from backend logs — they originate on the user's device, not your server. Getting them off the client reliably is the core challenge.

Log Levels

// src/logging/logger.ts

enum LogLevel {
  DEBUG = 0,   // Development only — verbose debugging info
  INFO = 1,    // Normal operations — page views, user actions
  WARN = 2,    // Potential issues — deprecation, slow API, retry
  ERROR = 3,   // Errors — caught exceptions, API failures
  FATAL = 4,   // Critical — app crash, payment failure
}

interface LogEntry {
  level: LogLevel;
  message: string;
  data?: Record<string, any>;
  timestamp: string;
  sessionId: string;
  userId?: string;
  page: string;
  release: string;
}

class Logger {
  private buffer: LogEntry[] = [];
  private minLevel: LogLevel;
  private maxBufferSize: number;
  private flushInterval: ReturnType<typeof setInterval>;

  constructor(config: { minLevel: LogLevel; maxBufferSize?: number; flushIntervalMs?: number }) {
    this.minLevel = config.minLevel;
    this.maxBufferSize = config.maxBufferSize ?? 50;
    this.flushInterval = setInterval(() => this.flush(), config.flushIntervalMs ?? 10000);

    // Flush on page unload
    document.addEventListener('visibilitychange', () => {
      if (document.visibilityState === 'hidden') this.flush();
    });
  }

  debug(message: string, data?: Record<string, any>) { this.log(LogLevel.DEBUG, message, data); }
  info(message: string, data?: Record<string, any>)  { this.log(LogLevel.INFO, message, data); }
  warn(message: string, data?: Record<string, any>)  { this.log(LogLevel.WARN, message, data); }
  error(message: string, data?: Record<string, any>) { this.log(LogLevel.ERROR, message, data); }
  fatal(message: string, data?: Record<string, any>) { this.log(LogLevel.FATAL, message, data); }

  private log(level: LogLevel, message: string, data?: Record<string, any>) {
    if (level < this.minLevel) return;

    const entry: LogEntry = {
      level,
      message,
      data,
      timestamp: new Date().toISOString(),
      sessionId: getSessionId(),
      userId: getCurrentUserId(),
      page: window.location.pathname,
      release: __APP_VERSION__,
    };

    this.buffer.push(entry);

    // Immediate flush for FATAL
    if (level === LogLevel.FATAL) {
      this.flush();
      return;
    }

    if (this.buffer.length >= this.maxBufferSize) {
      this.flush();
    }
  }

  private async flush() {
    if (this.buffer.length === 0) return;

    const batch = this.buffer.splice(0);

    try {
      const blob = new Blob([JSON.stringify(batch)], { type: 'application/json' });
      const sent = navigator.sendBeacon('/api/logs', blob);

      if (!sent) {
        await fetch('/api/logs', {
          method: 'POST',
          body: JSON.stringify(batch),
          headers: { 'Content-Type': 'application/json' },
          keepalive: true,
        });
      }
    } catch {
      // Save to IndexedDB for retry
      await this.saveToIndexedDB(batch);
    }
  }

  private async saveToIndexedDB(entries: LogEntry[]) {
    try {
      const db = await openLogDB();
      const tx = db.transaction('logs', 'readwrite');
      for (const entry of entries) {
        tx.objectStore('logs').add(entry);
      }
      await tx.done;
    } catch {
      // Last resort — logs are lost. Acceptable for DEBUG/INFO.
    }
  }
}

// Production: only WARN and above
// Development: everything
export const logger = new Logger({
  minLevel: process.env.NODE_ENV === 'production' ? LogLevel.WARN : LogLevel.DEBUG,
  maxBufferSize: 50,
  flushIntervalMs: 10_000,
});

6.2 Log Transport — Getting Logs Off the Client

Transport Method	Reliability	Survives Page Unload	Size Limit	Use Case
`navigator.sendBeacon()`	High	✅ Yes	~64 KB	Primary method (analytics, logs)
`fetch()` with `keepalive`	High	✅ Yes	~64 KB	Fallback for sendBeacon
`fetch()` (normal)	Medium	❌ No	Unlimited	Batch uploads
`XMLHttpRequest`	Medium	❌ No	Unlimited	Legacy fallback
`Image` pixel	High	⚠️ Partial	~2 KB (URL)	Simple event pings
WebSocket	High (persistent)	❌ No	Unlimited	Real-time log streaming
IndexedDB (offline buffer)	High	✅ Persists	~50 MB+	Offline-first, retry queue

Transport Priority Chain

async function sendLogs(payload) {
  const body = JSON.stringify(payload);
  const blob = new Blob([body], { type: 'application/json' });

  // 1. Try sendBeacon (most reliable for page unload)
  if (navigator.sendBeacon?.('/api/logs', blob)) {
    return;
  }

  // 2. Fallback to fetch with keepalive
  try {
    await fetch('/api/logs', {
      method: 'POST',
      body,
      headers: { 'Content-Type': 'application/json' },
      keepalive: true,
    });
    return;
  } catch {}

  // 3. Last resort: save to IndexedDB for later retry
  await saveToIndexedDB(payload);
}

6.3 Log Storage & Querying Infrastructure

Where do logs go after they leave the browser? Here's the full pipeline:

┌──────────┐    ┌──────────────┐    ┌──────────────┐    ┌───────────────┐
│  Browser  │    │  Ingestion    │    │  Processing   │    │  Storage &     │
│           │    │  Layer        │    │  Layer        │    │  Querying      │
│ sendBeacon│───>│              │───>│              │───>│               │
│ fetch()   │    │  Options:     │    │  Options:     │    │  Options:      │
│           │    │  • API Gateway│    │  • Kafka      │    │  • ELK Stack   │
│           │    │  • Nginx      │    │  • Kinesis    │    │  • Loki+Grafana│
│           │    │  • Fluentd    │    │  • Datadog    │    │  • Datadog     │
│           │    │  • Vector     │    │    Pipeline   │    │  • CloudWatch  │
│           │    │  • CloudFlare │    │  • Logstash   │    │  • Splunk      │
│           │    │    Workers    │    │  • Vector     │    │  • ClickHouse  │
└──────────┘    └──────────────┘    └──────────────┘    └───────────────┘

Option 1: ELK Stack (Elasticsearch + Logstash + Kibana)

Browser → API Endpoint → Logstash → Elasticsearch → Kibana Dashboard

Pros: Powerful full-text search, great for debugging
Cons: Resource-heavy, expensive at scale

Best for: Large orgs with dedicated infra teams

Option 2: Loki + Grafana (Lightweight)

Browser → API Endpoint → Promtail/Vector → Loki → Grafana

Pros: Lightweight, cost-effective (only indexes labels, not content)
Cons: Weaker full-text search than ELK

Best for: Teams already using Grafana for metrics

Option 3: Datadog

Browser → Datadog Browser SDK → Datadog Logs → Datadog Dashboard

Pros: SaaS, zero infra, correlates logs + traces + metrics
Cons: Expensive at volume

Best for: Teams that want a single observability platform

Option 4: AWS CloudWatch Logs

Browser → API Gateway → Lambda → CloudWatch Logs → CloudWatch Insights

Pros: Serverless, auto-scales, native AWS integration
Cons: Query language is limited, UI is basic

Best for: AWS-native teams

Option 5: Sentry (Errors + Logs combined)

Browser → Sentry SDK → Sentry → Sentry Dashboard

Pros: Errors + breadcrumbs + replay in one place
Cons: Not designed for high-volume logging (use for errors/warnings only)

Best for: Error-focused logging (not general analytics logs)

Comparison Matrix

Solution	Self-Host	Cost	Query Power	Setup	Best For
ELK Stack	✅	$$$–$$$$ (infra)	⭐⭐⭐⭐⭐	Complex	Large scale, full-text search
Loki + Grafana	✅	$–$$	⭐⭐⭐	Medium	Cost-conscious, Grafana users
Datadog	❌ SaaS	$$$$	⭐⭐⭐⭐	Easy	All-in-one observability
CloudWatch	❌ AWS	$$	⭐⭐⭐	Easy	AWS-native teams
Sentry	❌ SaaS (or self-host)	$$–$$$	⭐⭐⭐	Easy	Error-focused
ClickHouse	✅	$–$$	⭐⭐⭐⭐	Medium	Custom analytics + logs

6.4 Structured Logging Best Practices

// ❌ BAD: Unstructured logs — impossible to query
console.log('User clicked button');
console.error('Payment failed for user john');

// ✅ GOOD: Structured logs — queryable, filterable
logger.info('button_clicked', {
  button_id: 'add_to_cart',
  product_id: 'SKU-123',
  page: '/product/SKU-123',
});

logger.error('payment_failed', {
  provider: 'stripe',
  error_code: 'card_declined',
  order_id: 'ORD-456',
  amount: 99.99,
  currency: 'USD',
  // ❌ NEVER log: user.email, user.name, card number, password
});

Structured log fields:

Field	Always Include?	Purpose
`timestamp`	✅	When it happened
`level`	✅	Severity (debug/info/warn/error/fatal)
`message`	✅	What happened (snake_case event name)
`sessionId`	✅	Group logs by session
`userId`	If available	Group logs by user
`page` / `route`	✅	Where it happened
`release`	✅	Which app version
`data.*`	Situational	Additional structured context
`traceId`	For APIs	Correlate frontend + backend logs

6.5 Log Levels & Sampling

Not all logs are equal. Sending every debug log from every user would be overwhelming and expensive.

Production Sampling Strategy:

  FATAL  → 100% sent (every fatal is critical)
  ERROR  → 100% sent (every error matters)
  WARN   → 50% sampled (reduce noise, still catch patterns)
  INFO   → 10% sampled (spot-check user flows)
  DEBUG  → 0% in production (development only)

  Exceptions:
  - 100% for users with active support tickets
  - 100% for internal/beta users
  - 100% for users in active experiments

// Sampling implementation
function shouldSample(level: LogLevel): boolean {
  const rates: Record<LogLevel, number> = {
    [LogLevel.FATAL]: 1.0,
    [LogLevel.ERROR]: 1.0,
    [LogLevel.WARN]:  0.5,
    [LogLevel.INFO]:  0.1,
    [LogLevel.DEBUG]: 0.0,
  };

  // Always log for internal users
  if (isInternalUser()) return true;

  return Math.random() < (rates[level] ?? 0);
}

6.6 Complete Logging Pipeline Architecture

┌──────────────────────────────────────────────────────────────────────┐
│                   Frontend Logging Pipeline                          │
│                                                                      │
│   COLLECTION          TRANSPORT         PROCESSING       STORAGE     │
│                                                                      │
│  ┌─────────────┐    ┌────────────┐    ┌────────────┐  ┌──────────┐  │
│  │ Logger       │    │ sendBeacon │    │ API Gateway│  │ Kafka /  │  │
│  │ (in-memory   │───>│ (primary)  │───>│ / Nginx    │─>│ Kinesis  │  │
│  │  buffer)     │    │            │    │            │  │          │  │
│  │              │    │ fetch()    │    └────────────┘  └────┬─────┘  │
│  │ Batch (20)   │    │ (fallback) │                         │        │
│  │ Flush (10s)  │    │            │                         ▼        │
│  │ Flush on     │    └────────────┘                   ┌──────────┐  │
│  │  unload      │                                     │ Stream    │  │
│  └──────┬──────┘                                     │ processor │  │
│         │ offline?                                    │ (enrich,  │  │
│         ▼                                            │  filter,  │  │
│  ┌─────────────┐    On reconnect                     │  route)   │  │
│  │ IndexedDB    │────── retry ──────────>             └─────┬────┘  │
│  │ (offline     │                                          │        │
│  │  buffer)     │                                          ▼        │
│  └─────────────┘                                    ┌──────────┐   │
│                                                      │ Storage   │   │
│                                                      │           │   │
│                                        Errors ──────>│ Sentry    │   │
│                                        Logs ────────>│ ELK/Loki  │   │
│                                        Analytics ───>│ ClickHouse│   │
│                                        Replays ─────>│ FullStory │   │
│                                                      └──────────┘   │
│                                                           │         │
│                                                           ▼         │
│                                                      ┌──────────┐  │
│                                                      │ Dashboards│  │
│                                                      │ & Alerts  │  │
│                                                      │ (Grafana, │  │
│                                                      │  PagerDuty│  │
│                                                      │  Slack)   │  │
│                                                      └──────────┘  │
└──────────────────────────────────────────────────────────────────────┘

⬆ Back to Top

Putting It All Together Unified Observability

In production, these systems are interconnected:

User Action
    │
    ├──→ Analytics:    track('product_added_to_cart', { ... })
    │
    ├──→ Feature Flag: useFeatureFlag('new_cart_animation')
    │
    ├──→ A/B Test:     experiment exposure tracked
    │
    ├──→ Logger:       logger.info('cart_updated', { itemCount: 3 })
    │
    └──→ Error (if any): Sentry captures with breadcrumbs + replay

All connected by:
  • sessionId  — groups all events from one visit
  • userId     — groups all events from one user
  • traceId    — connects frontend request to backend span
  • release    — associates events with a specific deploy

Unified SDK Example

// src/observability/index.ts
import { analytics } from './analytics';
import { logger } from './logger';
import { featureFlags } from './featureFlags';
import * as Sentry from '@sentry/react';

export const observability = {
  // Analytics
  track: analytics.track.bind(analytics),

  // Logging
  log: logger,

  // Feature flags
  flag: featureFlags.evaluate.bind(featureFlags),

  // Error tracking
  captureError: (error: Error, context?: Record<string, any>) => {
    Sentry.captureException(error, { extra: context });
    logger.error(error.message, context);
  },

  // Identify user across all systems
  identify(user: { id: string; plan: string; [key: string]: any }) {
    analytics.identify(user);
    Sentry.setUser({ id: user.id });
    featureFlags.updateContext({ userId: user.id, plan: user.plan });
    logger.info('user_identified', { userId: user.id });
  },
};

⬆ Back to Top

Decision Matrix and Quick Reference

What Tool for What Job?

Need	Tool Category	Recommendations
"What are users doing?"	Product Analytics	Amplitude, Mixpanel, PostHog
"Why is this page slow?"	Performance Monitoring	Web Vitals + Sentry Perf / Datadog RUM
"What happened before the crash?"	Error Tracking + Replay	Sentry (errors) + LogRocket/FullStory (replay)
"Where are users clicking?"	Heatmaps	Hotjar, Microsoft Clarity (free)
"Is the new design better?"	A/B Testing	LaunchDarkly, Statsig, PostHog
"Can I ship this safely?"	Feature Flags	LaunchDarkly, Unleash, Flagsmith
"What's in the logs?"	Log Management	ELK, Loki+Grafana, Datadog Logs
"User reported a bug"	Session Replay	FullStory, LogRocket, Sentry Replay

Startup vs Enterprise Stack

Stage	Recommended Stack	Monthly Cost
Early startup	PostHog (all-in-one, free self-host) + Sentry (free tier)	$0–$50
Growing startup	Amplitude (analytics) + Sentry (errors) + LaunchDarkly (flags) + Clarity (replay)	$200–$1,000
Mid-size	Segment (CDP) + Amplitude + Sentry + LaunchDarkly + FullStory	$2,000–$10,000
Enterprise	Segment + custom analytics (ClickHouse) + Datadog (full stack) + LaunchDarkly	$10,000+

⬆ Back to Top

Key Interview Takeaways

Topic	Key Points to Mention
Analytics	Event taxonomy (object_action), batching with sendBeacon, sampling for cost, funnel tracking for business metrics
A/B Testing	Server-side evaluation to avoid flicker, deterministic hashing for assignment, statistical significance before calling results
Feature Flags	Decouple deploy from release, singleton evaluation (LD/Unleash), flag hygiene (expiry, owners, cleanup)
Session Replay	DOM diffing (rrweb / MutationObserver), privacy masking, storage cost vs value
Error Tracking	Global handlers (`error`, `unhandledrejection`), source maps uploaded to Sentry (not served), breadcrumbs for context, Error Boundaries at page/section/widget levels
Logging	Structured logs (not console.log), sendBeacon + IndexedDB for reliability, log levels + sampling for cost, ELK/Loki/Datadog for storage
Where to store logs	Sentry for errors, ELK/Loki/Datadog for general logs, ClickHouse for analytics, IndexedDB for offline buffer — never only in the browser

⬆ Back to Top

Frontend System Design: Communication Protocols & Real-Time Data

ZeeshanAli-0704 — Sat, 14 Mar 2026 12:23:47 +0000

Communication Protocols & Real-Time Data — Frontend Interview Guide

Flow diagrams, working explanations, and trade-offs for HTTP, Polling, Long Polling, WebSockets, SSE, WebRTC, gRPC-Web, and GraphQL Subscriptions.

Overview and Mental Model
HTTP
Short Polling
Long Polling
Server Sent Events (SSE)
WebSockets
WebRTC
gRPC Web
GraphQL Subscriptions
Microservice Communication Patterns
Comparison Table
Decision Flowchart Which Protocol to Pick
Real World Architecture Examples
Interview Questions and Answers

⬆ Back to Top

Overview and Mental Model

Client ◄──────────────────────────────────► Server

 HTTP          Request → Response (one-shot)
 Short Poll    Request → Response → wait → repeat
 Long Poll     Request → ...hangs... → Response → repeat
 SSE           Request → Stream ←←←←← (server pushes)
 WebSocket     Handshake → ◄══ Full-duplex ══►
 WebRTC        Signaling → ◄══ Peer-to-Peer ══►

The Core Question

Need	Best Fit
Fetch data once	HTTP REST / GraphQL
Near-real-time updates (seconds OK)	Short Polling
Real-time, server → client only	SSE
Real-time, bidirectional	WebSocket
Ultra-low latency media/P2P	WebRTC
Strongly-typed RPCs from browser	gRPC-Web

⬆ Back to Top

HTTP

2.1 What Is It?

HTTP (HyperText Transfer Protocol) is a request-response protocol. The client sends a request; the server sends back exactly one response. The connection is stateless by default.

2.2 How It Works

Client initiates — The browser (or any HTTP client) opens a TCP connection to the server and sends an HTTP request containing a method (GET, POST, etc.), headers, and optionally a body.
Server processes — The server receives the request, performs the appropriate logic (read from DB, compute, etc.), and prepares a response.
Server responds — The server sends back a status code (e.g., 200 OK, 404 Not Found), response headers, and a body (JSON, HTML, etc.).
Connection closes or reuses — In HTTP/1.0 the connection closes immediately. In HTTP/1.1+ with keep-alive, the same TCP connection can be reused for subsequent requests, reducing handshake overhead.
Stateless — Each request is independent. The server does not remember previous requests unless state is stored externally (cookies, sessions, tokens).

2.3 Evolution

Version	Year	Key Feature
HTTP/1.0	1996	One request per TCP connection
HTTP/1.1	1997	Keep-alive, pipelining, chunked transfer
HTTP/2	2015	Multiplexing, header compression (HPACK), server push
HTTP/3	2022	QUIC (UDP-based), zero-RTT handshake, no head-of-line blocking

2.4 HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1          HTTP/2               HTTP/3
┌──────┐         ┌──────┐            ┌──────┐
│ Req1 │──┐      │Req1  │──┐        │Req1  │──┐
│ Res1 │◄─┘      │Req2  │  │ MUX    │Req2  │  │ MUX over
│ Req2 │──┐      │Req3  │  │ over   │Req3  │  │ QUIC (UDP)
│ Res2 │◄─┘      │Res2  │◄─┘ TCP    │Res1  │◄─┘
│ Req3 │──┐      │Res1  │           │Res3  │
│ Res3 │◄─┘      │Res3  │           │Res2  │
└──────┘         └──────┘            └──────┘
 Sequential       Multiplexed         No HOL blocking

HTTP/1.1 — Requests are sequential on a single connection (head-of-line blocking). Browsers open up to 6 parallel TCP connections per domain to work around this.
HTTP/2 — Multiplexes many requests/responses over a single TCP connection using binary frames and streams. Header compression (HPACK) reduces overhead. However, a single TCP packet loss stalls all streams (TCP-level HOL blocking).
HTTP/3 — Replaces TCP with QUIC (built on UDP). Each stream is independent, so a lost packet only blocks its own stream. Supports 0-RTT handshakes for faster connection setup.

2.5 Basic Syntax

// GET request
const res = await fetch('/api/posts');
const data = await res.json();

// POST request
await fetch('/api/posts', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ title: 'Hello' })
});

2.6 When to Use

Standard CRUD operations (REST APIs)
Page loads, form submissions
Static asset fetching
Any request-response interaction that doesn't need real-time

2.7 Pros & Cons

Pros	Cons
Simple, well-understood	No server push (HTTP/1.1)
Cacheable (ETags, Cache-Control)	New connection overhead (HTTP/1.1)
Stateless → easy to scale	Not suitable for real-time
Wide tooling support	Head-of-line blocking (HTTP/1.1, partially HTTP/2)

⬆ Back to Top

Short Polling

3.1 What Is It?

The client sends repeated HTTP requests at a fixed interval to check for new data. The server responds immediately — whether or not there's new data.

3.2 How It Works

Client                          Server
  │── GET /updates ──────────►│
  │◄── 200 { data: [] } ──────│  (no new data)
  │                            │
  │  ... wait 5 seconds ...    │
  │                            │
  │── GET /updates ──────────►│
  │◄── 200 { data: [msg1] } ──│  (new data!)
  │                            │
  │  ... wait 5 seconds ...    │
  │                            │
  │── GET /updates ──────────►│
  │◄── 200 { data: [] } ──────│  (no new data)

Client sets a timer — A setInterval (or similar) triggers a fetch request every N seconds (e.g., every 5s).
Server responds immediately — The server checks for new data and returns it right away. If nothing is new, it returns an empty response (e.g., { data: [] }).
Client processes response — If data is present, the UI updates. If empty, the client simply waits for the next interval.
Repeat — The cycle continues indefinitely until the client stops the timer.
No persistent connection — Each request is a completely independent HTTP round-trip. There's no state between requests on the server side.

Trade-off: The maximum delay before the client sees new data equals the polling interval. Shorter intervals = more responsive but more server load. Longer intervals = less load but stale data.

3.3 Basic Syntax

function startPolling(url, interval = 5000) {
  const poll = async () => {
    const res = await fetch(url);
    const data = await res.json();
    if (data.length > 0) handleNewData(data);
  };

  poll();
  return setInterval(poll, interval);
}

// Start & stop
const timerId = startPolling('/api/notifications', 3000);
clearInterval(timerId); // stop

3.4 When to Use

Dashboard refresh (analytics, stock tickers with 5-10s tolerance)
Checking job/task status (file upload progress, CI build status)
Simple notification badge counts
When infrastructure doesn't support WebSocket/SSE

3.5 Pros & Cons

Pros	Cons
Simplest to implement	Wastes bandwidth (empty responses)
Works everywhere (plain HTTP)	Latency = up to `interval` delay
Easy to debug	Hammers the server at scale
Stateless	Not truly real-time

⬆ Back to Top

Long Polling

4.1 What Is It?

The client sends a request, and the server holds the connection open until new data is available (or a timeout occurs). Once the client gets a response, it immediately sends a new request.

4.2 How It Works

Client                              Server
  │── GET /updates ───────────────►│
  │                                │  (server holds connection)
  │          ... waiting ...       │
  │                                │  ← new data arrives!
  │◄── 200 { data: [msg1] } ──────│
  │                                │
  │── GET /updates ───────────────►│  (immediately reconnect)
  │                                │  (server holds again...)
  │          ... waiting ...       │
  │         (timeout 30s)          │
  │◄── 204 No Content ────────────│
  │                                │
  │── GET /updates ───────────────►│  (reconnect)

Client sends request — The client makes a standard HTTP GET request, often including a Last-Event-ID or timestamp so the server knows what the client has already seen.
Server holds the connection — Instead of responding immediately, the server keeps the request open. It parks the response object and waits for something to happen (new message, event from a queue, etc.).
New data arrives → server responds — As soon as relevant data is available, the server writes it to the held-open response and closes it (HTTP 200 with the payload).
Timeout handling — If no data arrives within a timeout window (e.g., 30s), the server responds with 204 No Content (or an empty body) so the connection doesn't hang forever. Proxies and load balancers also have timeouts that must be respected.
Client immediately reconnects — The moment the client receives any response (data or timeout), it fires a new request to the server. This creates a continuous loop that feels near-real-time.
Server resource cost — Each waiting client occupies a held-open connection on the server. This can be expensive at scale since the server needs to manage many parked response objects.

Key difference from Short Polling: instead of the client repeatedly asking "anything new?", the server answers only when there IS something new — drastically reducing empty responses.

4.3 Basic Syntax

async function longPoll(url) {
  while (true) {
    try {
      const res = await fetch(url);
      if (res.status === 200) {
        const data = await res.json();
        handleNewData(data);
      }
      // 204 = timeout, no data → just reconnect
    } catch (err) {
      await new Promise(r => setTimeout(r, 3000)); // backoff on error
    }
  }
}

4.4 When to Use

Chat applications (before WebSocket adoption — Facebook used this)
Real-time notifications where SSE/WS aren't available
Environments behind strict firewalls/proxies that kill WS connections
When you need near-instant updates but can't use WebSocket

4.5 Pros & Cons

Pros	Cons
Near real-time delivery	Server holds open connections (resource cost)
Works through most proxies/firewalls	More complex than short polling
Fewer empty responses than short polling	Timeouts need careful handling
Universal browser support	Ordering/duplicate issues possible

⬆ Back to Top

Server Sent Events (SSE)

5.1 What Is It?

SSE is a unidirectional protocol where the server pushes data to the client over a single, long-lived HTTP connection. Built on top of HTTP — uses text/event-stream content type. The browser provides a native EventSource API.

5.2 How It Works

Client                                  Server
  │── GET /events ────────────────────►│
  │◄── HTTP 200                        │
  │◄── Content-Type: text/event-stream │
  │                                    │
  │◄── data: {"msg": "hello"}         │  ← push
  │                                    │
  │◄── data: {"msg": "world"}         │  ← push
  │                                    │
  │◄── event: alert                    │  ← named event
  │◄── data: {"level": "critical"}    │
  │                                    │
  │    (connection stays open...)      │

Client opens connection — The client creates an EventSource object pointing to a URL. The browser sends a standard HTTP GET request to that endpoint.
Server responds with event stream — The server responds with Content-Type: text/event-stream and keeps the connection open. It does NOT close the response — instead it writes data incrementally.
Server pushes events — Whenever the server has new data, it writes a text block in SSE format (data: ...\n\n) to the open response. Each double newline (\n\n) marks the end of one event.
Client receives events automatically — The EventSource API fires onmessage for default events, or custom event listeners for named events (e.g., event: notification).
Auto-reconnection — If the connection drops (network issue, server restart), the browser automatically reconnects after a configurable delay (retry: field). On reconnection, the browser sends a Last-Event-ID header with the last received id: value so the server can resume from where the client left off.
Connection stays open — Unlike regular HTTP, the response never "finishes". The server keeps the TCP connection alive and writes new events as they occur. The client can close it explicitly with source.close().

Event Stream Format:

data: Simple text message\n\n

event: notification
id: 42
data: {"type": "friend_request"}\n\n

retry: 5000

data: — The payload (required)
event: — Custom event name (default is "message")
id: — Event ID (used for auto-reconnection with Last-Event-ID header)
retry: — Reconnection interval in ms

5.3 Basic Syntax

const source = new EventSource('/api/events');

source.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('New message:', data);
};

source.addEventListener('notification', (event) => {
  showNotification(JSON.parse(event.data));
});

source.onerror = () => console.error('SSE error');
// EventSource auto-reconnects — no manual retry needed

source.close(); // close when done

5.4 When to Use

Live feeds (news, social media timeline updates)
Stock tickers, sports scores
Real-time notifications / alerts
Log streaming / build output
AI/LLM streaming responses (ChatGPT-style token streaming)
Any scenario where server → client is the primary data flow

5.5 Pros & Cons

Pros	Cons
Native browser API (`EventSource`)	Unidirectional only (server → client)
Auto-reconnection built-in	Max 6 connections per domain on HTTP/1.1 (limit removed on HTTP/2 via multiplexing)
Works over standard HTTP	No binary data (text only)
Lightweight, simple protocol	Less browser support than WebSocket for older browsers
Event IDs for reliable delivery
Works with HTTP/2 multiplexing

⬆ Back to Top

WebSockets

6.1 What Is It?

WebSocket is a full-duplex, bidirectional communication protocol. It starts as an HTTP request (upgrade handshake), then switches to a persistent TCP connection where both client and server can send messages at any time.

6.2 How It Works

Client                                    Server
  │── GET /chat HTTP/1.1 ──────────────►│
  │   Upgrade: websocket                │
  │   Connection: Upgrade               │
  │   Sec-WebSocket-Key: dGhlIHNh...    │
  │                                      │
  │◄── HTTP 101 Switching Protocols ────│
  │    Upgrade: websocket               │
  │    Sec-WebSocket-Accept: s3pPLM...  │
  │                                      │
  │◄════════ Full Duplex ═══════════════►│
  │                                      │
  │──► {"type":"msg","text":"Hi"}       │
  │◄── {"type":"msg","text":"Hello!"}   │
  │◄── {"type":"typing","user":"Bob"}   │
  │──► {"type":"msg","text":"How?"}     │
  │                                      │
  │──► Close Frame ─────────────────────│
  │◄── Close Frame ─────────────────────│

HTTP Upgrade Handshake — The client sends a standard HTTP GET request with special headers: Upgrade: websocket, Connection: Upgrade, and a random Sec-WebSocket-Key. This goes over the same port as HTTP (80/443).
Server accepts the upgrade — If the server supports WebSocket, it responds with HTTP 101 Switching Protocols and a Sec-WebSocket-Accept header (computed from the client's key + a magic GUID). This proves the server understands the WebSocket protocol.
Protocol switches — After the 101 response, the connection is no longer HTTP. It becomes a persistent, raw TCP connection using the WebSocket frame-based binary protocol. Both sides can now send data at any time.
Full-duplex communication — Either the client or the server can send messages independently. Messages are wrapped in small WebSocket frames (2-14 bytes overhead vs ~200-800 bytes for HTTP headers). Both text and binary data are supported.
Heartbeat / keep-alive — To detect stale connections, implementations use ping/pong frames. The server sends a ping; the client automatically responds with a pong. If no pong is received, the server terminates the connection.
No auto-reconnect — Unlike SSE, WebSocket has no built-in reconnection. If the connection drops, the onclose event fires and the client must manually reconnect (ideally with exponential backoff + jitter to avoid thundering herd).
Closing — Either side can initiate a close by sending a close frame. The other side responds with a close frame, and the TCP connection is torn down. Clean closes use code 1000.

6.3 Basic Syntax

const ws = new WebSocket('wss://api.example.com/ws');

ws.onopen = () => ws.send(JSON.stringify({ type: 'join', room: 'general' }));

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  // handle data.type: 'message', 'typing', 'presence', etc.
};

ws.onclose = (event) => {
  if (!event.wasClean) setTimeout(() => reconnect(), 3000);
};

ws.close(1000, 'Done'); // clean close

6.4 Reconnection Strategy

WebSocket does not auto-reconnect. Production apps must implement:

Connection drops → onclose fires
  │
  ▼
Start reconnection loop:
  Attempt 1 → wait 1s + random jitter
  Attempt 2 → wait 2s + random jitter
  Attempt 3 → wait 4s + random jitter   (exponential backoff)
  ...
  Attempt N → wait min(2^N seconds, 30s max cap)
  │
  ▼
On successful reconnect:
  • Reset retry counter
  • Flush any queued messages (buffered while offline)
  • Re-subscribe to rooms/channels
  │
  ▼
After max retries exceeded:
  • Show error UI to user
  • Optionally fall back to polling

6.5 Scaling WebSocket Connections

┌──────────┐                 ┌──────────────┐
│  Client   │◄═══ WS ═══════►│  WS Server 1 │──┐
└──────────┘                 └──────────────┘  │   ┌─────────┐
                                                ├──►│  Redis   │
┌──────────┐                 ┌──────────────┐  │   │  Pub/Sub │
│  Client   │◄═══ WS ═══════►│  WS Server 2 │──┘   └─────────┘
└──────────┘                 └──────────────┘
       ▲                           ▲
       └── Sticky Sessions ────────┘
           (IP hash / cookie)

Sticky sessions ensure a client always reaches the same server (needed because WS is stateful).
Pub/Sub layer (Redis, Kafka, NATS) enables cross-server broadcasting — a message sent to Server 1 reaches clients on Server 2.
A single server can handle ~10K-100K concurrent WS connections (tune OS file descriptors and memory).

6.6 When to Use

Chat applications (Slack, WhatsApp Web, Discord)
Multiplayer games
Collaborative editing (Google Docs, Figma)
Live trading platforms
Real-time dashboards that also accept user input
Any scenario with frequent bidirectional messages

6.7 Pros & Cons

Pros	Cons
True bidirectional, full-duplex	More complex server infrastructure
Very low latency	Stateful → harder to scale horizontally
Binary + text data support	No auto-reconnect (must implement)
Single TCP connection	Proxy/firewall issues (some block WS)
Efficient for high-frequency messages	No built-in request-response semantics
Wide browser support	Memory cost per connection on server

⬆ Back to Top

WebRTC

7.1 What Is It?

WebRTC (Web Real-Time Communication) enables peer-to-peer audio, video, and arbitrary data transfer directly between browsers, with minimal server involvement (signaling only).

7.2 How It Works

Browser A                  Signaling Server              Browser B
    │                           │                            │
    │── Offer (SDP) ──────────►│                            │
    │                           │── Offer (SDP) ───────────►│
    │                           │                            │
    │                           │◄── Answer (SDP) ──────────│
    │◄── Answer (SDP) ─────────│                            │
    │                           │                            │
    │── ICE Candidates ───────►│── ICE Candidates ─────────►│
    │◄── ICE Candidates ───────│◄── ICE Candidates ─────────│
    │                           │                            │
    │◄═══════════ Direct P2P Connection ══════════════════►  │
    │     (audio / video / data)                             │

Signaling (via a server) — Before peers can talk directly, they need to exchange connection metadata. This is done through a signaling server (using WebSocket, HTTP, or any transport). The signaling server does NOT relay media — it only relays setup messages.
SDP Offer/Answer — Peer A creates an SDP (Session Description Protocol) offer describing its capabilities: supported codecs, media types, encryption parameters. This offer is sent to Peer B via the signaling server. Peer B responds with an SDP answer confirming which capabilities it supports.
ICE Candidate Gathering — Both peers simultaneously discover their own network addresses using ICE (Interactive Connectivity Establishment):
- Host candidates — local IP addresses
- Server-reflexive candidates — public IP discovered via a STUN server (helps peers behind NAT)
- Relay candidates — fallback through a TURN server when direct connection is impossible (strict firewalls)

Each discovered candidate is sent to the other peer via the signaling server.

Connectivity checks — ICE performs connectivity checks on all candidate pairs (Peer A's candidates × Peer B's candidates) to find the best working path. It prioritizes direct connections over relayed ones.
Direct P2P connection established — Once a working candidate pair is found, a direct connection is established between the two browsers. All subsequent data flows peer-to-peer, bypassing the server entirely.
Secure media/data transfer — Audio and video are encrypted with SRTP, data channels use DTLS. Encryption is mandatory in WebRTC — there is no unencrypted mode.
For large groups — Pure P2P doesn't scale (N users = N×(N-1)/2 connections). For group calls, architectures use:
- SFU (Selective Forwarding Unit) — a server that receives streams and selectively forwards them (used by Zoom, Meet)
- MCU (Multipoint Control Unit) — a server that mixes all streams into one (higher server CPU cost)

7.3 Basic Syntax

// Create peer connection
const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});

// Create data channel (or add media tracks)
const channel = pc.createDataChannel('chat');
channel.onmessage = (e) => console.log(e.data);

// Create and send offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// → send offer to remote peer via signaling server

// Receive answer from remote peer
await pc.setRemoteDescription(remoteAnswer);

// Exchange ICE candidates
pc.onicecandidate = (e) => {
  if (e.candidate) sendToRemotePeer(e.candidate);
};

7.4 When to Use

Video/audio calls (Zoom, Google Meet, Teams)
Screen sharing
Peer-to-peer file transfer
Low-latency multiplayer gaming
IoT device communication

7.5 Pros & Cons

Pros	Cons
Peer-to-peer (low latency)	Complex setup (ICE, STUN, TURN)
Supports audio, video, data	Firewall/NAT traversal issues
Encrypted by default (DTLS/SRTP)	Higher battery usage on mobile
Reduces server bandwidth costs	Doesn't scale for large groups (need SFU/MCU)

7.5 STUN, TURN & ICE — NAT Traversal Explained

Most devices sit behind NATs (Network Address Translators) or firewalls. WebRTC needs to discover a path between two peers — that's where ICE (Interactive Connectivity Establishment) comes in.

┌─────────────────────────────────────────────────────────────────┐
│                    ICE Candidate Gathering                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. Host Candidates        — Local IP addresses (LAN)           │
│  2. Server Reflexive (srflx) — Public IP via STUN               │
│  3. Relay Candidates       — Relayed via TURN (fallback)        │
│                                                                 │
│  ICE tries candidates in order: Host → srflx → Relay            │
│  (Fastest to slowest, cheapest to most expensive)                │
└─────────────────────────────────────────────────────────────────┘

STUN (Session Traversal Utilities for NAT)

┌────────┐    "What's my public IP?"    ┌────────────┐
│ Peer A  │────────────────────────────►│ STUN Server │
│ (NAT)   │◄────────────────────────────│ (Public)    │
└────────┘    "Your IP is 203.0.113.5   └────────────┘
               port 54321"

Purpose: Discover the peer's public IP and port.
Lightweight: Only used during connection setup, not for media relay.
Free: Google provides free STUN servers (stun:stun.l.google.com:19302).
Limitation: Fails if both peers are behind symmetric NATs (port mapping changes per destination).

TURN (Traversal Using Relays around NAT)

┌────────┐                   ┌─────────────┐                   ┌────────┐
│ Peer A  │═══ Encrypted ═══►│ TURN Server  │═══ Encrypted ═══►│ Peer B  │
│ (NAT)   │◄═════════════════│  (Relay)     │◄═════════════════│ (NAT)  │
└────────┘                   └─────────────┘                   └────────┘

Purpose: Relay media/data when direct P2P fails (symmetric NAT, strict firewalls).
Always works: Acts as a middleman — both peers connect to TURN, which forwards data.
Expensive: TURN consumes bandwidth on the relay server (you pay for it).
Last resort: ICE tries STUN/direct first; TURN is the fallback.
Allocation: Peer requests a TURN allocation (reserved port), which is time-limited and authenticated.

ICE (Interactive Connectivity Establishment)

ICE orchestrates the entire process:

1. Gather all candidates (host, srflx via STUN, relay via TURN)
2. Exchange candidates with remote peer via signaling server
3. Pair local candidates with remote candidates
4. Run connectivity checks on each pair (STUN Binding Requests)
5. Select the best working pair (lowest latency, direct > relay)
6. Begin media/data transfer on the selected path

ICE States:

State	Meaning
`new`	ICE agent created, no candidates gathered yet
`gathering`	Collecting local candidates (host, srflx, relay)
`checking`	Running connectivity checks on candidate pairs
`connected`	At least one working pair found
`completed`	All checks done, best pair selected
`failed`	No working pair found (connection impossible)
`disconnected`	Connectivity lost (may recover)
`closed`	ICE agent shut down

peerConnection.oniceconnectionstatechange = () => {
  console.log('ICE state:', peerConnection.iceConnectionState);
  // 'checking' → 'connected' → 'completed' (happy path)
  // 'checking' → 'failed' (no path found)
  // 'connected' → 'disconnected' → 'connected' (network hiccup)
};

Trickle ICE vs Full ICE:

Approach	Description	Speed
Full ICE	Gather ALL candidates first, then send offer/answer	Slower (waits for TURN)
Trickle ICE	Send candidates as they're discovered, incrementally	Faster (connection starts sooner)

Trickle ICE is the modern default — candidates are sent via signaling as they appear.

7.6 SDP (Session Description Protocol)

SDP is the metadata format exchanged during WebRTC signaling. It describes the media capabilities of each peer.

v=0
o=- 4611731400430051location 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 49170 RTP/SAVPF 111 103 104
c=IN IP4 203.0.113.5
a=rtpmap:111 opus/48000/2         ← Opus audio codec
a=fmtp:111 minptime=10;useinbandfec=1
a=candidate:0 1 UDP 2113667327 192.168.1.5 54321 typ host
a=candidate:1 1 UDP 1694498815 203.0.113.5 54321 typ srflx raddr 192.168.1.5 rport 54321
m=video 51372 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000               ← VP8 video codec
a=rtpmap:97 H264/90000             ← H264 video codec

Key SDP Fields:

Field	Meaning
`m=`	Media line (audio, video, or application for data channels)
`a=rtpmap:`	Codec mapping (which codecs the peer supports)
`a=candidate:`	ICE candidate (IP, port, type)
`a=fingerprint:`	DTLS certificate fingerprint (for encryption verification)
`a=ice-ufrag` / `a=ice-pwd`	ICE credentials for connectivity checks

Offer/Answer Model:

Peer A creates Offer SDP  →  "I can do Opus audio + VP8/H264 video"
                               Sends via signaling server
Peer B receives Offer     →  "I can do Opus audio + VP8 video (no H264)"
Peer B creates Answer SDP →  "Let's use Opus + VP8"
                               Sends via signaling server
Peer A receives Answer    →  Negotiation complete, start media

7.7 WebRTC Media — Tracks, Streams & Transceivers

// ─── Getting User Media ───
const stream = await navigator.mediaDevices.getUserMedia({
  video: { width: 1280, height: 720, frameRate: 30 },
  audio: { echoCancellation: true, noiseSuppression: true }
});

// ─── Screen Sharing ───
const screenStream = await navigator.mediaDevices.getDisplayMedia({
  video: { cursor: 'always' },
  audio: true // system audio (if supported)
});

// ─── Adding Tracks to Peer Connection ───
stream.getTracks().forEach(track => {
  peerConnection.addTrack(track, stream);
});

// ─── Receiving Remote Tracks ───
peerConnection.ontrack = (event) => {
  const [remoteStream] = event.streams;
  remoteVideoElement.srcObject = remoteStream;
};

// ─── Transceivers (fine-grained control) ───
const transceiver = peerConnection.addTransceiver('video', {
  direction: 'sendrecv',      // 'sendonly', 'recvonly', 'inactive'
  sendEncodings: [
    { rid: 'high', maxBitrate: 2500000 },  // Simulcast layers
    { rid: 'mid', maxBitrate: 500000, scaleResolutionDownBy: 2 },
    { rid: 'low', maxBitrate: 150000, scaleResolutionDownBy: 4 }
  ]
});

7.8 SFU vs MCU vs Mesh — Scaling WebRTC

WebRTC is P2P by design, but group calls need different topologies:

┌─────────────────────────── MESH ──────────────────────────────┐
│                                                                │
│     A ◄══════► B          Each peer connects to EVERY other    │
│     ▲ ╲      ╱ ▲          peer. N peers = N×(N-1)/2 connections│
│     ║   ╲  ╱   ║          Good for: 2-4 participants           │
│     ║    ╲╱    ║          Bad for: 5+ (CPU/bandwidth explodes) │
│     ▼   ╱ ╲   ▼                                                │
│     C ◄══════► D                                               │
└────────────────────────────────────────────────────────────────┘

┌─────────────────────────── SFU ───────────────────────────────┐
│              (Selective Forwarding Unit)                        │
│                                                                │
│     A ──send──► ┌─────┐ ──forward──► B                        │
│     B ──send──► │ SFU │ ──forward──► A                        │
│     C ──send──► │     │ ──forward──► A, B, D                  │
│     D ──send──► └─────┘ ──forward──► A, B, C                  │
│                                                                │
│  Each peer sends ONE stream to SFU.                            │
│  SFU selectively forwards to each recipient.                   │
│  No transcoding — just routing. Low server CPU.                │
│  Used by: Zoom, Google Meet, Twilio, Jitsi                     │
└────────────────────────────────────────────────────────────────┘

┌─────────────────────────── MCU ───────────────────────────────┐
│            (Multipoint Conferencing Unit)                       │
│                                                                │
│     A ──send──► ┌─────┐                                       │
│     B ──send──► │ MCU │ ──mixed stream──► A, B, C, D          │
│     C ──send──► │     │                                       │
│     D ──send──► └─────┘                                       │
│                                                                │
│  MCU decodes ALL streams, mixes them into ONE composite        │
│  stream, re-encodes, and sends to each peer.                   │
│  Very CPU-intensive server. Low client bandwidth.              │
│  Used by: Legacy video conferencing systems                    │
└────────────────────────────────────────────────────────────────┘

Topology	Upload	Download	Server CPU	Best For
Mesh	N-1 streams	N-1 streams	None	2-4 people, simple
SFU	1 stream	N-1 streams	Low (routing)	5-50+ people
MCU	1 stream	1 stream	Very High (transcoding)	Low-bandwidth clients

7.9 WebRTC Security Model

┌────────────────────────────────────────────────────────────────┐
│                    WebRTC Security Stack                        │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│  ┌────────────────┐   ┌─────────────────────────────────────┐  │
│  │  Data Channels  │   │  Media (Audio/Video)                │  │
│  │  ───────────── │   │  ─────────────────────              │  │
│  │  SCTP over DTLS │   │  SRTP (Secure RTP)                  │  │
│  │                │   │  Keys exchanged via DTLS             │  │
│  └────────┬───────┘   └──────────────┬──────────────────────┘  │
│           │                          │                         │
│           ▼                          ▼                         │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  DTLS (Datagram Transport Layer Security)               │   │
│  │  • TLS-like encryption for UDP                          │   │
│  │  • Certificate fingerprints verified via SDP            │   │
│  │  • Mutual authentication (both peers verify)            │   │
│  └─────────────────────────────────────────────────────────┘   │
│                          │                                     │
│                          ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  ICE + UDP/TCP Transport                                │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                │
│  Key Points:                                                   │
│  • ALL WebRTC communication is encrypted by default            │
│  • Cannot be disabled — encryption is mandatory                │
│  • SRTP keys derived from DTLS handshake (no external KMS)    │
│  • getUserMedia requires HTTPS (secure context) or localhost   │
│  • User must grant explicit permission for camera/mic          │
└────────────────────────────────────────────────────────────────┘

7.10 WebRTC Complete Connection Flow (Putting It All Together)

┌──────────┐         ┌──────────────┐          ┌──────────┐
│  Peer A   │         │  Signaling    │          │  Peer B   │
│           │         │  Server       │          │           │
│  1. Create│         │  (WebSocket/  │          │           │
│     PeerConn        │   HTTP)       │          │           │
│           │         │               │          │           │
│  2. getUserMedia()  │               │          │           │
│     (camera+mic)    │               │          │           │
│           │         │               │          │           │
│  3. addTrack()      │               │          │           │
│           │         │               │          │           │
│  4. createOffer()   │               │          │           │
│  5. setLocalDesc()  │               │          │           │
│           │         │               │          │           │
│  6. ──Offer SDP────►│──Offer SDP───►│          │           │
│           │         │               │  7. setRemoteDesc()  │
│           │         │               │  8. createAnswer()   │
│           │         │               │  9. setLocalDesc()   │
│           │         │               │          │           │
│           │◄─Answer SDP─│◄─Answer SDP──│          │
│ 10. setRemoteDesc() │               │          │           │
│           │         │               │          │           │
│ 11. ICE candidates ◄═══════════════► ICE candidates       │
│     (trickled via signaling)                    │           │
│           │         │               │          │           │
│ 12. DTLS Handshake ◄═════ P2P ═════► DTLS Handshake       │
│           │         │               │          │           │
│ 13. ◄════ SRTP Media + SCTP Data ════►         │           │
│           │         │               │          │           │
│     🎉 Connected!   │               │  🎉 Connected!       │
└──────────┘         └──────────────┘          └──────────┘

⬆ Back to Top

gRPC Web

8.1 What Is It?

gRPC-Web allows browsers to call gRPC services using Protocol Buffers. It provides strongly-typed, efficient RPC communication but requires a proxy (like Envoy) since browsers can't do native HTTP/2 gRPC.

8.2 How It Works

Browser ──► gRPC-Web ──► Envoy Proxy ──► gRPC Server
           (HTTP/1.1      (translates     (HTTP/2
            or HTTP/2)     to gRPC)        native)

Define service contracts — Services are defined in .proto files using Protocol Buffers (protobuf). These define the RPC methods, request types, and response types in a language-neutral schema.
Code generation — The .proto file is compiled into client-side JavaScript/TypeScript stubs using protoc with the gRPC-Web plugin. This generates typed request/response classes and service client methods — no manual HTTP calls needed.
Client makes RPC call — The browser calls the generated client method (e.g., client.getUser(request, ...)). Under the hood, gRPC-Web serializes the request into a compact binary protobuf format and sends it as an HTTP/1.1 or HTTP/2 request with Content-Type: application/grpc-web.
Proxy translates — Browsers cannot speak native gRPC (which requires HTTP/2 trailers and full-duplex streaming). An Envoy proxy (or similar) sits between the browser and the gRPC server, translating the gRPC-Web request into a native gRPC request.
Server processes — The backend gRPC server processes the request and responds in native gRPC format. The proxy translates it back to gRPC-Web format for the browser.
Streaming support — gRPC-Web supports server streaming (server sends a stream of messages in response to a single request). However, client streaming and bidirectional streaming are NOT supported in the browser due to HTTP limitations.

8.3 Basic Syntax

// user.proto — Service definition
service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
}

// Client call (using generated stubs)
const request = new GetUserRequest();
request.setId('user-123');

client.getUser(request, {}, (err, response) => {
  console.log(response.getName());
});

8.4 When to Use

Microservices architecture where backend already uses gRPC
Need strongly-typed contracts between frontend and backend
High-performance, low-bandwidth requirements
Internal tools / dashboards

8.5 Pros & Cons

Pros	Cons
Strongly typed (protobuf)	Requires proxy (Envoy)
Compact binary format	Not human-readable (debugging harder)
Code generation	Limited browser support (no bidi streaming)
Server streaming support	Steeper learning curve

8.5 Protocol Buffers (Protobuf) — Deep Dive

Protobuf is the serialization format used by gRPC. It's a binary format that is ~5-10x smaller and ~20-100x faster to parse than JSON.

┌──────────────────────── JSON vs Protobuf ────────────────────┐
│                                                               │
│  JSON (text, 82 bytes):                                       │
│  {"id":"user-123","name":"Alice","email":"a@b.com",│
│   "age":30,"active":true}                                   │
│                                                               │
│  Protobuf (binary, ~28 bytes):                                │
│  0a 08 75 73 65 72 2d 31 32 33 12 05 41 6c 69 63 65 ...     │
│                                                               │
│  Savings: ~66% smaller payload                                │
└───────────────────────────────────────────────────────────────┘

How Protobuf Encoding Works:

message User {
  string id = 1;      // Field number 1 → tag = (1 << 3) | 2 = 0x0a
  string name = 2;    // Field number 2 → tag = (2 << 3) | 2 = 0x12
  string email = 3;   // Field number 3
  int32 age = 4;      // Varint encoding (30 = 0x1e, just 1 byte!)
  bool active = 5;    // 1 byte (0 or 1)
}

Key Protobuf Rules:

Field numbers are forever — Once assigned, never change them (backward compat).
Adding fields is safe — Old clients ignore unknown fields.
Removing fields — Mark as reserved to prevent reuse.
Default values — 0 for numbers, "" for strings, false for bools (not serialized → saves space).

8.6 gRPC Streaming Types

gRPC supports 4 communication patterns:

┌──────────────────────────────────────────────────────────────┐
│                    gRPC Communication Patterns                │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  1. UNARY (Request-Response)                                 │
│     Client ──Request──► Server                               │
│     Client ◄──Response── Server                              │
│     Like a regular REST call.                                │
│                                                              │
│  2. SERVER STREAMING                                         │
│     Client ──Request──► Server                               │
│     Client ◄──Stream──── Server  (multiple responses)        │
│     Example: Stock price feed, log tailing.                  │
│                                                              │
│  3. CLIENT STREAMING                                         │
│     Client ──Stream──► Server  (multiple requests)           │
│     Client ◄──Response── Server                              │
│     Example: File upload, sensor data ingestion.             │
│                                                              │
│  4. BIDIRECTIONAL STREAMING   ⚠️ NOT supported in gRPC-Web  │
│     Client ◄══Stream══► Server  (both sides stream)          │
│     Example: Chat, real-time collaboration.                  │
│                                                              │
└──────────────────────────────────────────────────────────────┘

// All 4 patterns in proto definition
service ChatService {
  rpc GetMessage (GetMessageRequest) returns (Message);                    // Unary
  rpc ListMessages (ListRequest) returns (stream Message);                 // Server streaming
  rpc UploadMessages (stream Message) returns (UploadResponse);           // Client streaming
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);             // Bidirectional
}

// ─── Server Streaming Example (gRPC-Web supported) ───
const stream = client.listMessages(new ListRequest());

stream.on('data', (message) => {
  console.log('Received:', message.getText());
  appendToUI(message);
});

stream.on('status', (status) => {
  console.log('Stream status:', status.code, status.details);
});

stream.on('end', () => {
  console.log('Stream completed');
});

8.7 gRPC-Web vs Native gRPC

Feature	Native gRPC	gRPC-Web
Transport	HTTP/2 (native)	HTTP/1.1 or HTTP/2
Requires proxy	No	Yes (Envoy, grpc-web-proxy)
Unary	✅	✅
Server streaming	✅	✅
Client streaming	✅	❌
Bidi streaming	✅	❌
Browser support	❌ (cannot do raw HTTP/2)	✅
Binary format	Protobuf	Protobuf or base64 text
Used in	Backend-to-backend	Browser-to-backend

Why browsers can't do native gRPC:

Browsers don't expose raw HTTP/2 frames.
fetch() and XMLHttpRequest abstract away the transport layer.
gRPC-Web is a modified protocol that works within browser constraints.

8.8 gRPC Error Handling & Status Codes

// ─── gRPC Status Codes (subset relevant to frontend) ───
const grpcStatusCodes = {
  0:  'OK',                  // Success
  1:  'CANCELLED',           // Client cancelled the request
  2:  'UNKNOWN',             // Unknown error
  3:  'INVALID_ARGUMENT',    // Bad request (like HTTP 400)
  4:  'DEADLINE_EXCEEDED',   // Timeout (like HTTP 408)
  5:  'NOT_FOUND',           // Resource not found (like HTTP 404)
  7:  'PERMISSION_DENIED',   // Forbidden (like HTTP 403)
  13: 'INTERNAL',            // Server error (like HTTP 500)
  14: 'UNAVAILABLE',         // Service unavailable (like HTTP 503)
  16: 'UNAUTHENTICATED',     // Not authenticated (like HTTP 401)
};

// ─── Error Handling in gRPC-Web ───
client.getUser(request, metadata, (err, response) => {
  if (err) {
    switch (err.code) {
      case 3:  // INVALID_ARGUMENT
        showValidationError(err.message);
        break;
      case 14: // UNAVAILABLE
        retryWithBackoff(() => client.getUser(request, metadata, callback));
        break;
      case 16: // UNAUTHENTICATED
        redirectToLogin();
        break;
      default:
        showGenericError(err.message);
    }
    return;
  }
  renderUser(response);
});

8.9 gRPC Interceptors (Middleware)

// ─── Client-side Interceptor for Auth + Logging ───
class AuthInterceptor {
  intercept(request, invoker) {
    // Add auth metadata to every request
    const metadata = request.getMetadata();
    metadata['authorization'] = `Bearer ${getToken()}`;
    metadata['x-request-id'] = crypto.randomUUID();

    const start = performance.now();

    return invoker(request).then((response) => {
      const duration = performance.now() - start;
      console.log(`gRPC ${request.getMethodDescriptor().name}: ${duration}ms`);
      return response;
    }).catch((err) => {
      if (err.code === 16) { // UNAUTHENTICATED
        return refreshToken().then(() => invoker(request)); // retry
      }
      throw err;
    });
  }
}

// Apply interceptor
const client = new UserServiceClient('http://localhost:8080', null, {
  unaryInterceptors: [new AuthInterceptor()],
  streamInterceptors: [new AuthInterceptor()]
});

8.10 gRPC Load Balancing Strategies

┌────────────────────── Proxy-Based (L7) ──────────────────────┐
│                                                               │
│  Browser ──► Envoy Proxy ──► gRPC Server 1                    │
│                          ──► gRPC Server 2                    │
│                          ──► gRPC Server 3                    │
│                                                               │
│  Envoy understands gRPC protocol, can do:                     │
│  • Round-robin / least-connections                             │
│  • gRPC health checking                                       │
│  • Per-RPC load balancing (not per-connection!)                │
│  • Retries with status code awareness                          │
│  • Circuit breaking                                           │
│                                                               │
│  ⚠️ Plain TCP load balancers (L4) fail with gRPC because      │
│  HTTP/2 multiplexes all RPCs over one TCP connection.          │
│  L4 LB sends ALL traffic to one backend!                      │
└───────────────────────────────────────────────────────────────┘

⬆ Back to Top

GraphQL Subscriptions

9.1 What Is It?

GraphQL Subscriptions enable real-time data via GraphQL. Under the hood, they typically use WebSockets (via graphql-ws protocol) to push updates when subscribed data changes.

9.2 How It Works

Client                                Server
  │── Subscribe: subscription {       │
  │     messageAdded(room: "general") │
  │       { id text author }          │
  │   } ─────────────────────────────►│
  │                                    │
  │◄── { messageAdded: {              │  ← push
  │       id: 1, text: "Hi",          │
  │       author: "Alice"             │
  │     }}                             │
  │                                    │
  │◄── { messageAdded: {              │  ← push
  │       id: 2, text: "Hello!",      │
  │       author: "Bob"               │
  │     }}                             │

Transport setup — The client establishes a WebSocket connection to the GraphQL server (using the graphql-ws or older subscriptions-transport-ws protocol). Regular queries/mutations continue over HTTP; only subscriptions use the WebSocket link.
Client subscribes — The client sends a subscription operation (just like a query, but with the subscription keyword). It specifies exactly which fields it wants — GraphQL's power of client-driven data shape applies here too.
Server registers the subscription — The server parses the subscription, validates it against the schema, and registers a listener. Internally, this often hooks into a Pub/Sub system (Redis, Kafka, or in-memory) that watches for relevant events.
Event triggers push — When the subscribed data changes (e.g., a new message is created via a mutation), the server's Pub/Sub system fires an event. The subscription resolver runs, resolves the data into the exact shape the client requested, and pushes it over the WebSocket.
Client receives typed data — The pushed data arrives in the same shape as a normal GraphQL response. It integrates seamlessly with the client's GraphQL cache (e.g., Apollo's InMemoryCache), so the UI updates automatically.
Unsubscribe — The client can stop listening by closing the subscription (or the entire WebSocket connection). The server de-registers the listener and frees resources.

9.3 Basic Syntax

# Subscription definition
subscription OnMessageAdded($room: String!) {
  messageAdded(room: $room) {
    id
    text
    author
    createdAt
  }
}

// Client usage (Apollo)
const { data, loading } = useSubscription(MESSAGE_SUBSCRIPTION, {
  variables: { room: 'general' }
});

9.4 When to Use

When your API is already GraphQL
Real-time features in a GraphQL application
Want subscription data to integrate with GraphQL cache
Type-safe real-time updates

9.5 Pros & Cons

Pros	Cons
Unified API (queries + mutations + subscriptions)	Adds WebSocket complexity
Client specifies exact data shape	Scalability challenges
Integrates with GraphQL cache	Overhead if only subscriptions are needed
Type-safe with codegen

⬆ Back to Top

Microservice Communication Patterns

How do microservices talk to each other — and how does the frontend fit into the picture?

10.1 Overview: Synchronous vs Asynchronous

┌────────────────────────────────────────────────────────────────────┐
│           Microservice Communication Spectrum                      │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  SYNCHRONOUS (Request-Response)      ASYNCHRONOUS (Event-Driven)  │
│  ─────────────────────────────      ────────────────────────────   │
│  • REST (HTTP/JSON)                 • Message Queues (RabbitMQ)    │
│  • gRPC (HTTP/2 + Protobuf)         • Event Streams (Kafka)        │
│  • GraphQL                          • Pub/Sub (Redis, NATS)        │
│  • WebSocket (real-time sync)       • Webhooks                     │
│                                                                    │
│  Caller WAITS for response          Caller sends & moves on        │
│  Tight coupling in time             Loose coupling                 │
│  Simpler to reason about            Better fault isolation         │
│  Cascading failures possible        Eventual consistency            │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

10.2 REST vs gRPC vs GraphQL — Inter-Service Communication

Aspect	REST	gRPC	GraphQL
Format	JSON (text)	Protobuf (binary)	JSON (text)
Transport	HTTP/1.1 or HTTP/2	HTTP/2 (native)	HTTP (any version)
Contract	OpenAPI/Swagger	`.proto` files	Schema (SDL)
Code generation	Optional (OpenAPI codegen)	Built-in (protoc)	Built-in (codegen)
Streaming	No (use SSE/WS)	4 types (unary, server, client, bidi)	Subscriptions (WS)
Payload size	Large (verbose keys)	Small (binary, no keys)	Medium (query-shaped)
Browser support	✅ Native	❌ Needs proxy (gRPC-Web)	✅ Native
Best for	Public APIs, CRUD	Internal microservices	Frontend-facing APIs
Latency	Medium	Low	Medium
Learning curve	Low	Medium-High	Medium

┌──────────────────── Typical Architecture ───────────────────┐
│                                                              │
│   Browser/App                                                │
│      │                                                       │
│      │ REST / GraphQL / gRPC-Web                             │
│      ▼                                                       │
│   ┌──────────────┐                                           │
│   │  API Gateway  │  (or BFF — Backend for Frontend)         │
│   │  / BFF        │                                          │
│   └──────┬───────┘                                           │
│          │                                                   │
│     ┌────┼──────────────┐                                    │
│     │    │              │                                    │
│     ▼    ▼              ▼                                    │
│   ┌────┐ ┌────┐  ┌──────────┐                                │
│   │Svc │ │Svc │  │  Svc C   │     Between services:          │
│   │ A  │ │ B  │  │          │     • gRPC (fast, typed)       │
│   └────┘ └────┘  └──────────┘     • REST (simple, universal) │
│     │       │          │          • Events (async, decoupled) │
│     └───────┼──────────┘                                     │
│             ▼                                                │
│        Message Broker                                        │
│     (Kafka / RabbitMQ / NATS)                                │
└──────────────────────────────────────────────────────────────┘

10.3 Message Brokers — Async Communication

RabbitMQ (Message Queue)

Producer ──► Exchange ──► Queue ──► Consumer

┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
│ Order    │────►│ Exchange │────►│  Queue   │────►│ Payment  │
│ Service  │     │ (routing)│     │          │     │ Service  │
└──────────┘     └──────────┘     └──────────┘     └──────────┘

Point-to-point: One message → one consumer.
Pub/Sub: One message → multiple queues → multiple consumers.
Message acknowledgment: Consumer confirms processing; unacked messages are redelivered.
Dead letter queue (DLQ): Failed messages go to a separate queue for inspection.
Best for: Task queues, order processing, email sending, reliable delivery.

Apache Kafka (Event Streaming)

Producers ──► Topic (Partitions) ──► Consumer Groups

┌──────────┐      ┌─────────────────────┐      ┌──────────────┐
│ Order    │─────►│ Topic: orders       │─────►│ Payment Svc  │
│ Service  │      │ ┌─P0─┐ ┌─P1─┐ ┌─P2─┐│     │ (Group A)    │
└──────────┘      │ │msg1│ │msg2│ │msg3││      └──────────────┘
┌──────────┐      │ │msg4│ │msg5│ │msg6││      ┌──────────────┐
│ Inventory│─────►│ └────┘ └────┘ └────┘│─────►│ Analytics    │
│ Service  │      └─────────────────────┘      │ (Group B)    │
└──────────┘                                   └──────────────┘

Log-based: Messages are appended to an immutable log, retained for days/weeks.
Consumer groups: Multiple services can read the same topic independently.
Partitions: Enable parallel consumption; ordering guaranteed per partition.
Replay: Consumers can re-read old messages (great for debugging, event sourcing).
Best for: Event sourcing, activity tracking, real-time analytics, high-throughput pipelines.

NATS (Lightweight Pub/Sub)

┌──────────┐    publish     ┌──────┐    subscribe    ┌──────────┐
│ Service A │──────────────►│ NATS │───────────────►│ Service B │
└──────────┘               │      │───────────────►│ Service C │
                            └──────┘                └──────────┘

Ultra-fast: In-memory, no persistence by default (NATS JetStream adds persistence).
At-most-once delivery (core NATS) or at-least-once (JetStream).
Request-Reply: Built-in pattern for synchronous-style calls over async transport.
Best for: IoT, edge computing, lightweight microservices, real-time signaling.

Comparison

Feature	RabbitMQ	Kafka	NATS
Model	Message queue	Event log/stream	Pub/sub
Delivery	At-least-once	At-least-once	At-most-once (core)
Ordering	Per queue	Per partition	No guarantee
Persistence	Until consumed	Configurable retention	Optional (JetStream)
Throughput	~50K msg/s	~1M+ msg/s	~10M+ msg/s
Replay	❌	✅	✅ (JetStream)
Best for	Task queues	Event streaming	Real-time signaling

10.4 API Gateway Pattern

┌────────────────────────────────────────────────────────────────┐
│                        API Gateway                             │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│  Browser ──HTTP──► ┌──────────────┐ ──► User Service (gRPC)   │
│                    │  API Gateway  │ ──► Order Service (gRPC)  │
│  Mobile ──HTTP──►  │              │ ──► Payment Service (REST) │
│                    │  (Kong /     │ ──► Notification (event)   │
│  3rd Party ──────► │   Nginx /    │                            │
│                    │   AWS ALB)   │                            │
│                    └──────────────┘                            │
│                                                                │
│  Responsibilities:                                             │
│  ✅ Request routing (path-based, header-based)                 │
│  ✅ Authentication & authorization (JWT validation)            │
│  ✅ Rate limiting & throttling                                  │
│  ✅ Request/response transformation                             │
│  ✅ Load balancing                                              │
│  ✅ Circuit breaking                                            │
│  ✅ Caching                                                     │
│  ✅ Logging, metrics, tracing                                   │
│  ✅ CORS handling                                               │
│  ✅ SSL termination                                             │
│  ✅ Protocol translation (REST ↔ gRPC)                          │
│                                                                │
└────────────────────────────────────────────────────────────────┘

10.5 BFF (Backend for Frontend) Pattern

┌───────────┐     ┌─────────────┐
│  Web App   │────►│ Web BFF     │──┐
│  (React)   │     │ (GraphQL)   │  │
└───────────┘     └─────────────┘  │
                                    │     ┌────────────┐
┌───────────┐     ┌─────────────┐  ├────►│ User Svc   │
│ Mobile App │────►│ Mobile BFF  │──┤     └────────────┘
│ (iOS/And)  │     │ (REST, slim)│  │     ┌────────────┐
└───────────┘     └─────────────┘  ├────►│ Order Svc  │
                                    │     └────────────┘
┌───────────┐     ┌─────────────┐  │     ┌────────────┐
│  TV App    │────►│ TV BFF      │──┘     │ Product Svc│
│            │     │ (minimal)   │───────►└────────────┘
└───────────┘     └─────────────┘

Why BFF?

Different clients need different data shapes — Web needs rich data; mobile needs slim payloads.
Prevents over-fetching — Each BFF aggregates exactly what its client needs.
Team ownership — The frontend team owns their BFF; they don't depend on a shared API.
Aggregation — BFF calls multiple downstream services and combines responses.

10.6 Service Mesh (Istio / Linkerd)

┌──────────────────────────────────────────────────────────────┐
│                        Service Mesh                           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────────────┐        ┌──────────────────┐            │
│  │  Service A        │        │  Service B        │           │
│  │  ┌─────────────┐ │  mTLS  │  ┌─────────────┐ │           │
│  │  │   App Code   │ │◄═════►│  │   App Code   │ │           │
│  │  └──────┬──────┘ │        │  └──────┬──────┘ │           │
│  │         │        │        │         │        │           │
│  │  ┌──────▼──────┐ │        │  ┌──────▼──────┐ │           │
│  │  │ Sidecar     │ │◄══════►│  │ Sidecar     │ │           │
│  │  │ Proxy       │ │        │  │ Proxy       │ │           │
│  │  │ (Envoy)     │ │        │  │ (Envoy)     │ │           │
│  │  └─────────────┘ │        │  └─────────────┘ │           │
│  └──────────────────┘        └──────────────────┘            │
│                                                              │
│  The app doesn't know about the mesh.                        │
│  Sidecar proxies handle ALL network concerns:                │
│                                                              │
│  • mTLS (mutual TLS) — automatic encryption between services │
│  • Load balancing — intelligent routing                       │
│  • Circuit breaking — stop calling failing services           │
│  • Retries & timeouts — configurable per service              │
│  • Observability — distributed tracing, metrics, access logs  │
│  • Traffic shifting — canary deployments, A/B testing         │
│  • Rate limiting — per-service or global                      │
│                                                              │
│  Control Plane (Istiod):                                      │
│  Manages configuration, pushes policies to all sidecars.      │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Why it matters for frontend:

The frontend developer doesn't interact with the service mesh directly.
But knowing it exists explains why retry/timeout/auth logic is sometimes handled at the infrastructure level rather than in application code.
Service mesh makes gRPC inter-service communication trivial (handles mTLS, discovery, load balancing).

10.7 Event-Driven Architecture (EDA)

┌──────────────────────────────────────────────────────────────────────┐
│                  Event-Driven Architecture                           │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  User places order on Web UI                                         │
│         │                                                            │
│         ▼                                                            │
│  ┌──────────────┐   OrderCreated   ┌──────────────────────────────┐  │
│  │ Order Service │ ───event──────►  │        Event Bus             │  │
│  └──────────────┘                  │  (Kafka / RabbitMQ / NATS)   │  │
│                                     └──────────┬──┬──┬────────────┘  │
│                                                │  │  │               │
│                         ┌──────────────────────┘  │  └───────────┐   │
│                         ▼                         ▼              ▼   │
│                  ┌──────────────┐  ┌──────────────┐  ┌──────────┐   │
│                  │ Payment Svc  │  │ Inventory Svc│  │ Email Svc│   │
│                  │ (charge card)│  │ (reserve qty)│  │ (confirm)│   │
│                  └──────┬───────┘  └──────────────┘  └──────────┘   │
│                         │                                            │
│                         ▼                                            │
│                  PaymentCompleted event ──► more downstream actions   │
│                                                                      │
│  Benefits:                                                           │
│  • Services are DECOUPLED (Order doesn't know about Payment)         │
│  • Easy to ADD new consumers (e.g., add Analytics service)           │
│  • FAULT TOLERANT (if Email is down, message stays in queue)         │
│  • SCALABLE (each service scales independently)                      │
│                                                                      │
│  Challenges:                                                         │
│  • Eventual consistency (not immediate)                              │
│  • Debugging distributed flows is harder                             │
│  • Message ordering can be tricky                                    │
│  • Need idempotent consumers (duplicate messages possible)           │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

10.8 Saga Pattern — Distributed Transactions

In a monolith, a single DB transaction covers everything. In microservices, each service has its own DB. The Saga pattern coordinates multi-service transactions.

┌──────────────── Choreography Saga ─────────────────────────┐
│                                                             │
│  Order Svc ──OrderCreated──► Payment Svc                   │
│                               │                             │
│                          PaymentDone──► Inventory Svc       │
│                                          │                  │
│                                    ItemReserved──► Shipping │
│                                                      │      │
│                                               ShipmentCreated│
│                                                             │
│  If Payment FAILS:                                          │
│  Payment Svc ──PaymentFailed──► Order Svc (cancel order)   │
│                                                             │
│  Each service reacts to events and publishes new events.    │
│  No central coordinator.                                    │
└─────────────────────────────────────────────────────────────┘

┌──────────────── Orchestration Saga ───────────────────────┐
│                                                            │
│  ┌─────────────────┐                                       │
│  │ Saga Orchestrator│ (central coordinator)                │
│  │ (Order Saga)     │                                      │
│  └────────┬────────┘                                       │
│           │                                                │
│           ├──► Step 1: Payment Svc.charge()                │
│           │       ✅ success                                │
│           ├──► Step 2: Inventory Svc.reserve()             │
│           │       ❌ failure                                │
│           ├──► Compensate: Payment Svc.refund()            │
│           └──► Mark saga as FAILED                          │
│                                                            │
│  The orchestrator knows the full workflow and handles       │
│  compensation (rollback) for each failed step.             │
└────────────────────────────────────────────────────────────┘

Approach	Pros	Cons
Choreography	Decoupled, no single point of failure	Hard to track, complex for many steps
Orchestration	Clear workflow, easier to debug	Central coordinator = potential bottleneck

10.9 Circuit Breaker Pattern

┌──────────────── Circuit Breaker States ─────────────────────┐
│                                                              │
│   CLOSED (normal)                                            │
│   ┌────────────────────┐                                     │
│   │ Requests flow       │                                    │
│   │ through normally    │──failure threshold exceeded──┐     │
│   └────────────────────┘                               │     │
│          ▲                                             ▼     │
│          │                                    OPEN (blocked) │
│          │                               ┌─────────────────┐ │
│   success in half-open                   │ ALL requests     │ │
│          │                               │ instantly fail   │ │
│          │                               │ (fail-fast)      │ │
│          │                               └────────┬────────┘ │
│          │                                        │          │
│          │                              timeout elapsed      │
│          │                                        │          │
│          │                                        ▼          │
│   ┌──────┴──────────────┐                 HALF-OPEN          │
│   │ HALF-OPEN            │          ┌─────────────────┐      │
│   │ Allow ONE test req   │◄─────────│ Let a few test  │      │
│   │ If success → CLOSED  │          │ requests through│      │
│   │ If failure → OPEN    │          └─────────────────┘      │
│   └─────────────────────┘                                    │
│                                                              │
└──────────────────────────────────────────────────────────────┘

// ─── Simple Circuit Breaker Implementation ───
class CircuitBreaker {
  constructor(fn, options = {}) {
    this.fn = fn;
    this.failureThreshold = options.failureThreshold ?? 5;
    this.resetTimeout = options.resetTimeout ?? 30000;
    this.state = 'CLOSED';   // CLOSED | OPEN | HALF_OPEN
    this.failureCount = 0;
    this.lastFailureTime = null;
  }

  async call(...args) {
    if (this.state === 'OPEN') {
      if (Date.now() - this.lastFailureTime >= this.resetTimeout) {
        this.state = 'HALF_OPEN'; // try one request
      } else {
        throw new Error('Circuit breaker is OPEN — request blocked');
      }
    }

    try {
      const result = await this.fn(...args);
      this.onSuccess();
      return result;
    } catch (err) {
      this.onFailure();
      throw err;
    }
  }

  onSuccess() {
    this.failureCount = 0;
    this.state = 'CLOSED';
  }

  onFailure() {
    this.failureCount++;
    this.lastFailureTime = Date.now();
    if (this.failureCount >= this.failureThreshold) {
      this.state = 'OPEN';
      console.warn('Circuit breaker OPENED — too many failures');
    }
  }
}

// Usage
const fetchUsers = new CircuitBreaker(
  () => fetch('/api/users').then(r => r.json()),
  { failureThreshold: 3, resetTimeout: 10000 }
);

try {
  const users = await fetchUsers.call();
} catch (err) {
  showFallbackUI(); // graceful degradation
}

10.10 How the Frontend Connects to Microservices

┌──────────────────────────────────────────────────────────────────┐
│              Frontend ↔ Microservice Communication               │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  PATTERN 1: API Gateway (most common)                            │
│  ───────────────────────────────────                             │
│  Frontend ──REST/GraphQL──► API Gateway ──gRPC──► Services       │
│  • Single entry point for all API calls                          │
│  • Gateway handles auth, rate limiting, routing                  │
│  • Frontend doesn't know about individual services               │
│                                                                  │
│  PATTERN 2: BFF (Backend for Frontend)                           │
│  ─────────────────────────────────────                           │
│  Frontend ──GraphQL──► BFF ──gRPC/REST──► Services               │
│  • BFF aggregates data from multiple services                    │
│  • Tailored to frontend needs (no over/under-fetching)           │
│  • Frontend team owns the BFF                                    │
│                                                                  │
│  PATTERN 3: Direct Service Calls (rare, not recommended)         │
│  ────────────────────────────────────────────────────             │
│  Frontend ──REST──► Service A                                    │
│  Frontend ──REST──► Service B                                    │
│  • Tight coupling, CORS issues, no centralized auth              │
│  • Only for very simple architectures                            │
│                                                                  │
│  PATTERN 4: Real-Time Layer                                      │
│  ──────────────────────────                                      │
│  Frontend ──WebSocket──► WS Gateway ──Pub/Sub──► Services        │
│  Frontend ──SSE──► Event Gateway ──Kafka──► Services             │
│  • Separate real-time channel from request-response              │
│  • Gateway subscribes to event bus, pushes to connected clients  │
│                                                                  │
│  PATTERN 5: GraphQL Federation                                   │
│  ─────────────────────────────                                   │
│  Frontend ──GraphQL──► Apollo Gateway ──► Subgraph A (Users)     │
│                                       ──► Subgraph B (Products)  │
│                                       ──► Subgraph C (Orders)    │
│  • Each microservice exposes a GraphQL subgraph                  │
│  • Apollo Router/Gateway composes them into a unified schema     │
│  • Frontend queries one schema, gateway resolves across services │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

10.11 Webhooks — Server-to-Server Push

┌───────────────┐    Event occurs     ┌────────────────────┐
│  Stripe       │ ──POST /webhook───► │  Your Server       │
│  (3rd party)  │    (HTTP callback)  │  (listener endpoint)│
└───────────────┘                     └────────────────────┘

// ─── Webhook Receiver (Express) ───
app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];

  try {
    // Verify signature (prevent forgery)
    const event = stripe.webhooks.constructEvent(req.body, sig, WEBHOOK_SECRET);

    switch (event.type) {
      case 'payment_intent.succeeded':
        handlePaymentSuccess(event.data.object);
        break;
      case 'invoice.payment_failed':
        handlePaymentFailure(event.data.object);
        break;
    }

    res.status(200).json({ received: true }); // ACK quickly
  } catch (err) {
    res.status(400).send(`Webhook Error: ${err.message}`);
  }
});

Webhook Best Practices:

Verify signatures — Always validate webhook payloads to prevent spoofing.
Respond fast (< 5s) — ACK immediately, process asynchronously.
Idempotency — Handle duplicate deliveries (use event ID for dedup).
Retry handling — Webhooks typically retry on 4xx/5xx (exponential backoff).
Dead letter queue — Store failed webhooks for manual inspection.

10.12 Communication Pattern Decision Matrix

Scenario	Recommended Pattern	Why
Frontend fetching user profile	API Gateway + REST/GraphQL	Simple CRUD, request-response
Real-time chat in browser	WebSocket via WS Gateway	Bidirectional, low-latency
Order processing pipeline	Event-driven (Kafka/RabbitMQ)	Async, multi-step, decoupled
Service-to-service data fetch	gRPC	Fast, typed, streaming support
3rd-party payment notification	Webhook	Server-to-server push callback
Live dashboard updates	SSE via Event Gateway	Server-to-client, auto-reconnect
Video call feature	WebRTC (+ signaling server)	P2P media, ultra-low latency
Multi-service data aggregation	BFF or GraphQL Federation	Reduce round trips, tailor responses
Distributed transaction	Saga (choreography/orchestration)	No distributed DB transactions
Prevent cascading failures	Circuit Breaker	Fail-fast, graceful degradation

⬆ Back to Top

Comparison Table

Feature	HTTP	Short Poll	Long Poll	SSE	WebSocket	WebRTC
Direction	Client → Server	Client → Server	Client → Server	Server → Client	Bidirectional	Bidirectional (P2P)
Latency	Per request	Up to interval	Near real-time	Real-time	Real-time	Ultra-low
Connection	Short-lived	Short-lived	Medium-lived	Long-lived	Long-lived	Long-lived (P2P)
Protocol	HTTP	HTTP	HTTP	HTTP	WS (TCP)	UDP/TCP
Binary Data	✅	✅	✅	❌ (text only)	✅	✅
Auto-reconnect	N/A	N/A	Manual	✅ Built-in	❌ Manual	❌ Manual
Browser Support	Universal	Universal	Universal	Modern (IE❌)	Modern	Modern
Max Connections	6/domain (H1)	6/domain (H1)	6/domain (H1)	6/domain (H1)	No HTTP limit	No HTTP limit
Scalability	★★★★★	★★★☆☆	★★★☆☆	★★★★☆	★★★☆☆	★★★★★ (P2P)
Complexity	★☆☆☆☆	★☆☆☆☆	★★☆☆☆	★★☆☆☆	★★★☆☆	★★★★★
Server Cost	Low	Medium-High	High	Medium	High	Low (P2P)

⬆ Back to Top

Decision Flowchart Which Protocol to Pick

                    Start
                      │
                      ▼
             Need real-time data?
            /                    \
          No                     Yes
          │                       │
          ▼                       ▼
     Use HTTP/REST          Need bidirectional?
     or GraphQL             /                \
                          No                  Yes
                          │                    │
                          ▼                    ▼
                   Server → Client        Need media/P2P?
                   only?                  /              \
                  /        \            No               Yes
                Yes         No          │                 │
                │           │           ▼                 ▼
                ▼           ▼       WebSocket           WebRTC
          Can use SSE?    Use Long
         /           \    Polling
       Yes            No
        │              │
        ▼              ▼
       SSE         Long Polling

  ┌─────────────────────────────────────────────┐
  │  Quick Rules:                                │
  │                                              │
  │  • CRUD / one-time data → HTTP               │
  │  • Dashboard refresh → Short Polling         │
  │  • Notifications, feeds → SSE                │
  │  • Chat, collaboration → WebSocket           │
  │  • Video call → WebRTC                       │
  │  • Already on GraphQL → GraphQL Subscriptions│
  └─────────────────────────────────────────────┘

⬆ Back to Top

Real World Architecture Examples

12.1 Chat App (WhatsApp Web / Slack)

┌──────────┐    WebSocket     ┌──────────────┐     Pub/Sub      ┌───────┐
│  Browser  │◄══════════════►│  WS Gateway   │◄═══════════════►│ Redis  │
│  (React)  │                │  (Load Bal.)  │                  │ Pub/Sub│
└──────────┘                 └──────────────┘                  └───────┘
                                    │                               │
                              ┌─────▼─────┐                  ┌─────▼─────┐
                              │  Message   │                  │ Presence  │
                              │  Service   │                  │  Service  │
                              └───────────┘                  └───────────┘

Why WebSocket? Bidirectional: users send AND receive messages. Typing indicators, read receipts all need server push + client push.

12.2 Live Score Dashboard

┌──────────┐      SSE        ┌──────────────┐
│  Browser  │◄════════════════│  Score API    │◄── Score Feed
│  (React)  │                │  Server       │
└──────────┘                 └──────────────┘

Why SSE? Unidirectional: server pushes scores. Client only reads. Auto-reconnection is a bonus.

12.3 Google Docs (Collaborative Editing)

┌────────┐  WebSocket  ┌────────────┐  CRDT/OT   ┌──────────┐
│ User A  │◄══════════►│  Collab     │◄══════════►│    DB    │
│ Browser │            │  Server     │            └──────────┘
└────────┘            └────────────┘
┌────────┐  WebSocket       ▲
│ User B  │◄════════════════┘
│ Browser │
└────────┘

Why WebSocket? Both users send edits AND receive others' edits in real-time. OT/CRDT operations need bidirectional, low-latency channel.

12.4 Uber / Ride Tracking

                           ┌──────────────┐
  Driver App ──HTTP POST──►│  Location    │
  (GPS updates)            │  Ingestion   │
                           │  Service     │
                           └──────┬───────┘
                                  │
                           ┌──────▼───────┐
  Rider App ◄─── SSE/WS ──│  Tracking    │
  (map updates)            │  Service     │
                           └──────────────┘

Why SSE for rider? Rider only receives location updates (unidirectional). Driver sends via HTTP POST (infrequent, bursty).

⬆ Back to Top

Interview Questions and Answers

Q1: What's the difference between WebSocket and SSE?

Aspect	SSE	WebSocket
Direction	Server → Client only	Full-duplex (both ways)
Protocol	HTTP	Separate WS protocol over TCP
Data format	Text only	Text + Binary
Reconnection	Automatic (built-in)	Manual implementation needed
Browser API	`EventSource`	`WebSocket`
Use case	Notifications, live feeds	Chat, gaming, collaboration

Key insight: Use SSE when you only need server-to-client push (simpler). Use WebSocket when you need bidirectional communication.

Q2: How would you scale WebSocket connections?

Sticky sessions — Use load balancer (IP hash / cookie) to route a client to the same server.
Pub/Sub layer — Use Redis Pub/Sub, Kafka, or NATS so that any server can broadcast to any client.
Horizontal scaling — Each WS server handles N connections. Add more servers behind the load balancer.
Connection limits — A single server can handle ~10K-100K WebSocket connections (tune OS: file descriptors, memory).
Dedicated WS gateway — Separate WebSocket handling from business logic.

Q3: What happens if a WebSocket connection drops?

The onclose event fires on the client.
You must implement manual reconnection with:
- Exponential backoff — 1s → 2s → 4s → 8s → ... to avoid thundering herd.
- Jitter — Add random delay to prevent all clients reconnecting simultaneously.
- Message queue — Buffer unsent messages during disconnection.
- Last event ID — Track the last received message to resume from where you left off.
- Max retries — Give up after N attempts and show an error UI.

Q4: Explain the WebSocket handshake.

Client sends an HTTP GET with Upgrade: websocket header and a random Sec-WebSocket-Key.
Server responds with 101 Switching Protocols and a Sec-WebSocket-Accept (computed from the client's key + a magic GUID).
This proves the server understands WebSocket.
After this, the connection switches from HTTP to the WebSocket frame-based protocol.

Q5: How does SSE handle reconnection?

EventSource has built-in auto-reconnection.
When the connection drops, the browser waits (default 3s, configurable via retry: field) and reconnects.
On reconnection, the browser sends the Last-Event-ID header with the last received id: value.
The server can use this ID to resume from where the client left off, avoiding duplicate or lost events.
This makes SSE more reliable out-of-the-box than WebSocket for server-push scenarios.

Q6: When would you choose Long Polling over WebSocket?

Proxy/firewall restrictions — Some corporate networks block WebSocket upgrades. Long Polling works on plain HTTP.
Simplicity — No special server infrastructure needed; any HTTP server works.
Low-frequency updates — If updates are infrequent (once every few seconds), the overhead of maintaining a WebSocket connection isn't justified.
Legacy compatibility — Older systems that can't support WS.
Fallback — Libraries like Socket.IO use Long Polling as a fallback when WebSocket fails.

Q7: What is the "thundering herd" problem and how do you avoid it?

When a server goes down, all connected clients (thousands) detect the disconnection simultaneously and try to reconnect at the same time → overwhelming the server.

Solutions:

Exponential backoff — Each retry waits longer: delay = baseDelay * 2^attempt
Jitter — Add random delay: delay = baseDelay * 2^attempt + random(0, 1000)
Max backoff cap — Don't exceed a maximum (e.g., 30s)
Connection admission control — Server rejects excess connections with 503 Retry-After

Q8: How would you implement real-time notifications in a large-scale app?

┌────────┐   SSE/WS    ┌────────────┐    Subscribe    ┌───────┐
│ Client  │◄════════════│ Notif.     │◄════════════════│ Redis  │
│ Browser │             │ Gateway    │                  │ Pub/Sub│
└────────┘             └────────────┘                 └───────┘
                                                          ▲
                        ┌────────────┐    Publish          │
                        │ Any Backend │═══════════════════►│
                        │ Service     │
                        └────────────┘

Key decisions:

SSE if notifications are server → client only (simpler)
WebSocket if user can mark-as-read or interact in real-time
Use Redis Pub/Sub for cross-server broadcasting
Fallback to Short Polling for environments where SSE/WS fail
Store notifications in DB for offline users (pull on reconnect)
Use Service Workers for push notifications when app is closed

Q9: Compare HTTP/2 Server Push vs SSE vs WebSocket.

Feature	HTTP/2 Server Push	SSE	WebSocket
Purpose	Push assets (CSS, JS)	Push events/data	Bidirectional messaging
Initiated by	Server (with request)	Server (after subscribe)	Either side
Use case	Asset preloading	Live data feeds	Chat, games
Client control	No (server decides)	Yes (EventSource)	Yes (send/receive)
Status	Deprecated in Chrome	Active & supported	Active & supported

Note: HTTP/2 Server Push was designed for assets, not application data. It has been removed from Chrome (2022) due to low real-world benefit. Don't confuse it with SSE.

Q10: How do you handle authentication with WebSocket?

Option	Approach	Trade-off
Token in URL	`new WebSocket('wss://...?token=jwt')`	Simple but token leaks in logs/history
Cookie-based	Cookies sent automatically during handshake	Works with existing session auth
Auth after connect	First message = `{ type: 'auth', token }`	Recommended; server closes if invalid
Ticket-based	Get one-time ticket via HTTP, connect with ticket	Most secure; short TTL, single use

Q11: What is the difference between STUN and TURN in WebRTC?

Answer:

STUN helps a peer discover its own public IP and port by asking a STUN server. It's lightweight and free. Once the public address is known, the two peers attempt a direct P2P connection.
TURN acts as a relay server. If direct connection fails (symmetric NAT, strict firewall), both peers send data to the TURN server, which forwards it to the other peer.
ICE orchestrates the process: it gathers candidates from host, STUN (srflx), and TURN (relay), then tests pairs to find the best working path.
Key insight: ~85% of connections succeed with STUN alone. TURN is the expensive fallback that always works.

Q12: How do microservices communicate with each other?

Answer:

Microservices use a combination of synchronous and asynchronous communication:

Synchronous (request-response):
- gRPC — Preferred for internal communication (binary, typed, fast, streaming).
- REST — Universal, simple, good for public-facing APIs.
- GraphQL — Good when frontend needs flexible queries across services.
Asynchronous (event-driven):
- Message queues (RabbitMQ) — Point-to-point task processing.
- Event streams (Kafka) — Pub/sub with replay capability.
- Pub/Sub (NATS, Redis) — Lightweight real-time event distribution.
Patterns:
- API Gateway — Single entry point routing requests to services.
- BFF — Per-client backend that aggregates microservice data.
- Service Mesh (Istio) — Infrastructure-level networking (mTLS, retries, observability).
- Saga — Distributed transaction coordination.
- Circuit Breaker — Prevent cascading failures.

Q13: When would you use gRPC over REST for microservices?

Answer:

Use gRPC when...	Use REST when...
Internal service-to-service calls	Public-facing APIs
High throughput / low latency needed	Human-readable debugging needed
Strong typing and contracts matter	Simplicity is prioritized
Streaming (server, client, bidi) needed	Browser clients (without proxy)
Polyglot microservices (codegen for any lang)	Wide ecosystem tooling needed

Key insight: Many architectures use BOTH — REST/GraphQL for external (browser-facing) traffic and gRPC for internal inter-service calls.

Q14: Explain the Saga pattern for distributed transactions.

Answer:

In microservices, you can't use a single DB transaction across services. The Saga pattern breaks a transaction into a sequence of local transactions, each with a compensating action (rollback).

Example: E-commerce order flow:

Order Service → Create order (compensate: cancel order)
Payment Service → Charge card (compensate: refund)
Inventory Service → Reserve stock (compensate: release stock)
Shipping Service → Create shipment (compensate: cancel shipment)

If step 3 fails, the saga runs compensations in reverse: refund card → cancel order.

Two approaches:

Choreography: Services react to events (decoupled, but hard to track).
Orchestration: A central saga coordinator drives the flow (easier to debug).

Q15: What is a Service Mesh, and why does it matter for frontend engineers?

Answer:

A service mesh (e.g., Istio, Linkerd) adds a sidecar proxy (like Envoy) alongside each microservice to handle networking concerns transparently:

mTLS — Automatic encryption between services.
Load balancing — Intelligent, per-request routing.
Retries & circuit breaking — Resilience without code changes.
Observability — Distributed tracing, metrics.

Frontend relevance: When you wonder why your API calls have retries, timeouts, or auth "built in" without explicit code — a service mesh may be handling it at the infrastructure level. Understanding this helps in debugging latency and failure scenarios.

Bonus: Quick One-Liners for Interviews

Question	Answer
WebSocket port?	Same as HTTP: 80 (ws://) and 443 (wss://)
SSE max connections?	6 per domain on HTTP/1.1, unlimited on HTTP/2
WebSocket frame overhead?	2-14 bytes (vs HTTP headers ~200-800 bytes)
Can SSE send binary?	No, text only. Use base64 encoding as workaround.
Socket.IO = WebSocket?	No. Socket.IO is a library that CAN use WebSocket but also falls back to Long Polling. It adds rooms, acknowledgements, broadcasting.
Is WebSocket RESTful?	No. WS is stateful and doesn't follow REST principles.
gRPC vs REST?	gRPC: binary (protobuf), typed, streaming. REST: text (JSON), flexible, simpler.
WebRTC need server?	Yes, for signaling. Data transfer is P2P after connection.
STUN vs TURN?	STUN discovers public IP (lightweight). TURN relays data (expensive fallback).
SFU vs MCU?	SFU forwards streams (low CPU). MCU mixes streams into one (high CPU).
Kafka vs RabbitMQ?	Kafka: event log with replay. RabbitMQ: traditional message queue.
What is a BFF?	Backend for Frontend — a per-client API layer that aggregates microservice data.
Circuit breaker?	Stops calling a failing service after N failures. Retries after a timeout.

Interview Tip: When asked "How would you build X in real-time?", structure your answer as:

Identify the data flow — unidirectional or bidirectional?

Pick the protocol — SSE for server push, WS for bidirectional, Short Poll as fallback

Address scaling — Pub/Sub layer, sticky sessions, horizontal scaling

Handle failures — Reconnection strategy, message buffering, offline support

Security — Auth mechanism, rate limiting, origin validation

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Micro Frontends, Monolith vs MFE

ZeeshanAli-0704 — Sat, 14 Mar 2026 11:57:58 +0000

Micro Frontends, Module Federation and Cross Communication

A guide to Monolithic vs Micro Frontend architectures, composition strategies, cross-MFE communication patterns, and Webpack Module Federation — focused on when to use what and why.

Monolithic Frontend Architecture
What Are Micro Frontends
Monolith vs Micro Frontend Tradeoffs
MFE Integration Composition Approaches
Hosting Multiple MFEs Under One UI
Cross Communication Between MFEs
Module Federation Deep Dive
Module Federation 2.0
Shared Dependencies and Versioning
Routing in Micro Frontends
Deployment and CI CD
Real World Examples
Decision Flowchart
Key Takeaways ⬆ Back to Top

Monolithic Frontend Architecture

A monolithic frontend is a single, unified codebase where every page, feature, and route lives together. One team (or multiple teams in the same repo) builds, tests, and deploys the entire application as a single unit.

┌──────────────────────────────────────────────────┐
│                Monolithic SPA                     │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
│  │  Auth     │  │  Product │  │  Cart    │        │
│  │  Module   │  │  Catalog │  │  Module  │        │
│  └──────────┘  └──────────┘  └──────────┘        │
│                                                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
│  │  Search   │  │  Profile │  │  Orders  │        │
│  │  Module   │  │  Module  │  │  Module  │        │
│  └──────────┘  └──────────┘  └──────────┘        │
│                                                   │
│     Single Build  →  Single Bundle  →  Deploy     │
└──────────────────────────────────────────────────┘

Aspect	Detail
Codebase	Single repository, single build pipeline
Deployment	All-or-nothing deploy for every change
Team Coupling	High — every team touches the same code
Bundle Size	Grows linearly with features (mitigated by code-splitting)
Consistency	Natural — shared design system, shared state

Build & Deploy Cycle

Developer A (Auth)  ──┐
Developer B (Cart)  ──┼──>  Single Repo  ──>  CI Pipeline
Developer C (Search)──┘    (merge to main)       │
                                                  ▼
                                        Lint + Test (ALL code)
                                                  │
                                                  ▼
                                         Build (Entire App)
                                                  │
                                                  ▼
                                      Deploy (All or Nothing)

Developer A's one-line auth fix must wait for Developer B's half-finished cart feature to be merged or reverted.

When Monolith Works Well

Small-to-medium app with 1–3 teams
Features are tightly coupled (e.g., dashboard where every widget shares state)
Your org doesn't need independent deployment cadences
Early-stage products where speed of iteration matters most

Monoliths are not bad — they are the correct starting point. The problems only emerge at organizational scale, not application scale. A well-structured monolith with lazy routes and code-splitting can serve a product for years. Most of the benefits attributed to MFEs can be partially achieved within a well-structured monolith: lazy loading, monorepo tooling (Nx, Turborepo), and CODEOWNERS files. The one thing a monolith cannot give you is independent deployment.

Rule of thumb: If your team can ship a feature from code review to production in under a day, your monolith is not the bottleneck.

Pain Points at Scale

App grows  →  Build times spike (5–15 min+)
           →  Merge conflicts multiply
           →  One bug blocks entire deploy
           →  Teams step on each other's code
           →  Testing surface explodes

The Coupling Cascade

Nothing prevents cross-module coupling in a monolith. Any file can import any other file. Developers under deadline pressure take shortcuts — import a utility from another module, share a React context, add a field to a shared Redux store. Each shortcut is harmless individually, but collectively they create a web of implicit dependencies that makes independent changes impossible.

Year 1:  Clean modules, fast builds, small team
Year 2:  "Just import that util from the other module"
Year 3:  "We need a shared context for user data"
Year 4:  "Changing the cart broke the search page somehow"
Year 5:  Fear-driven development, massive test suites, 3-week releases

Micro-frontends solve this by creating hard boundaries — separate repos, separate builds, separate deploys. You physically cannot import from another MFE's source code, forcing teams to communicate through explicit contracts.

⬆ Back to Top

What Are Micro Frontends

Micro-frontends extend the microservices idea to the frontend: split a large monolithic UI into independently developed, tested, deployed, and hosted frontend applications that are composed together in the browser to feel like one cohesive product.

"An architectural style where independently deliverable frontend applications are composed into a greater whole." — Martin Fowler

Vertical Slices, Not Horizontal Layers

The most common mistake is thinking of MFEs as horizontal layers (UI team, API team, data team). Instead, MFEs are vertical slices — each team owns an entire feature end-to-end.

  ❌ WRONG: Horizontal Layers         ✅ CORRECT: Vertical Slices

  ┌──────────────────────┐         ┌──────┐  ┌──────┐  ┌──────┐
  │   UI Team            │         │Search│  │Produc│  │ Cart │
  ├──────────────────────┤         │ Team │  │ Team │  │ Team │
  │   API Team           │         │      │  │      │  │      │
  ├──────────────────────┤         │  UI  │  │  UI  │  │  UI  │
  │   Data Team          │         │  API │  │  API │  │  API │
  └──────────────────────┘         │  DB  │  │  DB  │  │  DB  │
                                   └──────┘  └──────┘  └──────┘
  Teams organized by layer          Teams own full features
  → lots of cross-team work         → autonomous delivery

Each MFE owns its own UI, state, routes, and ideally communicates with its own backend microservice. The Search team owns the search UI (React app), search API (Node/Go service), and search database (Elasticsearch). They can ship without coordinating with anyone.

Core Principles

Principle	Meaning
Team Autonomy	Each team owns a vertical slice end-to-end. They can make local decisions without cross-team approval.
Technology Agnostic	Teams can use different frameworks (though most orgs standardize). Mainly useful for incremental migration.
Independent Deployment	Ship your MFE without coordinating with other teams. Each MFE has its own CI/CD. This is the #1 reason companies adopt MFEs.
Isolation	One MFE's crash shouldn't take down others. `ErrorBoundary` around each MFE ensures fault containment.
No Shared State	Prefer explicit contracts (events, APIs, props) over shared global state. Shared state re-introduces the coupling MFEs are meant to solve.

Technology Agnostic sounds appealing but is almost always the wrong default. Running React + Vue means double framework bundles, two tooling sets, and difficulty sharing a design system. The real value is for incremental migration — moving from Angular to React MFE by MFE.

Architecture Overview

                    ┌─────────────────────────────┐
                    │       App Shell / Host       │
                    │  (Routing, Layout, Auth)     │
                    └─────────┬───────────────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                    │
 ┌────────▼──────┐  ┌────────▼──────┐  ┌─────────▼─────┐
 │  MFE: Search   │  │  MFE: Product │  │  MFE: Cart    │
 │  (Team Alpha)  │  │  (Team Beta)  │  │  (Team Gamma) │
 │  React 18      │  │  React 18     │  │  Vue 3        │
 └────────────────┘  └───────────────┘  └───────────────┘
          │                   │                    │
          ▼                   ▼                    ▼
 Independent CI/CD   Independent CI/CD   Independent CI/CD

⬆ Back to Top

Monolith vs Micro Frontend Tradeoffs

Dimension	Monolith	Micro-Frontend
Team scalability	Hard beyond 5–8 devs	Scales to dozens of teams
Deployment	All-or-nothing	Per-MFE independent
Build time	Grows with app size (10–15 min for 500K LoC)	Per-MFE (stays small, ~30 sec)
Technology freedom	Single stack	Mix-and-match (with caution)
UX Consistency	Natural	Requires shared design system
Performance	One optimized bundle	Risk of duplicate deps
Complexity	Low	High (orchestration, contracts, versioning)
Testing	Single E2E suite	Per-MFE + integration layer
Fault isolation	One bug can break all	Bug scoped to one MFE
Shared state	Easy (Redux, context)	Hard (events, props, URL)

The Inflection Point

          Pain / Overhead
          │
 MFE      │        /   Monolith Pain
 Overhead │       /
 ------   │      /
          │     /
 ─────────┼────/──────── ← Crossover point (4-6 teams, 100K+ LoC)
          │   /
          │  /
 MFE Cost │ ──────────── MFE Overhead (relatively flat)
          │
          └────────────────────────>
          1 team    4-6 teams    10+ teams

In a monolith, coordination cost scales O(n²) with team count (every team's changes can conflict with every other's). MFEs reduce this to O(n) because teams only coordinate at well-defined boundaries.

When to Choose MFEs

✅ Large org with 5+ autonomous teams
✅ Teams need different release cadences
✅ Clear domain boundaries (e.g., search, product, cart, checkout)
✅ Need to incrementally migrate a legacy monolith

When NOT to Choose MFEs

❌ Small team (< 5 devs)
❌ Features are heavily coupled with lots of shared state
❌ Org doesn't have DevOps maturity for multiple pipelines
❌ Building a prototype or MVP

Strangler Fig Migration Pattern

Most real-world MFE adoption is gradually migrating a monolith, not greenfield. The Strangler Fig pattern wraps the old system and replaces it piece by piece:

Phase 1:  Monolith serves everything
          ┌────────────────────────────────┐
          │  MONOLITH (Search|Product|Cart) │
          └────────────────────────────────┘

Phase 2:  Add App Shell, extract first MFE
          ┌────────────────────────────────┐
          │           APP SHELL            │
          │  /search  → Search MFE (new)   │
          │  /* else  → Monolith (legacy)  │
          └────────────────────────────────┘

Phase 3:  Extract more MFEs over months
          ┌────────────────────────────────┐
          │           APP SHELL            │
          │  /search  → Search MFE         │
          │  /product → Product MFE        │
          │  /cart    → Cart MFE           │
          │  /* else  → Monolith (shrink)  │
          └────────────────────────────────┘

Phase 4:  Monolith fully decomposed
          ┌────────────────────────────────┐
          │           APP SHELL            │
          │  All routes → dedicated MFEs   │
          │  Monolith is gone ✓            │
          └────────────────────────────────┘

At every phase the system is fully functional. If a new MFE has bugs, route it back to the monolith with a config change. Each phase delivers immediate measurable value — unlike "big bang" rewrites that deliver zero value until 100% complete.

The hardest part is shared authentication and layout. The monolith and new MFEs must share the same login session (via cookies or localStorage tokens) and maintain a consistent header/footer. Build the App Shell and auth integration first.

⬆ Back to Top

MFE Integration Composition Approaches

Composition Spectrum

Build-Time                                             Runtime
(tight coupling,                                (loose coupling,
 best performance)                               more flexibility)
     │                                                  │
     ▼                                                  ▼
┌─────────┐  ┌──────────┐  ┌──────────┐  ┌─────────┐  ┌─────────┐
│   npm   │  │  Module  │  │ JS       │  │  Web    │  │ iframes │
│ packages│  │  Federat-│  │ Dynamic  │  │ Compo-  │  │         │
│         │  │  ion     │  │ Remotes  │  │ nents   │  │         │
└─────────┘  └──────────┘  └──────────┘  └─────────┘  └─────────┘

  Less autonomy                                More autonomy
  Better perf                                  More isolation
  Simpler setup                                More complexity

4.1 Build Time Integration (npm Packages)

MFEs are published as npm packages and the host installs them as dependencies. The host imports and bundles them at compile time.

Pros	Cons
Simple to set up	Loses independent deployment (host must rebuild)
Strong typing across MFEs	Version coupling — lock-step releases
Single optimized bundle	Not truly "micro" — just well-organized monolith

Why this isn't true MFE: Every time the Search team ships a new version, the Host must bump the version, rebuild, run CI/CD, and deploy. The Host becomes a bottleneck. In a 10-team org, the Host could rebuild 5 times a day just to pick up others' changes. Works great for shared component libraries where you want explicit opt-in to new versions, not for independent deployment.

4.2 Runtime Integration via iframes

Each MFE is loaded inside an <iframe>. Each iframe gets a separate browsing context with its own DOM, CSS engine, JS heap, and event loop.

Pros	Cons
Complete isolation (CSS, JS, DOM)	Poor UX (no shared scrolling, awkward resizing)
Technology agnostic	Cross-iframe communication is clunky (`postMessage`)
Security sandbox	Performance overhead (~4x memory for 3 iframes)
	Cannot share dependencies (duplicate React)
	SEO-unfriendly

When to actually use iframes:

Third-party widget embedding (Intercom, payment forms) — you don't control the code
Legacy migration — wrap the old jQuery monolith in an iframe while building new MFEs
Security-critical sections — iframe the payment page so XSS in the main app can't steal card data

4.3 Runtime Integration via JavaScript (Dynamic Remotes)

The host loads each MFE's JS bundle at runtime. Each MFE exports a mount(container) function. This is the pattern Single-SPA popularized.

How it works:

Host App Shell
     │
     ├── Fetch manifest.json → { search: "cdn/.../search.js" }
     │
     ├── <script src="search.js">
     │       └── window.searchMFE.mount(#search-root)
     │
     └── <script src="cart.js">
             └── window.cartMFE.mount(#cart-root)

Lifecycle flow:

Each MFE exports mount(container) and optionally unmount(), bootstrap()
The Host decides when to call them based on routes
Each MFE is framework-agnostic — mount can call ReactDOM.render(), createApp().mount() (Vue), or vanilla DOM
The cleanup function is critical — without proper unmount, you get memory leaks

User navigates to /search:
  Host → fetch search.js → call mount(#search-root) → Search MFE renders

User navigates to /cart:
  Host → call search cleanup() → fetch cart.js → call mount(#cart-root)

Pros	Cons
True independent deployment	Manual dependency management
Each MFE can use different tech	Global namespace pollution risk
Runtime flexibility	No built-in shared dependency dedup

4.4 Runtime Integration via Web Components

Each MFE wraps itself as a Custom Element using the browser-native Web Components API. Shadow DOM provides style isolation without iframe overhead.

Pros	Cons
Framework-agnostic (browser standard)	Shadow DOM CSS isolation can be tricky
Encapsulated via Shadow DOM	Event bubbling across shadow boundaries needs `composed: true`
Native browser API	SSR support is limited
	Passing complex data via attributes is awkward (string-only)

Web Components act as a framework-agnostic wrapper: your React MFE renders inside a custom element's Shadow DOM, and from the host's perspective it's just a <mfe-search> tag. The practical challenge is passing complex data — HTML attributes are strings, so you either serialize to JSON or use JS properties.

4.5 Runtime Integration via Module Federation (Webpack 5)

The most popular modern approach. See Section 7 for the deep dive.

4.6 Server-Side Composition

MFEs are composed on the server before HTML reaches the browser. A composition layer (edge function, CDN, Node.js middleware) fetches HTML fragments from each MFE's SSR service and stitches them into one page.

Browser: GET /product/laptop-123
              │
              ▼
    Composition Server (Edge)
         │         │         │
         ▼         ▼         ▼
    Header SSR  Product SSR  Footer SSR
    (50ms)      (120ms)      (30ms)
         │         │         │
         └─────────┬─────────┘
                   ▼
     Stitched HTML (130ms total) → Browser

Technologies: Podium, Piral, Tailor (Zalando), ESI (Edge Side Includes)

Pros	Cons
Fast FCP (server-rendered)	More complex infrastructure
SEO-friendly	Hydration coordination is hard
No client-side orchestration	Technology mixing is harder

The critical challenge is hydration coordination: each fragment was rendered by a different framework instance. Each MFE must hydrate only its own fragment with separate hydration scripts.

Comparison Matrix

Approach	Indep. Deploy	Isolation	Shared Deps	Performance	Complexity	SEO
npm packages	❌	❌	✅ Natural	✅ Best	Low	✅
iframes	✅	✅ Full	❌ Duplicated	❌ Heavy	Low	❌
JS Dynamic Remotes	✅	⚠️ Partial	⚠️ Manual	⚠️ Depends	Medium	⚠️
Web Components	✅	✅ Shadow DOM	⚠️ Manual	⚠️ Depends	Medium	⚠️
Module Federation	✅	⚠️ Partial	✅ Built-in	✅ Good	Medium-High	⚠️
Server-side	✅	✅ Process	⚠️ Varies	✅ Good FCP	High	✅

Three Underlying Tensions

Don't memorize the table. Understand the three tensions that drive every cell:

Coupling vs Autonomy: Build-time approaches (npm) give tight integration and best performance but sacrifice independent deployment. Runtime approaches (iframes, Module Federation) give full autonomy but add network requests and potential failure points.
Isolation vs Shared Resources: iframes give perfect isolation but zero resource sharing. Module Federation gives shared dependencies but imperfect isolation (MFEs share the same DOM and can accidentally interfere with CSS).
Performance vs Flexibility: Best performance comes from a single optimized bundle. Most flexibility comes from runtime code loading. No approach maximizes both simultaneously.

Practical recommendation: Module Federation for Webpack/Vite + React teams. Server-side composition when SEO is a hard requirement. iframes only for truly untrusted third-party content.

⬆ Back to Top

Hosting Multiple MFEs Under One UI

The key challenge: how do you make 3–10 independently deployed apps feel like one product?

The App Shell Pattern

The App Shell (Host/Container) is a lightweight application responsible for:

Routing — which MFE to load for a given URL
Layout — shared chrome (header, sidebar, footer)
Authentication — auth tokens/context for all MFEs
Loading MFEs — fetching and mounting the correct MFE
Shared Services — analytics, error tracking, feature flags

The shell should be thin and stable — it deploys rarely while MFEs deploy frequently. Think of it like an OS kernel: small, rarely updated. If the shell had significant business logic, it would become a bottleneck.

┌────────────────────────────────────────────────────────┐
│                    App Shell (Host)                    │
│  ┌──────────────────────────────────────────────────┐  │
│  │  Header / Navigation Bar                         │  │
│  └──────────────────────────────────────────────────┘  │
│                                                        │
│  ┌──────────┐  ┌─────────────────────────────────┐     │
│  │          │  │       MFE Content Area          │     │
│  │ Sidebar  │  │                                 │     │
│  │ (shared) │  │  /search  → Search MFE          │     │
│  │          │  │  /product → Product MFE         │     │
│  │          │  │  /cart    → Cart MFE            │     │
│  │          │  │                                 │     │
│  └──────────┘  └─────────────────────────────────┘     │
│                                                        │
│  ┌──────────────────────────────────────────────────┐  │
│  │  Footer                                          │  │
│  └──────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────┘

Hosting Strategies

Strategy	How It Works	When to Use
Separate origins	Each MFE on its own subdomain (`search.myapp.com`)	Max autonomy, separate cloud accounts. Requires CORS config.
Path-based CDN	Same CDN, different prefixes (`cdn.myapp.com/search/`)	Most common. Same-origin = no CORS headaches.
Monorepo deploy	One repo (Nx/Turborepo), each MFE builds/deploys independently	Orgs starting their MFE journey. Shared tooling + independent deploys.
Container registry	Docker containers behind reverse proxy (K8s + Nginx)	Orgs with existing Kubernetes infra.

Discovery Service / Manifest

In production, the host doesn't hardcode MFE URLs. It fetches a manifest at runtime — the same pattern as service discovery in backend microservices (Consul, etcd, K8s DNS).

Hardcoded (bad):
  Host config → "searchApp@cdn/search/v2.3.1/remoteEntry.js"
  Search deploys v2.4.0 → Host still points to v2.3.1!
  Must rebuild + redeploy host ❌

Manifest (good):
  Host fetches "/mfe-manifest.json" → { search: "cdn/search/v2.4.0/..." }
  Search deploys v2.4.0 → Updates manifest only
  Host automatically picks up new version ✓

The manifest enables canary deployments (5% of users see new version), instant rollbacks (update manifest to previous version — no rebuild), A/B testing at MFE level, and an emergency kill switch (revert within CDN cache TTL of ~60 seconds).

Cache strategy: Manifest served with a short TTL (60 seconds) so updates propagate quickly. MFE bundles served with long TTLs (1 year) using content-hashed filenames since they're immutable.

⬆ Back to Top

Cross Communication Between MFEs

One of the hardest MFE problems. MFEs must be independent (no shared imports), yet the UX demands they feel connected (clicking "Add to Cart" in Product MFE should update the cart badge in Cart MFE).

Communication Rules

✘ NEVER:  import { addToCart } from '../cart-mfe/utils';
          (creates build-time dependency)

✘ NEVER:  window.cartMFE.state.items.push(newItem);
          (reaches into another MFE's internal state)

✓ GOOD:   eventBus.emit('cart:add-item', { productId, qty });
          (loose coupling via agreed contract)

✓ GOOD:   <CartMFE items={cartItems} onCheckout={handleCheckout} />
          (props from host — explicit, typed, traceable)

✓ GOOD:   URL: /product/123?addedToCart=true
          (natural, shareable, bookmarkable state)

6.1 Custom Events (DOM Events)

Uses the browser's native CustomEvent API. One MFE dispatches on document, another listens.

Pros	Cons
Zero dependencies, native API	No type safety
Framework agnostic	Easy to create spaghetti event chains
Works across Shadow DOM	Debugging is harder

When to use: 2–3 MFEs with a handful of fire-and-forget notifications like "user logged in" or "item added to cart".

When NOT to use: 10+ event types across 5+ MFEs — you lose track of who's emitting what.

6.2 Pub/Sub Event Bus (Typed)

A lightweight event bus shared across MFEs via a singleton on window. The key improvement over raw CustomEvents is a typed event contract — a single interface that defines all cross-MFE events and their payload shapes.

The MFEEvents interface acts as a shared contract living in a shared package (@org/mfe-contracts). When one team changes a payload shape, TypeScript flags all consumers at build time instead of silently breaking in production.

Without types:  Product emits { productId: '123', qty: 1 }
                Cart expects { quantity: 1 }  ← silent bug in prod!

With types:     MFEEvents['cart:add-item'] = { productId: string; quantity: number }
                Product tries to emit { qty: 1 } → TypeScript error ✅

Pros	Cons
Type-safe with TS interfaces	Debugging event flows needs logging infra
Loose coupling	Events can fail silently if nobody listens
Framework agnostic	Shared contract package needed

Best for: Most MFE architectures. The go-to pattern for peer-to-peer communication.

6.3 Props Down from Host

The host passes data and callbacks to MFEs as props. Explicit, traceable, type-safe with TypeScript.

Pros	Cons
Explicit data flow, easy to debug	Host becomes a bottleneck/middleman
Type-safe with TypeScript	Tight coupling between host and MFE interfaces
Easy to debug	Doesn't scale for many events

Best for: Few MFEs, simple data flow. Auth context, user info, feature flags.

6.4 URL / Query Params

The URL is a natural, framework-agnostic state container. Any MFE can read/write query params. It's bookmarkable, shareable, and survives page refreshes.

Best for: Filter state, search queries, pagination, sort order — any state multiple MFEs need to read and that should survive refresh.

Limits: String-only, publicly visible, ~2000 char limit, can't hold complex nested objects.

6.5 BroadcastChannel API

For cross-tab communication or MFEs in separate iframes. Example: user logs out in one tab → BroadcastChannel notifies all tabs → all redirect to login. Impossible with events or event bus since those only work within a single document.

6.6 Shared Backend / APIs

MFEs don't talk to each other — they share the same backend APIs. Most loosely coupled pattern, but the trade-off is latency (Cart badge won't update instantly on "Add to Cart"). Pair with optimistic UI updates.

Comparison

Pattern	Coupling	Type Safety	Best For
Custom Events	Loose	❌	Simple, few events
Typed Event Bus	Loose	✅	Most MFE architectures
Props from Host	Medium	✅	Few MFEs, simple data
URL/Query Params	Loose	❌	Filters, navigation state
BroadcastChannel	Loose	❌	Cross-tab, iframes
Shared Backend	Loose	N/A	Eventually consistent data

Best Practice: Layer Your Communication

┌────────────────────────────────────────────────────────┐
│  LAYER 1: Props from Host (top-down)                    │
│  Auth token, user profile, theme, feature flags         │
│  Strongest contract — compile-time enforced              │
├────────────────────────────────────────────────────────┤
│  LAYER 2: Typed Event Bus (peer-to-peer)                │
│  'cart:add-item', 'cart:updated', 'search:filter-change'│
│  Medium-strength — typed but runtime-enforced            │
├────────────────────────────────────────────────────────┤
│  LAYER 3: URL State (shared, bookmarkable)              │
│  ?q=laptop&sort=price&page=2                            │
│  Implicit contract — survives refresh, shareable         │
├────────────────────────────────────────────────────────┤
│  LAYER 4: Shared Backend API (eventually consistent)    │
│  Cart count, user preferences, order history            │
│  Loosest contract — persistent data, latency trade-off   │
└────────────────────────────────────────────────────────┘

Anti-pattern: Reaching for the Event Bus when Props would be simpler. If the host already has the data, just pass it as props. Save the event bus for genuinely peer-to-peer interactions.

⬆ Back to Top

Module Federation Deep Dive

What Is Module Federation?

A Webpack 5 feature that lets an app dynamically load code from another independently built and deployed app at runtime while sharing dependencies to avoid duplication. Think of it as runtime npm.

Before Module Federation (pre-2020), choices were: npm packages (loses independent deployment), iframes (terrible UX), or custom script-loading hacks (no dependency sharing). Module Federation was created to solve the shared dependency problem — multiple independent apps sharing React at runtime without duplicating it.

Key Concepts

Concept	What It Is
Host	App that consumes remote modules (the main aggregator)
Remote	App that exposes modules for others to consume
Shared	Dependencies shared between host and remotes to avoid duplication
Container	Runtime entry point (`remoteEntry.js`) the host uses to access a remote's modules
Expose	Declaring which modules a remote makes available (its public API)
Scope	Isolated namespace to avoid conflicts between remotes

Runtime Flow (Step by Step)

This is the critical flow to understand — how code actually loads at runtime:

┌───────────────────────────────────────────────────────────┐
│         Module Federation Runtime Flow                     │
├───────────────────────────────────────────────────────────┤
│                                                            │
│  Step 1: Browser loads Host's index.html + main.js         │
│                    │                                       │
│                    ▼                                       │
│  Step 2: main.js calls import('./bootstrap')               │
│          This creates the ASYNC BOUNDARY                   │
│                    │                                       │
│                    ▼                                       │
│  Step 3: Webpack initializes the sharing scope             │
│          Registers Host's versions: React 18.2             │
│                    │                                       │
│                    ▼                                       │
│  Step 4: User navigates to /search                         │
│          lazy(() => import('searchApp/SearchPage'))         │
│                    │                                       │
│                    ▼                                       │
│  Step 5: Webpack fetches remoteEntry.js (~5KB) from CDN    │
│                    │                                       │
│                    ▼                                       │
│  Step 6: SHARING NEGOTIATION:                              │
│          Remote: "I need React ^18.0.0"                    │
│          Host:   "I have React 18.2.0"                     │
│          18.2 satisfies ^18.0 → Remote reuses Host's React │
│                    │                                       │
│                    ▼                                       │
│  Step 7: container.get('./SearchPage') fetches only        │
│          the SearchPage chunk (~50KB), NOT entire bundle   │
│                    │                                       │
│                    ▼                                       │
│  Step 8: SearchPage renders as a normal React component    │
│          Shared React → hooks, context all work correctly  │
│                                                            │
└───────────────────────────────────────────────────────────┘

Build Time vs Runtime

Build Time:
┌──────────────────────┐     ┌───────────────────────┐
│   Host App            │     │   Remote: Search MFE   │
│                       │     │                        │
│ webpack.config.js:    │     │ webpack.config.js:     │
│  remotes: {           │     │  name: 'searchApp'     │
│    searchApp: '...'   │     │  exposes: {            │
│  }                    │     │    './SearchPage'      │
│  shared: ['react']    │     │  }                     │
│                       │     │  shared: ['react']     │
└──────────────────────┘     └───────────────────────┘

Runtime:
┌──────────────────────┐      ┌───────────────────────┐
│  Host App (browser)   │      │   CDN                  │
│                       │      │                        │
│ 1. User visits /search│      │  searchApp/            │
│ 2. Loads remoteEntry  │─────>│    remoteEntry.js      │
│ 3. Negotiates shared  │      │    src_SearchPage.js   │
│    deps (React)       │      │                        │
│ 4. Downloads only the │<─────│                        │
│    SearchPage chunk   │      │                        │
│ 5. Renders SearchPage │      │                        │
└──────────────────────┘      └───────────────────────┘

The Async Boundary (Critical!)

Module Federation requires an async boundary at the entry point. Without it, shared dependency negotiation fails.

index.js  →  import('./bootstrap')  →  bootstrap.js (actual app code)
          │
          └── This gap is where sharing negotiation happens

Without the async boundary, the host's main entry executes synchronously before the sharing scope is initialized. Remote modules try to resolve react from the sharing scope, find nothing, and either crash with "Shared module is not available for eager consumption" or load their own separate copy (defeating sharing).

The import('./bootstrap') creates an async chunk boundary, giving Webpack time to: (1) parse all remoteEntry.js files, (2) build the sharing scope, (3) resolve version negotiations, (4) then start rendering.

Dynamic Remotes

Instead of hardcoding remote URLs at build time, load them from a manifest at runtime. This enables true independent deployment — the host doesn't need to rebuild when a remote deploys a new version. The flow: inject <script> for remoteEntry.js, call __webpack_init_sharing__, initialize the container, then get the specific module.

Bidirectional Federation

Any app can be both host AND remote simultaneously. App A exposes Header/Footer while consuming ProductCatalog from App B, and vice versa.

When to use: Shared layout components. The Platform team exposes Header/Footer as a remote, but their admin dashboard consumes ProductCatalog from Product MFE.

Caution: Circular dependencies can cascade failures. Keep bi-directional surface area small (shared UI shells, not business logic).

⬆ Back to Top

Module Federation 2.0

MF 1.0 was Webpack-specific, had no type safety, and required Webpack internal hacks for advanced use cases. MF 2.0 decouples the federation runtime from the bundler.

Key Improvements

Feature	MF 1.0	MF 2.0
Bundler support	Webpack only	Webpack, Vite, Rspack, Rollup
Type safety	None	Auto-generated `.d.ts` from remote exports
Manifest	`remoteEntry.js` only	`mf-manifest.json` with metadata
Runtime API	Webpack internals (`__webpack_init_sharing__`)	Clean SDK: `init()` and `loadRemote()`
Versioning	Manual shared config	Automatic negotiation
DevTools	None	Chrome extension for inspecting remotes

The biggest win is type safety. In MF 1.0, import('searchApp/SearchPage') was completely untyped. MF 2.0 generates TypeScript declarations from the remote's actual exports — full autocomplete and compile-time errors.

MF 2.0 uses @module-federation/enhanced as a drop-in replacement for ModuleFederationPlugin. For new projects, start with MF 2.0. For existing MF 1.0 setups, migration is straightforward.

⬆ Back to Top

Shared Dependencies and Versioning

The biggest performance concern in MFEs: duplicate dependencies.

How Sharing Works

Host has React 18.2, Remote has React 18.3 in package.json

Sharing negotiation:
  Remote: "I need React ^18.0.0"
  Host:   "I have React 18.2.0"
  18.2 satisfies ^18.0 → Remote uses Host's React ✅ (ONE copy)

If incompatible:
  Remote: "I need React ^19.0.0"
  Host:   "I have React 18.2.0"
  18.2 does NOT satisfy ^19.0 → Remote loads own React ⚠️ (TWO copies)

Why Duplicate React is Catastrophic

It's not just bundle size — it's a runtime correctness issue. React uses module-level state for its hooks system (fiber tree, hook queue). Two React instances means:

Hooks break: useState registers in one React's registry. If a component renders in another React's tree, you get "Invalid hook call" — the #1 Module Federation debugging nightmare.
Context doesn't work: useContext across different React instances can't share context. A ThemeProvider wrapping the host's React won't provide values to a remote using a different instance.
Events break: React's synthetic event system is per-instance.

This is why singleton: true is mandatory for React, ReactDOM, and any library with module-level state.

Sharing Negotiation Algorithm

Remote requests 'react':
  │
  ├── Is singleton: true?
  │    ├── YES → Host has react in share scope?
  │    │    ├── YES → Host version satisfies requiredVersion?
  │    │    │    ├── YES → ✅ Use Host's version (shared!)
  │    │    │    └── NO  → strictVersion: true?
  │    │    │         ├── YES → 💥 RUNTIME ERROR
  │    │    │         └── NO  → ⚠️ Warning, use Host's anyway
  │    │    └── NO  → Remote loads its own (bad!)
  │    │
  │    └── NO (not singleton) →
  │         Version satisfied? → Share (save bandwidth)
  │         Not satisfied?     → Load own copy (OK for stateless libs)

Version Strategy

Library Type	`singleton`	`strictVersion`	Why
React / ReactDOM	`true`	`false`	Multiple instances break hooks, context, events
State libs (Redux)	`true`	`false`	Need single store
Router	`true`	`false`	Need single history object
Design System	`true`	`false`	Consistent styling
Utility libs (lodash)	`false`	`false`	Stateless — duplication is harmless, just bundle bloat

Organizational Strategy

The most dangerous moment is when one team upgrades React and others haven't. Establish a shared dependency upgrade cadence — all teams upgrade React together once per quarter. The Platform team proposes the version, tests it in staging, and coordinates rollout.

Set strictVersion: false (the default) as a safety net. On version mismatch, Webpack logs a warning but still uses the Host's version. Minor version differences (18.2 vs 18.3) rarely cause real issues. Only use strictVersion: true if a mismatch would cause data corruption.

⬆ Back to Top

Routing in Micro Frontends

Each MFE has its own routes, but the user sees one URL bar.

Routing Delegation Model

URL: /search/results?q=laptop&sort=price
      │        │
      │        └──────────────────┐
      ▼                           ▼
 Host Router                 MFE Router
 matches /search/*           matches /results
 → loads Search MFE          → renders SearchResults

 HOST RESPONSIBILITY:         MFE RESPONSIBILITY:
 - Top-level route matching   - Sub-route matching
 - Loading/unloading MFEs     - Internal navigation
 - Cross-MFE navigation       - Query param management

Approach: Nested Route Delegation

The Host owns top-level routes with wildcard /*. Each MFE owns everything under its prefix:

Host:
  /search/*   → Search MFE
  /product/*  → Product MFE
  /cart/*     → Cart MFE

Search MFE sub-routes:
  /search/          → SearchHome
  /search/results   → SearchResults
  /search/filters   → SearchFilters

The Single Router Rule

If each MFE uses its own BrowserRouter, multiple router instances fight over the URL bar. When Search MFE calls navigate('/cart'), its own router processes it but the Host's router doesn't know — Cart MFE never loads.

Solutions:

MFEs don't have their own router — receive route info as props
Use MemoryRouter for internal navigation (doesn't touch URL bar), delegate cross-MFE navigation to the Host via callback or event bus
Use basename prop and the Host listens for popstate events

Option 2 is the most common in production. The MFE owns internal navigation (tabs, filters) via MemoryRouter. For "leave this MFE" navigation, it fires an event or calls the Host's navigate().

Cross-MFE Navigation

Three options:

window.history.pushState({}, '', '/cart') + dispatch popstate event
eventBus.emit('nav:navigate', { path: '/cart' })
Call props.navigate('/cart') from host-provided callback

Common Routing Bugs

Double router bug: MFE updates URL but Host's router doesn't see it → wrong MFE renders
Back button confusion: MemoryRouter changes don't touch browser history → back button skips MFE-internal navigation
Deep linking failure: MFE doesn't read URL params on mount → shared URLs show default view instead of expected state

Golden rule: The Host owns the URL bar. MFEs can read the URL to initialize state, but should only write through the Host's navigation API.

⬆ Back to Top

Deployment and CI CD

Independent Pipelines

Search MFE:   push → lint → test → build → deploy to CDN → update manifest
Product MFE:  push → lint → test → build → deploy to CDN → update manifest
Host:         push → lint → test → build → deploy (rarely changes)

Each MFE has its own pipeline. The Host shell changes rarely.

Versioning & Rollback

CDN structure:
cdn.myapp.com/search/
  v2.3.0/remoteEntry.js   ← Previous
  v2.3.1/remoteEntry.js   ← Current

Manifest points to current. Rollback = update manifest to previous version.
No rebuild needed. Old bundles stay on CDN.

Rollback comparison:

MFE rollback: Update manifest (one config change, ~60 seconds propagation)
Monolith rollback: Revert interleaved git commits, cherry-pick, rebuild (15 min), redeploy (30–60 min)

Canary deployments: The manifest serves different versions to different user cohorts. Start at 1% traffic, monitor errors, scale to 100% if healthy.

Testing Strategy

Per-MFE: Unit + integration tests in each pipeline (fast, isolated)
Composition testing: Staging environment running latest of every MFE from manifest. Run E2E tests (Playwright) on every MFE deploy. Block manifest update if E2E fails.
Contract testing: Verify cross-MFE event payload shapes. If Product changes cart:add-item payload, Cart's contract test fails before deployment. Use Pact or JSON Schema validation.
Breaking changes: Deploy the consumer first (handles old + new format), then deploy the producer. Same "expand and contract" pattern as database migrations.

⬆ Back to Top

Real World Examples

Every company below adopted MFEs because of an organizational problem, not a technology problem.

Company	Architecture	Why
IKEA	Module Federation + React	30+ country teams need geographic deployment autonomy
Spotify	iframes → Web Components	100+ squads need maximum isolation. Migrating from iframes for better performance.
Zalando	Server-side composition (Tailor)	SEO-critical e-commerce. Streams HTML fragments from multiple services.
Amazon	Server-side + client-side JS	Thousands of engineers. Product details, reviews, recommendations = separate teams.
Banking (Empresas)	Single-SPA + Module Federation	Regulatory compliance. Each product (loans, cards) has different audit cycles.

The pattern: IKEA needed geographic autonomy, Spotify needed squad independence, Zalando needed SEO with team autonomy, Amazon needed thousands of engineers to not step on each other, banking needed regulatory isolation.

If asked "Should we use MFEs?", the right first question is: "What organizational problem are you solving?" If the answer is "slow builds" or "large bundles", solve those within a monolith (code-splitting, CDN caching). If the answer is "teams blocking each other's deployments", that's when MFEs earn their complexity tax.

⬆ Back to Top

Decision Flowchart

Start
  │
  ├── How many teams?
  │     │
  │     ├── 1-3 teams → MONOLITH (with code-splitting)
  │     │                 Lazy routes, good folder structure
  │     │
  │     └── 4+ teams →
  │           │
  │           ├── Clear domain boundaries?
  │           │     │
  │           │     ├── Yes → MICRO-FRONTENDS
  │           │     │          │
  │           │     │          ├── Need framework mixing?
  │           │     │          │     ├── Yes → Web Components / Single-SPA
  │           │     │          │     └── No  → Module Federation
  │           │     │          │
  │           │     │          ├── SEO critical?
  │           │     │          │     ├── Yes → Server-side composition
  │           │     │          │     └── No  → Client-side composition
  │           │     │          │
  │           │     │          └── Legacy migration?
  │           │     │                ├── Yes → iframes → migrate to MF
  │           │     │                └── No  → Module Federation from day 1
  │           │     │
  │           │     └── No (highly coupled) → MONOLITH (monorepo + Nx/Turborepo)
  │           │
  │           └── Not sure → Monolith with CLEAR MODULE BOUNDARIES
  │                          Migrate to MFE when pain points emerge
  └── End

Quick Decision Matrix

Situation	Recommendation
Small app, 1-2 teams	Monolith. MFE overhead far exceeds benefits.
Growing app, 3-5 teams	Monorepo with clear boundaries (Nx/Turborepo). Evaluate MFE.
Large app, 5+ teams, clear domains	Module Federation. Sweet spot for MFE.
Legacy migration	Strangler Fig. iframes first, extract MFEs gradually.
SEO-critical	Server-side composition (Podium / custom SSR).
Third-party widgets	iframes or Web Components. Maximum isolation.
Different tech stacks	Single-SPA or Web Components.

⬆ Back to Top

Key Takeaways

Monolith first. Don't adopt MFE until you feel the pain at organizational scale. MFE is an organizational architecture decision, not a technical one.
Module Federation is the most popular approach for React-based MFEs. It solves the shared dependency problem. Use MF 2.0 for type safety and bundler flexibility (Vite, Rspack).
App Shell is the standard hosting pattern — thin host handles routing, layout, auth. Keep it stable so it rarely redeploys.
Cross-MFE communication should be layered: Props for auth/config, Typed Event Bus for peer-to-peer, URL for filters/navigation, Shared API for persistent data. Never import another MFE's code directly.
Shared singletons (singleton: true for React, Redux, Router) prevent duplicate instances that break hooks, context, and events.
Async boundary (import('./bootstrap')) is mandatory for Module Federation's sharing negotiation to work.
Manifest + CDN enables true independent deployment, instant rollbacks, canary releases, and A/B testing without rebuilding the host.
The right answer to "Should we use MFEs?" is: "It depends on your organization's size, structure, DevOps maturity, and whether monolith pain exceeds MFE overhead."

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Event Handling and Pub/Sub Patterns

ZeeshanAli-0704 — Sat, 14 Mar 2026 11:39:43 +0000

Event Handling and Pub/Sub Patterns, Frontend System Design Guide

Event delegation, bubbling, debounce/throttle, requestIdleCallback, custom event buses, AbortController, and memory leak detection, with theory, simple code, ASCII diagrams, and interview ready answers.

Why Event Handling Matters at Scale
DOM Event Model Capture Target Bubble
Event Delegation The Scalable Pattern
Debounce Throttle requestIdleCallback
Custom Event Bus Pub Sub for Decoupled Communication
AbortController for Cancellable Requests
Memory Leaks Detection Diagnosis and Prevention
Combining Patterns Real World Architectures
Comparison Tables
Interview Questions and Answers
Summary Key Takeaways ⬆ Back to Top

Why Event Handling Matters at Scale

Modern frontend apps handle thousands of events per second: clicks, scrolls, key presses, network responses, resize, intersection observations, web socket messages, etc.

Naive event handling leads to:

Problem	Root Cause
Memory leaks	Listeners not cleaned up on unmount
Layout thrashing	Synchronous DOM reads inside scroll/resize handlers
Dropped frames	Too many handlers firing per frame (> 16ms budget)
Tight coupling	Components directly calling each other
Race conditions	Stale network responses overwriting fresh data
Zombie requests	Navigated away but fetch still in-flight

Good event architecture is the difference between a janky prototype and a production-grade application.

How Events Flow Through a Modern App

 User Interaction (click, scroll, type, etc.)
       │
       ▼
 ┌─────────────┐
 │  DOM Event   │ ◄── Browser fires event → capture → target → bubble phases
 │  Pipeline    │     Delegation catches it on a parent element
 └──────┬──────┘
        │
        ▼
 ┌─────────────┐
 │  Rate Limit  │ ◄── debounce / throttle / rIC decide WHEN to process
 │  Layer       │     Prevents flooding the system with too many calls
 └──────┬──────┘
        │
        ▼
 ┌─────────────┐
 │  Event Bus   │ ◄── pub/sub broadcasts to all interested modules
 │  / Pub-Sub   │     Decouples who PRODUCES events from who CONSUMES them
 └──────┬──────┘
        │
        ▼
 ┌─────────────┐
 │  Async Work  │ ◄── AbortController cancels stale/zombie requests
 │  (fetch/WS)  │     Prevents race conditions & wasted bandwidth
 └─────────────┘

How to read this diagram: A user action enters at the top. Each layer processes or filters the event before passing it down. The DOM layer catches it, the rate-limit layer controls frequency, the event bus broadcasts it to multiple consumers, and the async layer handles network calls with cancellation support. Each layer is independent — you can use any combination.

⬆ Back to Top

DOM Event Model Capture Target Bubble

2.1 The Three Phases

Every DOM event travels through three phases. Think of it like throwing a stone into water — it sinks down (capture), hits the bottom (target), and ripples come back up (bubble).

             Window
               │
       ┌───────┴───────┐
       │   CAPTURE ↓    │  Phase 1: Capturing (top → target)
       │   Document     │  The event travels DOWN from Window
       │      │         │  through each ancestor toward the
       │    <html>      │  target element. Rarely used, but
       │      │         │  useful for intercepting events
       │    <body>      │  before they reach children.
       │      │         │
       │    <div>       │
       │      │         │
       │  ┌───┴───┐     │
       │  │<button>│    │  Phase 2: Target
       │  │ TARGET │    │  The event arrives at the element
       │  └───┬───┘     │  that was actually clicked/interacted
       │      │         │  with. Both capture & bubble handlers
       │   BUBBLE ↑     │  on this element fire here.
       │    <div>       │
       │      │         │  Phase 3: Bubbling (target → top)
       │    <body>      │  The event travels BACK UP to Window.
       │      │         │  This is the default phase and the
       │    <html>      │  basis for EVENT DELEGATION.
       │   Document     │
       └───────┴───────┘
             Window

Why this matters: Event delegation (Section 3) works because of the bubble phase. When you click a <button> deep in the DOM, the event bubbles up through every ancestor — so a listener on a parent <div> can catch clicks on ALL its children.

2.2 Listener Registration

// Bubbling phase (default) — most common
element.addEventListener('click', handler);

// Capture phase — fires BEFORE the target
element.addEventListener('click', handler, { capture: true });

// Full options object
element.addEventListener('click', handler, {
  capture: false,   // Listen during bubble phase
  once: true,       // Auto-remove after first invocation
  passive: true,    // Promise not to call preventDefault()
  signal: controller.signal  // AbortController for removal
});

2.3 `stopPropagation()` vs `stopImmediatePropagation()` vs `preventDefault()`

Method	What It Does	Use When
`stopPropagation()`	Stops event from traveling to parent/child elements	You want to handle the event only at this level
`stopImmediatePropagation()`	Stops propagation AND prevents other handlers on same element	Multiple handlers on same element, only one should fire
`preventDefault()`	Prevents browser's default action (form submit, link navigation)	You want custom behavior instead of default

// stopPropagation — parent won't see the click
child.addEventListener('click', (e) => {
  e.stopPropagation();
  console.log('Only child handles this');
});

// preventDefault — link won't navigate
link.addEventListener('click', (e) => {
  e.preventDefault();
  router.push(link.href); // custom navigation
});

2.4 Passive Listeners, The Scroll Optimization

By default, the browser must wait for touchstart/touchmove/wheel handlers to finish before it knows whether to scroll (the handler might call preventDefault()). This adds latency.

// ❌ Bad — browser waits, scroll feels janky
window.addEventListener('touchstart', handler);

// ✅ Good — browser scrolls immediately (passive = "I won't preventDefault")
window.addEventListener('touchstart', handler, { passive: true });

Chrome, Edge, Firefox make touchstart, touchmove, and wheel listeners on document/window passive by default since 2017. Declaring { passive: true } explicitly is still best practice for clarity.

2.5 Event Properties Cheat Sheet

event.target         // The ACTUAL element that was clicked (innermost)
event.currentTarget  // The element the listener is ATTACHED to
event.type           // 'click', 'keydown', etc.
event.isTrusted      // true = real user action, false = script-dispatched
event.composedPath() // Full path from target to window (crosses Shadow DOM)

⬆ Back to Top

Event Delegation The Scalable Pattern

3.1 The Problem

Imagine a list of 10,000 items. Attaching a listener to each one is expensive:

// ❌ 10,000 listeners — memory & registration overhead
items.forEach(item => {
  item.addEventListener('click', handleItemClick);
});

Items	Listeners	Impact
100	100	Negligible
1,000	1,000	Noticeable
10,000	10,000	Significant
100,000	100,000	🔴 Problematic

3.2 The Solution, Event Delegation

Attach one listener on a common ancestor. The event bubbles up from the clicked child, and you use event.target to figure out which child was clicked.

┌───────────────────────────────────────┐
│ <ul id="list">  ◄── ONE listener here │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐  │
│  │ <li>    │ │ <li>    │ │ <li>    │  │
│  │ Item 1  │ │ Item 2  │ │ Item 3  │  │
│  └─────────┘ └─────────┘ └─────────┘  │
│          ... 10,000 items ...         │
└───────────────────────────────────────┘
       Click on Item 2 bubbles up ↑
       Handled by the single <ul> listener

How it works: Instead of 10,000 listeners on 10,000 <li> elements, you put ONE listener on the <ul>. When any <li> is clicked, the event bubbles up to the <ul>, and your handler checks event.target to know which <li> was clicked.

// ✅ One listener for ALL items (current & future)
const list = document.getElementById('list');

list.addEventListener('click', (e) => {
  const item = e.target.closest('li'); // find the <li> even if user clicked a child inside it
  if (!item) return;                   // click was on <ul> itself
  if (!list.contains(item)) return;    // safety check

  handleItemClick(item.dataset.id);
});

3.3 `closest()`, The Key to Robust Delegation

event.target might be a nested element (e.g., an <svg> icon inside a <button>). Use closest() to walk up and find the real delegate:

container.addEventListener('click', (e) => {
  const btn = e.target.closest('[data-action]');
  if (!btn) return;

  switch (btn.dataset.action) {
    case 'delete': handleDelete(btn); break;
    case 'edit':   handleEdit(btn);   break;
  }
});

3.4 Why Delegation Handles Dynamic Content Automatically

Since the listener is on the parent, any new children added later are automatically covered — the parent listener doesn't care when the child was added, only that the event bubbles up.

3.5 When NOT to Use Delegation

Scenario	Why
`focus`/`blur` events	Don't bubble (use `focusin`/`focusout` instead)
`mouseenter`/`mouseleave`	Don't bubble (use `mouseover`/`mouseout`)
Events on `<canvas>`	No child elements — use coordinates
Single specific element handlers	No performance benefit

3.6 React / Framework Event Delegation

React already uses delegation internally:

React ≤ 16: All events delegated to document
React 17+:  All events delegated to the React root container

You write per-component handlers (onClick), but React attaches a single listener at the root and routes events using its Synthetic Event system. If you use vanilla addEventListener inside useEffect, you must manage delegation yourself.

⬆ Back to Top

Debounce Throttle requestIdleCallback

4.1 Mental Model, The Core Difference

User typing: a-b-c-d-e-f (6 keystrokes in 600ms)
Time:        0  100  200  300  400  500  600  700  800  900

No limiting:  ✓  ✓   ✓   ✓   ✓   ✓         ← 6 calls (wasteful)

Throttle      ✓              ✓              ✓  ← every 300ms (at most)
(300ms):      │              │              │
              fires          fires          fires

Debounce      ×  ×   ×   ×   ×   ✓         ← 1 call (after 300ms quiet)
(300ms):      resets each time       wait 300ms ──┘

rIC:          ····················✓          ← when browser has free time

How to read this diagram:

No limiting: Every keystroke fires the function. 6 keystrokes = 6 API calls. Wasteful.
Throttle (300ms): The function fires on the first call, then ignores subsequent calls until 300ms passes, then fires again. It's like a "rate limit" — at most once per interval.
Debounce (300ms): The timer resets on every keystroke. The function only fires once the user stops for 300ms. It waits for "calm."
requestIdleCallback: Fires whenever the browser has nothing else to do — could be soon or seconds later.

Technique	When It Fires	Best For
Debounce	After N ms of silence	Search input, auto-save, resize end
Throttle	At most once every N ms	Scroll position, mousemove, analytics
requestIdleCallback	When browser is idle	Non-urgent work, analytics, pre-fetching

4.2 Debounce, Wait Until Calm

Debounce delays execution until the user stops triggering the event for a specified period. If the event fires again during the wait, the timer resets.

Without debounce (every keystroke triggers API call):
  Type "react" → 5 API calls:  r, re, rea, reac, react  (4 wasted!)

With debounce (300ms):
  Type "react" → 1 API call:   react  (fires 300ms after last keystroke)

When to use: Anytime you care about the final value, not intermediate ones — search input, auto-save, form validation, window resize end.

Simple Implementation

function debounce(fn, delay) {
  let timerId;
  return function (...args) {
    clearTimeout(timerId);
    timerId = setTimeout(() => fn.apply(this, args), delay);
  };
}

How it works: Every time the returned function is called, it clears the previous timer and starts a new one. The original fn only runs when there's a pause of delay ms.

Usage

// Search input — only call API after user stops typing for 300ms
const input = document.getElementById('search');
const debouncedSearch = debounce((query) => {
  fetch(`/api/search?q=${encodeURIComponent(query)}`)
    .then(res => res.json())
    .then(data => renderResults(data));
}, 300);

input.addEventListener('input', (e) => debouncedSearch(e.target.value));

// Auto-save — save 1 second after user stops editing
const debouncedSave = debounce(saveDocument, 1000);
editor.addEventListener('input', debouncedSave);

// Window resize — recalculate layout after resizing stops
window.addEventListener('resize', debounce(recalculateLayout, 200));

React Hook

function useDebounce(fn, delay) {
  const timerRef = useRef(null);
  const fnRef = useRef(fn);
  fnRef.current = fn;

  useEffect(() => () => clearTimeout(timerRef.current), []);

  return useCallback((...args) => {
    clearTimeout(timerRef.current);
    timerRef.current = setTimeout(() => fnRef.current(...args), delay);
  }, [delay]);
}

// Usage
function SearchBar() {
  const [query, setQuery] = useState('');
  const debouncedFetch = useDebounce((q) => {
    fetch(`/api/search?q=${q}`).then(/* ... */);
  }, 300);

  return <input value={query} onChange={(e) => {
    setQuery(e.target.value);
    debouncedFetch(e.target.value);
  }} />;
}

4.3 Throttle, Rate Limit Execution

Throttle ensures a function is called at most once within a given time window. Unlike debounce, it fires periodically DURING continuous activity.

Scroll events firing at 60fps = ~60 calls/sec

Throttle (200ms):
  Time: 0   50  100  150  200  250  300  350  400
  Fire: ✓                   ✓                   ✓
        │                   │                   │
        fires immediately   fires again         fires again

When to use: Anytime you need periodic updates during continuous activity — scroll position tracking, drag-and-drop, mousemove, analytics event rate-limiting.

Simple Implementation

function throttle(fn, interval) {
  let lastTime = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastTime >= interval) {
      lastTime = now;
      fn.apply(this, args);
    }
  };
}

How it works: Tracks the last execution time. Only allows the function to run if enough time (interval) has passed since the last call.

Usage

// Scroll tracking — check every 200ms whether to load more
const throttledScroll = throttle(() => {
  const { scrollTop, scrollHeight, clientHeight } = document.documentElement;
  if (scrollTop + clientHeight > scrollHeight - 500) loadNextPage();
}, 200);
window.addEventListener('scroll', throttledScroll, { passive: true });

// Analytics — send viewport data at most once per second
const throttledTrack = throttle(() => {
  analytics.track('viewport', { sections: getVisibleSections() });
}, 1000);
window.addEventListener('scroll', throttledTrack, { passive: true });

4.4 Debounce vs Throttle, Decision Guide

                       ┌──────────────────────────┐
                       │ Do you need updates      │
                       │ DURING the burst of      │
                       │ events?                  │
                       └─────────┬────────────────┘
                                 │
                    ┌────────────┼────────────────┐
                    │ YES                          │ NO
                    ▼                              ▼
            ┌───────────────┐              ┌──────────────┐
            │   THROTTLE    │              │   DEBOUNCE   │
            │               │              │              │
            │ • scroll pos  │              │ • search     │
            │ • drag/drop   │              │ • auto-save  │
            │ • game loop   │              │ • resize end │
            │ • analytics   │              │ • validation │
            └───────────────┘              └──────────────┘

How to read: Ask yourself one question — "Do I need feedback WHILE the user is still scrolling/typing/dragging?" If YES → throttle. If NO (you only care about the final value) → debounce.

	Debounce	Throttle
Fires	After silence period	At regular intervals
First call delayed?	Yes	No (fires immediately)
Total calls in burst	1	N / interval
Real-time feel	Delayed response	Immediate, periodic
Good for	Final value	Continuous tracking

4.5 `requestIdleCallback`, Do Work When Browser Is Idle

requestIdleCallback schedules work during browser idle periods — the gaps between frames when the browser has nothing else to do.

Frame Timeline (targeting 60fps = 16.67ms per frame):

│◄── Frame 1 (16.67ms) ──►│◄── Frame 2 (16.67ms) ──►│
│                         │                         │
│ [JS] [Style] [Layout]   │ [JS] [Style]   [IDLE]   │
│ [Paint] [Composite]     │ [Layout] [Paint]        │
│                         │          ▲              │
│ No idle time here       │     rIC fires here      │

How to read: Each frame takes ~16.67ms to hit 60fps. Within each frame, the browser runs JS, calculates styles, does layout, paints. If all that finishes BEFORE 16.67ms, there's idle time left. requestIdleCallback uses that leftover time. If there's no idle time, it waits (or uses the timeout fallback).

When to use: Non-urgent work that shouldn't block user interaction — analytics, pre-fetching, lazy DOM updates.

Syntax

requestIdleCallback((deadline) => {
  // deadline.timeRemaining() → ms left in this idle period
  while (deadline.timeRemaining() > 0) {
    doNextChunkOfWork();
  }
}, { timeout: 2000 }); // Force execution within 2s even if never idle

4.6 Scheduling API Comparison

 High Priority ──────────────────────────────► Low Priority

 ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐
 │  Microtasks  │  │    rAF       │  │     rIC              │
 │  (Promises)  │  │  (next frame │  │  (idle time, may be  │
 │              │  │   ~16ms)     │  │   delayed seconds)   │
 └──────────────┘  └──────────────┘  └──────────────────────┘

How to read: Left = highest priority (runs first). Microtasks (Promises) run immediately after current JS. requestAnimationFrame runs before the next paint (~16ms). requestIdleCallback runs only when the browser is free.

API	When It Fires	Use For
`queueMicrotask()`	After current JS, before next task	Promise-like work, state sync
`requestAnimationFrame`	Before next paint (~16ms)	Animations, visual updates
`setTimeout(fn, 0)`	Next task (≥4ms)	Yielding to event loop
`requestIdleCallback`	Browser idle time	Analytics, prefetch, non-urgent DOM

⬆ Back to Top

Custom Event Bus Pub Sub for Decoupled Communication

5.1 What is Pub/Sub?

Pub/Sub (Publish-Subscribe) is a messaging pattern where:

Publishers emit events without knowing who listens
Subscribers register interest in events without knowing who emits them
An Event Bus is the middleman that routes events from publishers to subscribers

This is the same pattern used by:

Node.js EventEmitter (backend)
Redux (actions dispatched → reducers listen)
DOM Events (element dispatches → listeners catch)
WebSocket message routing
Micro-frontends communication

5.2 The Problem: Tight Coupling

Without Pub/Sub, components must import and call each other directly:

Without Pub/Sub — Spaghetti dependencies:

  ┌────────┐     ┌────────┐     ┌────────┐
  │ Header │────►│  Cart  │────►│ Toast  │
  │        │◄────│        │◄────│        │
  └───┬────┘     └───┬────┘     └───┬────┘
      │              │              │
      └──────────────┼──────────────┘
                     │
                ┌────┴────┐
                │ Product │
                │  Page   │
                └─────────┘

Every component imports and calls every other component.
Adding a new consumer means editing the producer.
Removing a component breaks all components that depend on it.

Why this is bad:

Adding a feature (e.g., "show toast on cart add") requires editing the Cart component
Removing a component (e.g., Toast) breaks Cart and Header
Testing requires mocking all dependencies
Components cannot be reused in other apps without their dependencies

5.3 The Solution: Pub/Sub (Event Bus)

With Pub/Sub — Decoupled communication:

  ┌────────┐  ┌────────┐  ┌────────┐  ┌──────────┐
  │ Header │  │  Cart  │  │ Toast  │  │ Product  │
  └───┬────┘  └───┬────┘  └───┬────┘  └────┬─────┘
      │           │           │            │
  subscribe   subscribe   subscribe     publish
      │           │           │             │
      └───────────┴───────────┴─────────────┘
                       │
               ┌───────┴───────┐
               │   Event Bus   │
               │ ───────────── │
               │ 'cart:add'    │
               │ 'cart:remove' │
               │ 'auth:login'  │
               │ 'theme:change'│
               └───────────────┘

Components know about EVENTS, not about each other.

How to read this diagram: The Product page publishes 'cart:add' to the Event Bus. The Event Bus delivers it to all subscribers — Header (updates count), Cart (adds item), Toast (shows message). No component imports any other component. The Event Bus is the ONLY dependency.

Why this is better:

Adding a feature = just subscribe a new listener. No existing code changes.
Removing a component = just remove its subscription. Nothing else breaks.
Testing = publish a fake event and check the response. No mocking needed.
Reusability = components only depend on the event bus, not on each other.

5.4 How Pub/Sub Works Internally

The Event Bus is essentially a map of event names → arrays of callback functions:

Internal data structure:

  listeners = {
    'cart:add':     [fn1, fn2, fn3],   ← 3 subscribers
    'auth:login':   [fn4],             ← 1 subscriber
    'theme:change': [fn5, fn6],        ← 2 subscribers
  }

When emit('cart:add', data) is called:
  → Loop through [fn1, fn2, fn3] and call each with data

Key operations:

on(event, fn) — Push fn into the array for event
emit(event, data) — Loop through all functions for event and call them with data
off(event, fn) — Remove fn from the array for event

5.5 Minimal Implementation (JavaScript)

class EventBus {
  constructor() {
    this.listeners = {};
  }

  // Subscribe — returns an unsubscribe function
  on(event, handler) {
    if (!this.listeners[event]) this.listeners[event] = [];
    this.listeners[event].push(handler);
    return () => this.off(event, handler);  // cleanup function
  }

  // Subscribe once — auto-removes after first call
  once(event, handler) {
    const wrapper = (data) => {
      this.off(event, wrapper);
      handler(data);
    };
    return this.on(event, wrapper);
  }

  // Unsubscribe
  off(event, handler) {
    if (!this.listeners[event]) return;
    this.listeners[event] = this.listeners[event].filter(h => h !== handler);
  }

  // Publish
  emit(event, data) {
    (this.listeners[event] || []).forEach(handler => {
      try { handler(data); }
      catch (err) { console.error(`EventBus error [${event}]:`, err); }
    });
  }

  // Clear all listeners for an event (or all events)
  clear(event) {
    if (event) delete this.listeners[event];
    else this.listeners = {};
  }
}

// Create a singleton for app-wide use
const eventBus = new EventBus();

5.6 Usage Pattern

// --- In ProductCard component ---
function handleAddToCart(product) {
  eventBus.emit('cart:add', { productId: product.id, quantity: 1 });
}

// --- In CartIcon component ---
const unsubscribe = eventBus.on('cart:add', ({ quantity }) => {
  cartCount += quantity;
  updateCartBadge(cartCount);
});
// Call unsubscribe() on component destroy to prevent memory leaks

// --- In ToastNotification component ---
eventBus.on('cart:add', ({ productId }) => {
  showToast(`Item added to cart!`);
});

// --- In Analytics module ---
eventBus.on('cart:add', (data) => {
  analytics.track('product_added', data);
});

5.7 React Integration

function useEventBus(event, handler) {
  const handlerRef = useRef(handler);
  handlerRef.current = handler;

  useEffect(() => {
    const unsubscribe = eventBus.on(event, (data) => handlerRef.current(data));
    return unsubscribe; // auto-cleanup on unmount
  }, [event]);
}

// Usage
function CartIcon() {
  const [count, setCount] = useState(0);
  useEventBus('cart:add', ({ quantity }) => setCount(prev => prev + quantity));
  useEventBus('cart:clear', () => setCount(0));
  return <span>🛒 {count}</span>;
}

5.8 Native Browser APIs for Pub/Sub

You don't always need a custom EventBus. The browser provides built-in pub/sub mechanisms:

`CustomEvent`, DOM Based Pub/Sub

// Publish
document.dispatchEvent(new CustomEvent('app:theme-change', {
  detail: { theme: 'dark' },
  bubbles: true,
}));

// Subscribe
document.addEventListener('app:theme-change', (e) => {
  applyTheme(e.detail.theme);
});

When to use: Web Components, communicating between components that share a DOM tree.

`BroadcastChannel`, Cross Tab Pub/Sub

// Tab 1: Listen
const channel = new BroadcastChannel('app-events');
channel.addEventListener('message', (e) => {
  if (e.data.type === 'auth:logout') window.location.href = '/login';
});

// Tab 2: Send to all other tabs
const channel2 = new BroadcastChannel('app-events');
channel2.postMessage({ type: 'auth:logout', reason: 'session_expired' });

When to use: Syncing auth state, cart, or theme across multiple tabs of the same origin.

5.9 When to Use What

Pattern	Scope	Best For
In-memory EventBus	Single page / SPA	Cross-component communication
CustomEvent on DOM	DOM tree (bubbles)	Web Component communication
BroadcastChannel	Cross-tab (same origin)	Auth sync, cart sync across tabs
`window.postMessage`	Cross-origin / iframes	Embedded widgets, micro-frontends
`storage` event	Cross-tab (same origin)	Simple cross-tab sync via localStorage
`MessageChannel`	Two specific endpoints	Worker ↔ Worker, port-based

5.10 Common Pitfalls

Pitfall	Solution
Memory leaks — subscribers never removed	Always call `unsubscribe()` on component destroy
Too many events — hard to track data flow	Use namespaced events (`cart:add`, `auth:login`) and centralize event definitions
Silent failures — typos in event names	Define event names as constants in one file
Ordering issues — subscriber added after publisher fires	Use `once()` + replay/cache pattern for initialization events
Debugging difficulty — "where did this event come from?"	Add a `debug: true` flag that logs all events with stack traces

⬆ Back to Top

AbortController for Cancellable Requests

6.1 The Problem: Stale and Zombie Requests

User types "re"    → fetch("/search?q=re")     ─── takes 500ms ──┐
User types "rea"   → fetch("/search?q=rea")    ─── takes 200ms ──┼── arrives FIRST  ✓
User types "react" → fetch("/search?q=react")  ─── takes 100ms ──┼── arrives SECOND
                                                                   │
                                                 "re" result ─────┘── arrives LAST!
                                                 Overwrites "react" result! 🐛

How to read this diagram: The user types "re", "rea", then "react" quickly. Three requests go out. Due to network timing, they come back OUT OF ORDER. The slowest request ("re") arrives last and overwrites the correct "react" result. This is a race condition.

Without cancellation you get:

Race conditions — old responses overwrite new ones (as shown above)
Wasted bandwidth — requests that are no longer needed still consume network
Memory leaks — unmounted components receive callbacks and try to update destroyed UI
Unnecessary server load — server processes requests nobody will use

6.2 What is AbortController?

AbortController is a native browser API that lets you cancel ongoing async operations — fetch requests, event listeners, streams, or any custom async work.

It has two parts:

controller.abort() — call this to trigger cancellation
controller.signal — pass this to the operation you want to make cancellable

┌──────────────────────────────────────────────┐
│                AbortController               │
│                                              │
│  ┌──────────────┐    ┌────────────────────┐  │
│  │   .abort()   │───►│   AbortSignal      │  │
│  │  (trigger)   │    │   .aborted = true  │  │
│  └──────────────┘    │   fires 'abort'    │  │
│                      │   event            │  │
│                      └────────┬───────────┘  │
└───────────────────────────────┼──────────────┘
                                │
           signal passed to:    │
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                  ▼
        ┌──────────┐   ┌──────────────┐   ┌────────────┐
        │  fetch() │   │addEventListener│   │ Any custom │
        │  cancels │   │  auto-removes │   │ async work │
        │  request │   │  listener     │   │            │
        └──────────┘   └──────────────┘   └────────────┘

How to read: You create a controller. You pass its signal to one or more operations. When you call abort(), the signal fires — and every operation watching that signal cancels itself automatically.

6.3 Basic Usage

const controller = new AbortController();

// Pass signal to fetch
fetch('/api/data', { signal: controller.signal })
  .then(res => res.json())
  .then(data => renderData(data))
  .catch(err => {
    if (err.name === 'AbortError') return; // Intentional cancel — not an error
    throw err; // Real error — handle it
  });

// Later — cancel the request
controller.abort();

6.4 Pattern: Cancel Previous Request on New Input (Search)

This is the most common use case — cancel the old request every time the user types a new character:

let controller = null;

async function search(query) {
  controller?.abort();                    // Cancel previous request
  controller = new AbortController();     // Create new controller

  try {
    const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
      signal: controller.signal,
    });
    return await res.json();
  } catch (err) {
    if (err.name === 'AbortError') return null; // Cancelled — ignore
    throw err;
  }
}

input.addEventListener('input', async (e) => {
  const results = await search(e.target.value);
  if (results) renderResults(results);
});

6.5 Built in Timeouts

// Abort if request takes longer than 5 seconds
fetch('/api/data', { signal: AbortSignal.timeout(5000) })
  .catch(err => {
    if (err.name === 'TimeoutError') showToast('Request timed out');
  });

6.6 Combining Signals, User Cancel + Timeout

const userController = new AbortController();

fetch('/api/large-file', {
  signal: AbortSignal.any([
    userController.signal,        // User clicks "Cancel"
    AbortSignal.timeout(10000),   // 10-second timeout
  ]),
});

cancelButton.onclick = () => userController.abort();

6.7 Batch Cleanup of Event Listeners

One of the most powerful uses — remove many listeners with a single abort():

const controller = new AbortController();
const { signal } = controller;

// Register multiple listeners with the same signal
window.addEventListener('resize', handleResize, { signal });
window.addEventListener('scroll', handleScroll, { signal });
document.addEventListener('keydown', handleKeydown, { signal });
document.addEventListener('click', handleClick, { signal });

// ONE call removes ALL four listeners
controller.abort();

This is especially clean in React:

useEffect(() => {
  const controller = new AbortController();
  const { signal } = controller;

  window.addEventListener('resize', handleResize, { signal });
  window.addEventListener('scroll', handleScroll, { signal });

  return () => controller.abort(); // cleanup removes everything
}, []);

6.8 App Level AbortController Strategy

In a real application, you should have a centralized approach to request cancellation rather than managing individual controllers everywhere.

Strategy 1: Route Level Controller

Cancel all in-flight requests when the user navigates to a new page:

// In your router/navigation handler
let routeController = new AbortController();

function onRouteChange(newRoute) {
  routeController.abort();                 // Cancel ALL requests from previous page
  routeController = new AbortController(); // Fresh controller for new page
  renderRoute(newRoute, routeController.signal);
}

// Every fetch in the app uses the route signal
async function fetchUserData(signal) {
  const res = await fetch('/api/user', { signal });
  return res.json();
}

Strategy 2: Fetch Wrapper with Auto Cancellation

Create a wrapper around fetch that your entire app uses:

function createFetchClient() {
  const pendingRequests = new Map();

  return {
    async request(key, url, options = {}) {
      // Cancel previous request with the same key
      pendingRequests.get(key)?.abort();

      const controller = new AbortController();
      pendingRequests.set(key, controller);

      try {
        const res = await fetch(url, { ...options, signal: controller.signal });
        return await res.json();
      } catch (err) {
        if (err.name === 'AbortError') return null;
        throw err;
      } finally {
        pendingRequests.delete(key);
      }
    },

    cancelAll() {
      pendingRequests.forEach(controller => controller.abort());
      pendingRequests.clear();
    },
  };
}

// Usage across the app
const api = createFetchClient();

// Same key = auto-cancels previous call
api.request('user-search', `/api/search?q=${query}`);
api.request('user-search', `/api/search?q=${newQuery}`); // cancels previous

// On logout or route change
api.cancelAll();

Strategy 3: React Hook for Any Component

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    if (!url) return;
    const controller = new AbortController();
    setLoading(true);

    fetch(url, { signal: controller.signal })
      .then(res => res.json())
      .then(json => { setData(json); setLoading(false); })
      .catch(err => {
        if (err.name !== 'AbortError') { setError(err); setLoading(false); }
      });

    return () => controller.abort(); // cleanup on unmount or URL change
  }, [url]);

  return { data, loading, error };
}

6.9 Debounce + AbortController Together (Search Pattern)

The most common real-world pattern — debounce input AND cancel stale requests:

function createSearch(renderResults, delay = 300) {
  let controller = null;
  let timerId = null;

  return function (query) {
    clearTimeout(timerId);      // Reset debounce timer
    controller?.abort();        // Cancel in-flight request

    if (!query.trim()) { renderResults([]); return; }

    timerId = setTimeout(async () => {
      controller = new AbortController();
      try {
        const res = await fetch(`/api/search?q=${encodeURIComponent(query)}`, {
          signal: controller.signal,
        });
        renderResults(await res.json());
      } catch (err) {
        if (err.name !== 'AbortError') console.error('Search failed:', err);
      }
    }, delay);
  };
}

const search = createSearch(renderResults, 300);
document.getElementById('search').addEventListener('input', (e) => search(e.target.value));

⬆ Back to Top

Memory Leaks Detection Diagnosis and Prevention

7.1 What is a Memory Leak?

A memory leak occurs when your application allocates memory that is never released back to the system. The garbage collector cannot free the memory because something still holds a reference to it, even though the data is no longer needed.

Over time, this causes:

Increasing memory usage — the app gets slower and slower
Page crashes — "Aw, Snap!" or "Out of Memory" errors
Poor user experience — especially on long-running SPAs where users don't refresh frequently

7.2 Common Causes of Memory Leaks in Frontend

┌─────────────────────────────────────────────────────┐
│              COMMON MEMORY LEAK SOURCES             │
├─────────────────────────────────────────────────────┤
│                                                     │
│  1. FORGOTTEN EVENT LISTENERS                       │
│     Component unmounts but listener stays on        │
│     window/document, holding references to the      │
│     component's closure and all its variables.      │
│                                                     │
│  2. ORPHANED TIMERS                                 │
│     setInterval / setTimeout keeps running after    │
│     component is destroyed. The callback holds      │
│     references to component state.                  │
│                                                     │
│  3. DETACHED DOM NODES                              │
│     A DOM element is removed from the document      │
│     but a JavaScript variable still references      │
│     it — the element stays in memory.               │
│                                                     │
│  4. CLOSURES HOLDING LARGE DATA                     │
│     An event handler or callback closes over a      │
│     large array/object. Even after the function     │
│     is no longer called, the closure + data stay    │
│     in memory because something references          │
│     the function.                                   │
│                                                     │
│  5. GROWING COLLECTIONS                             │
│     Maps, Sets, arrays that grow but never shrink.  │
│     E.g., an event bus where listeners are added    │
│     but never removed.                              │
│                                                     │
│  6. UNCANCELLED FETCH / PROMISES                    │
│     A fetch resolves after component unmounts and   │
│     calls setState on a destroyed component.        │
│     The promise callback keeps the component        │
│     closure alive.                                  │
│                                                     │
└─────────────────────────────────────────────────────┘

7.3 How to Detect Memory Leaks

Method 1: Chrome DevTools, Performance Monitor

Open DevTools → Performance Monitor (Ctrl+Shift+P → "Show Performance Monitor")
Watch the JS Heap Size graph while using your app
Expected: Memory goes up (work) then comes back down (GC collects)
Leak: Memory keeps going up and NEVER comes back down, even after GC

Normal behavior:                Memory leak:
 Memory                          Memory
  ▲                               ▲
  │    ╱╲   ╱╲   ╱╲               │        ╱
  │  ╱    ╲╱   ╲╱   ╲             │      ╱
  │╱                              │    ╱
  └──────────────────► Time       │  ╱
                                  │╱
  Goes up and comes               └──────────────────► Time
  back down = healthy             Only goes up = LEAK

Method 2: Chrome DevTools, Memory Heap Snapshots

This is the most precise method to identify exactly what is leaking.

Steps:

Open DevTools → Memory tab
Select "Heap Snapshot"
Take Snapshot 1 (baseline)
Perform the action you suspect leaks (e.g., open/close a modal 10 times)
Click the garbage bin icon (force GC)
Take Snapshot 2
In Snapshot 2, change the dropdown from "Summary" to "Comparison" and compare with Snapshot 1
Look for objects with high "Delta" — these are objects that were created but never released

What to look for:

Detached HTMLDivElement → DOM nodes removed from page but still referenced in JS
(closure) → Functions that hold references to destroyed component scope
EventListener → Listeners that were never removed
Large arrays/objects that shouldn't still exist

Method 3: Chrome DevTools, Allocation Timeline

Memory tab → select "Allocation instrumentation on timeline"
Start recording → perform the suspicious action → stop
Look at blue bars — blue bars that remain blue (not turned gray by GC) are potential leaks
Click on persistent blue bars to see what objects were allocated and who retains them

Method 4: `performance.measureUserAgentSpecificMemory()` (Programmatic)

// Programmatically check memory usage (requires cross-origin isolation)
async function checkMemory() {
  if (performance.measureUserAgentSpecificMemory) {
    const result = await performance.measureUserAgentSpecificMemory();
    console.log(`Total memory: ${(result.bytes / 1024 / 1024).toFixed(2)} MB`);
  }
}

Method 5: Monitor Listener Count

// Quick check: are listeners growing over time?
function countListeners() {
  // Check your event bus
  console.log('Event bus listeners:', eventBus.listenerCount?.() || 'N/A');

  // Chrome-only: getEventListeners() in console
  // getEventListeners(document)  — shows all listeners on document
  // getEventListeners(window)    — shows all listeners on window
}

7.4 Leak Free Patterns

Pattern 1: Always Clean Up Listeners

// ❌ LEAK: listener on window never removed
class LeakyWidget {
  constructor() {
    window.addEventListener('resize', this.onResize);
  }
  // No cleanup method!
}

// ✅ SAFE: AbortController removes all listeners
class SafeWidget {
  constructor() {
    this.controller = new AbortController();
    window.addEventListener('resize', this.onResize, { signal: this.controller.signal });
  }
  destroy() {
    this.controller.abort(); // removes ALL listeners
  }
}

Pattern 2: Always Clear Timers

// ❌ LEAK: interval runs forever after component removed
const id = setInterval(pollServer, 5000);

// ✅ SAFE: clear on destroy
const id = setInterval(pollServer, 5000);
// On cleanup:
clearInterval(id);

Pattern 3: Always Unsubscribe from Event Bus

// ❌ LEAK: subscription never removed
eventBus.on('data:update', handleUpdate);

// ✅ SAFE: store unsubscribe and call on destroy
const unsubscribe = eventBus.on('data:update', handleUpdate);
// On cleanup:
unsubscribe();

Pattern 4: Cancel Async Operations

// ❌ LEAK: fetch callback updates destroyed component
fetch('/api/data').then(res => this.setState(res));

// ✅ SAFE: abort on cleanup
const controller = new AbortController();
fetch('/api/data', { signal: controller.signal }).then(/* ... */);
// On cleanup:
controller.abort();

7.5 React Specific Leak Prevention

In React, the useEffect cleanup function is your primary defense:

useEffect(() => {
  const controller = new AbortController();
  const unsubscribe = eventBus.on('update', handleUpdate);
  const intervalId = setInterval(poll, 5000);

  fetch('/api/data', { signal: controller.signal });

  // Cleanup function — runs on unmount and before re-run
  return () => {
    controller.abort();    // Cancel fetch
    unsubscribe();         // Remove event bus listener
    clearInterval(intervalId); // Stop timer
  };
}, []);

7.6 Memory Leak Debugging Checklist

Check	How
Heap keeps growing?	Performance Monitor → watch JS Heap Size
What objects are leaking?	Memory → Heap Snapshot → Comparison view
Who is retaining them?	Click leaked object → "Retainers" panel shows the reference chain
Detached DOM nodes?	Heap Snapshot → Filter "Detached" → shows orphaned elements
Event listeners growing?	Console: `getEventListeners(document)` / `getEventListeners(window)`
Closures holding data?	Heap Snapshot → look for `(closure)` entries with large retained size
After navigation?	Navigate away and back → take snapshots before/after → compare delta

7.7 Performance Budget for Memory

Metric	Budget	How to Stay Within
Event listeners on `window`/`document`	< 20	Use delegation, group with AbortController
Total event bus subscriptions	< 200	Track with `listenerCount()`, warn on threshold
Handlers per scroll event	< 3 throttled	Combine into single throttled handler
Time per event handler	< 5ms	Offload to `requestIdleCallback` or Worker
JS Heap growth per navigation	~0 (should return to baseline)	Heap snapshot comparison after navigating away

⬆ Back to Top

Combining Patterns Real World Architectures

8.1 E Commerce: Cart Events + Delegation + Abort

┌──────────────────────────────────────────────────────┐
│  Product Listing Page                                │
│                                                      │
│  ┌─────────────────────────────────────────────────┐ │
│  │ <div id="products">  ◄── ONE delegated listener │ │
│  │   ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐       │ │
│  │   │Product│ │Product│ │Product│ │Product│       │ │
│  │   │  Card │ │  Card │ │  Card │ │  Card │       │ │
│  │   │ [Add] │ │ [Add] │ │ [Add] │ │ [Add] │       │ │
│  │   └───────┘ └───────┘ └───────┘ └───────┘       │ │
│  └─────────────────┬───────────────────────────────┘ │
│                    │ click event bubbles up          │
│                    ▼                                 │
│            eventBus.emit('cart:add')                 │
│                    │                                 │
│     ┌──────────────┼──────────────┐                  │
│     ▼              ▼              ▼                  │
│  CartIcon      Toast          Analytics              │
│  (updates      (shows         (tracks event          │
│   count)        message)       throttled)            │
└──────────────────────────────────────────────────────┘

How to read: One delegated listener on the product container catches ALL button clicks. It publishes a 'cart:add' event to the event bus. Three independent subscribers react — CartIcon updates the count, Toast shows a notification, Analytics tracks it (throttled to avoid excess). No component knows about any other component.

// 1. Delegated click handler
document.getElementById('products').addEventListener('click', (e) => {
  const btn = e.target.closest('[data-action="add-to-cart"]');
  if (!btn) return;
  eventBus.emit('cart:add', { productId: btn.dataset.productId });
});

// 2. Subscribers (each in their own module)
eventBus.on('cart:add', ({ productId }) => cartService.addItem(productId));
eventBus.on('cart:add', () => toast.show('Added to cart!'));
eventBus.on('cart:add', throttle((data) => analytics.track('cart_add', data), 1000));

8.2 Auto Save Form: Debounce + Abort + Event Bus

let controller = null;

const debouncedSave = debounce(async (formData) => {
  controller?.abort();
  controller = new AbortController();
  eventBus.emit('form:status', { status: 'saving' });

  try {
    await fetch('/api/drafts', {
      method: 'PUT',
      body: JSON.stringify(formData),
      signal: controller.signal,
    });
    eventBus.emit('form:status', { status: 'saved' });
  } catch (err) {
    if (err.name !== 'AbortError') {
      eventBus.emit('form:status', { status: 'error' });
    }
  }
}, 1000);

form.addEventListener('input', () => {
  const data = Object.fromEntries(new FormData(form));
  eventBus.emit('form:status', { status: 'unsaved' });
  debouncedSave(data);
});

⬆ Back to Top

Comparison Tables

Event Rate Limiting Techniques

Feature	Debounce	Throttle	requestIdleCallback	requestAnimationFrame
Fires when	After silence period	At regular intervals	Browser is idle	Before next paint
First call delayed	Yes	No	Yes	Next frame
Use case	Search, auto-save	Scroll, resize	Analytics, prefetch	Animations
Cancel	`clearTimeout`	`clearTimeout`	`cancelIdleCallback()`	`cancelAnimationFrame()`

Communication Patterns

Pattern	Coupling	Scope	Best For
Direct function call	Tight	Same module	Simple parent→child
Props/callbacks (React)	Moderate	Component tree	Parent↔child
Context/Store (Redux)	Moderate	App-wide	Shared state
Event Bus / Pub-Sub	Loose	App-wide	Cross-module events
BroadcastChannel	Loose	Cross-tab	Tab sync

⬆ Back to Top

Interview Questions and Answers

Q1: What is event delegation and why is it useful?

A: Event delegation uses one listener on a parent instead of individual listeners on each child. It leverages event bubbling — when a child is clicked, the event bubbles up to the parent where the handler uses event.target.closest() to identify the target.

Benefits: memory efficiency (one listener, not thousands), handles dynamic content (new children auto-covered), simpler cleanup (one listener to remove).

Q2: `event.target` vs `event.currentTarget`?

event.target → the actual element clicked (the innermost one)
event.currentTarget → the element the listener is attached to

In delegation, currentTarget is the parent, target is the child.

Q3: Debounce vs Throttle?

Debounce: Only care about the final value after activity stops (search input, auto-save)
Throttle: Need periodic updates during continuous activity (scroll, drag, analytics)

Key: Debounce = zero calls during burst (waiting for silence). Throttle = regular calls at intervals.

Q4: How does AbortController prevent race conditions?

A: Each new request calls abort() on the previous controller. The aborted fetch throws AbortError which is caught and ignored. Only the latest request's response is processed.

let controller;
async function search(query) {
  controller?.abort();
  controller = new AbortController();
  try {
    const res = await fetch(`/search?q=${query}`, { signal: controller.signal });
    return await res.json();
  } catch (e) {
    if (e.name === 'AbortError') return null;
    throw e;
  }
}

Q5: Why `{ passive: true }` on scroll/touch?

A: Without it, the browser must wait for the handler to finish before scrolling (handler might call preventDefault()). With passive: true, you promise not to call preventDefault(), so the browser scrolls immediately while the handler runs in parallel.

Q6: How would you detect a memory leak?

Performance Monitor — watch JS Heap Size. Healthy = up and down. Leak = only goes up.
Heap Snapshots — take snapshot before/after an action. Compare view shows objects that were created but never released.
Retainers panel — click a leaked object to see the reference chain holding it in memory.
Filter "Detached" — finds DOM nodes removed from page but still referenced in JS.
getEventListeners() — Chrome console command to count listeners on an element.

Q7: Design a pub/sub system that prevents memory leaks.

Return unsubscribe functions from on() — callers clean up on destroy
Set a maxListeners limit — warn when exceeded (like Node.js EventEmitter)
Use AbortController signals for DOM listeners — one abort() cleanups everything
In React, use a useEventBus hook that auto-unsubscribes on unmount
Add clear() method to remove all listeners for an event

Q8: What is `requestIdleCallback`?

A: Schedules work during browser idle periods — gaps between frames when the browser has no rendering or input to process. Use for non-urgent work: analytics, pre-fetching, lazy computation. Provides deadline.timeRemaining() to check available time. Always use timeout option as a safety net.

Q9: How does React handle events differently from vanilla DOM?

Synthetic Events — cross-browser wrappers around native events
Delegation at root — single listener on root container (React 17+)
Event names normalized (onClick vs onclick)
onFocus/onBlur use focusin/focusout (which bubble)

Q10: Real time dashboard with 100+ WebSocket messages/sec, how?

Throttle DOM updates — batch messages, update UI at most every 100-200ms via requestAnimationFrame
Pub/sub layer between WebSocket and UI — components subscribe to relevant events only
requestIdleCallback for non-critical updates (logging, analytics)
Virtual list for message history — only render visible items
Web Worker for data processing — aggregate in worker, post computed results to main thread

⬆ Back to Top

Summary Key Takeaways

Concept	One-Liner
Event Delegation	One listener on parent + `closest()` to find target — scales to 100K+ items
Passive Listeners	`{ passive: true }` on scroll/touch = instant scrolling, no jank
Debounce	Wait until silence — search, auto-save, resize end
Throttle	Rate-limit — scroll tracking, drag, analytics
requestIdleCallback	Non-urgent background work during browser idle time
Event Bus / Pub-Sub	Decouple producers from consumers — one-to-many communication
AbortController	Cancel fetch, listeners, streams — prevent race conditions & leaks
Memory Leaks	Always clean up listeners, timers, subscriptions. Detect with heap snapshots.
Cleanup	AbortController.abort() + returned unsubscribe functions

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Offline Support and Progressive Web Apps (PWAs)

ZeeshanAli-0704 — Sat, 14 Mar 2026 11:23:37 +0000

Offline Support and Progressive Web Apps (PWAs)

A Complete Frontend System Design Guide - Theory, Patterns and Interview Focus

Modern users expect apps to work everywhere — on flaky Wi-Fi, in subways, on flights, and even completely offline. Progressive Web Apps (PWAs) bridge the gap between web and native apps by delivering installability, offline support, background sync, and push notifications — all through the browser.

This guide focuses on concepts, architecture patterns, trade-offs, and interview-relevant knowledge rather than exhaustive code. Where code appears, it's kept to minimal syntax to illustrate a concept.

What is a Progressive Web App (PWA)
Core PWA Building Blocks
Service Worker Lifecycle Deep Conceptual Understanding
Cache Strategies Deep Dive
Offline First Architecture Patterns
Client Side Storage Comparison and Mental Models
App Shell Architecture
Background Sync Concepts and Patterns
Push Notifications How They Actually Work
Web App Manifest and Installability
Cache Versioning and Update Strategies
Real World Architecture Offline Capable App
Testing and Debugging PWAs
Trade offs Gotchas and Platform Limitations
Decision Frameworks
Interview Questions and Answers
Final Recommendations ⬆ Back to Top

What is a Progressive Web App (PWA)?

A PWA is not a single technology — it's a convergence of capabilities that make a web app behave like a native app. Think of it as a philosophy: progressively enhance a standard website with native-like features.

The Three Pillars

Pillar	What It Provides	Why It Matters
Service Worker	Offline support, caching, background sync, push notifications	The "brain" — a programmable network proxy sitting between your app and the network
Web App Manifest	Installability, splash screen, app icon, standalone mode	The "identity" — makes the browser treat your site as an installable app
HTTPS	Secure context (mandatory for Service Workers)	The "trust layer" — no Service Worker can register without HTTPS

Why PWAs Matter in System Design

Traditional Web App                     PWA
┌─────────────────┐                ┌─────────────────┐
│  Network-only   │                │  Offline-capable │
│  Tab experience │                │  Installable     │
│  No background  │                │  Background sync │
│  No push        │                │  Push-enabled    │
│  Always online  │                │  Resilient       │
└─────────────────┘                └─────────────────┘

Key Insight for Interviews

A PWA doesn't mean "building an offline app." It means designing resilient web experiences that degrade gracefully. Even if you never need full offline support, Service Workers dramatically improve perceived performance through intelligent caching.

Browser Support Landscape

Feature	Chrome	Firefox	Safari	Edge
Service Workers	✅	✅	✅	✅
Cache API	✅	✅	✅	✅
Web App Manifest	✅	✅	✅ (partial)	✅
Background Sync	✅	❌	❌	✅
Push Notifications	✅	✅	✅ (iOS 16.4+)	✅
Periodic Background Sync	✅	❌	❌	✅

Interview takeaway: Background Sync and Periodic Sync are Chromium-only. Always design with fallbacks. Push notifications on iOS only work for installed PWAs since iOS 16.4.

⬆ Back to Top

Core PWA Building Blocks

┌──────────────────────────────────────────────────────────┐
│                       Your Web App                        │
│   ┌─────────┐  ┌───────────┐  ┌────────────────────┐    │
│   │ App     │  │ Web App   │  │ Service Worker     │    │
│   │ Shell   │  │ Manifest  │  │  ┌──────────────┐  │    │
│   │ (HTML/  │  │ (JSON)    │  │  │ Cache API    │  │    │
│   │  CSS/JS)│  │           │  │  │ IndexedDB    │  │    │
│   │         │  │           │  │  │ Background   │  │    │
│   │         │  │           │  │  │   Sync       │  │    │
│   │         │  │           │  │  │ Push API     │  │    │
│   └─────────┘  └───────────┘  │  └──────────────┘  │    │
│                                └────────────────────┘    │
└──────────────────────────────────────────────────────────┘
                          │
                    ┌─────┴──────┐
                    │   HTTPS    │
                    └────────────┘

How These Pieces Relate (Mental Model)

Think of the architecture in layers:

App Shell — The skeleton UI (header, nav, footer) that loads instantly from cache. It's the "frame" of your app, with no data content.
Web App Manifest — A JSON file that tells the browser: "This website can be installed. Here's its name, icon, and how it should look when launched."
Service Worker — A JavaScript file that runs in a separate thread from your main page. It acts as a programmable proxy — every network request your app makes passes through it, and you decide whether to serve from cache, network, or both.
Cache API — A key-value store where keys are HTTP Requests and values are HTTP Responses. Used by the Service Worker to store and retrieve network responses.
IndexedDB — A full client-side database for structured data (objects, arrays, blobs). Used for app data (posts, messages, user profiles) — not HTTP responses.

Key distinction: Cache API stores network responses (Request → Response). IndexedDB stores application data (structured objects). They serve different purposes and are often used together.

⬆ Back to Top

Service Worker Lifecycle Deep Conceptual Understanding

Understanding the lifecycle is the most important concept for interviews. It determines when your cache updates, when old versions are cleaned up, when new features activate, and when bugs can appear.

The Six States

                    ┌──────────┐
                    │ Register │  ← Browser downloads SW file
                    └────┬─────┘
                         │
                    ┌────▼─────┐
                    │ Install  │  ← Precache critical assets here
                    └────┬─────┘
                         │
                    ┌────▼──────┐
                    │ Waiting   │  ← New SW waits for ALL old tabs to close
                    └────┬──────┘
                         │
                    ┌────▼──────┐
                    │ Activate  │  ← Clean old caches here
                    └────┬──────┘
                         │
                    ┌────▼──────┐
                    │  Idle     │  ← Listening for fetch/push/sync events
                    └────┬──────┘
                         │
                    ┌────▼──────────┐
                    │  Terminated   │  ← Browser can kill idle SW to save memory
                    └───────────────┘

Phase by Phase Explanation

1. Registration

Your main page JS calls navigator.serviceWorker.register('/sw.js').
The browser downloads the SW file.
Scope is determined by the SW file's location (or by an explicit scope option). A SW at /sw.js controls the root '/' scope.
Registration should happen after page load to avoid competing for bandwidth.

2. Install

Triggers the install event inside the SW.
This is where you precache your critical assets (app shell, offline fallback page).
If any asset fails to cache, the entire installation fails and the SW goes to a redundant state.
The SW does NOT yet control any pages.

3. Waiting

After install, the new SW enters a waiting state.
Why? Because the old SW is still controlling open tabs. Activating the new SW would create inconsistencies (old HTML + new SW logic).
The new SW will activate only when all tabs controlled by the old SW are closed.

4. Activate

Triggers the activate event inside the SW.
This is where you clean up old caches (delete caches from previous versions).
After activation, the SW is ready to intercept requests — but only for new navigations. Existing tabs that were open during activation won't be controlled unless you call clients.claim().

5. Idle / Fetch

The SW sits idle, waiting for events: fetch, push, sync, message.
Every network request from controlled pages triggers the fetch event — you decide the response source.

6. Terminated

The browser can kill an idle SW at any time to free memory.
It will be restarted when the next relevant event occurs.
This means: never store state in SW global variables — use IndexedDB or Cache API instead.

The Update Problem `skipWaiting` vs Controlled Updates

This is a very common interview topic:

Approach	How It Works	Use When
Default (no skipWaiting)	New SW waits until all old tabs close	Safest — no version mismatch between HTML and SW
`skipWaiting()` + `clients.claim()`	New SW activates immediately and takes over all open tabs	Non-breaking cache changes (e.g., adding new images to precache)
Prompt-based update	Show "Update available" banner, user clicks to reload	Best UX for production apps with breaking changes

Why `skipWaiting()` Can Be Dangerous

Imagine: User has Tab A open with v1 HTML. You deploy v2 which changes the API response format. If the new SW skipWaiting()s:

Tab A is now controlled by the v2 Service Worker
But it's still rendering v1 HTML/JS — which expects the old API format
Result: broken app

The safe pattern: Detect the update, show a banner ("New version available — click to refresh"), and only skipWaiting() when the user explicitly chooses to update.

// Minimal syntax — Prompt-based update pattern
// In main.js: listen for 'updatefound' on registration
// When new SW is 'installed' but old SW is active → show banner
// On user click → postMessage({ type: 'SKIP_WAITING' }) to new SW
// In sw.js: listen for message → call self.skipWaiting()
// In main.js: listen for 'controllerchange' → window.location.reload()

Key Mental Model

Think of the Service Worker as a shared singleton that runs per-origin, not per-tab. All tabs on the same origin share one active SW. That's why the "waiting" phase exists — you can't swap the singleton while old tabs depend on it.

⬆ Back to Top

Cache Strategies Deep Dive

The Cache API is a key-value store for Request → Response pairs. Service Workers intercept fetch events and decide how to respond: from cache, from network, or both.

Strategy Overview

┌─────────────────────────────────────────────────────────────────┐
│                     Cache Strategies                             │
│                                                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────────────────┐ │
│  │ Cache First  │  │Network First │  │ Stale-While-          │ │
│  │ (Cache,      │  │(Network,     │  │   Revalidate          │ │
│  │  fallback    │  │ fallback     │  │ (Cache + Background   │ │
│  │  network)    │  │ cache)       │  │   Network Update)     │ │
│  └──────────────┘  └──────────────┘  └───────────────────────┘ │
│                                                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌───────────────────────┐ │
│  │ Network Only │  │ Cache Only   │  │ Race (Cache vs        │ │
│  │              │  │              │  │   Network)             │ │
│  └──────────────┘  └──────────────┘  └───────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

1. Cache First (Cache Falling Back to Network)

Best for: Static assets that rarely change — CSS bundles, JS bundles (with content hashes), images, fonts.

Request → Check Cache → HIT?  → Return cached response
                      → MISS? → Fetch from network → Store in cache → Return

How it works conceptually:

The SW checks the Cache API first. If found, it returns immediately — zero network latency.
On a miss, it fetches from the network, stores the response in cache for next time, and returns.
The response must be cloned before caching because the Response body is a stream that can only be consumed once.

Trade-offs:
| Pros | Cons |
|---|---|
| Fastest possible response | Serves stale content until SW is updated |
| Works fully offline | Must version caches or use hashed filenames |
| Lowest bandwidth usage | Stale-forever risk if cache cleanup is neglected |

When to use: Versioned, hashed assets like app.a1b2c3.js, font files, icons. These files are immutable per version.

2. Network First (Network Falling Back to Cache)

Best for: Dynamic content that should be fresh — API responses, HTML pages, dashboards.

Request → Fetch from network → SUCCESS? → Store in cache → Return
                              → FAIL?    → Return cached (offline fallback)

How it works conceptually:

Always try the network first for the freshest data.
If the network succeeds, update the cache and return the response.
If the network fails (offline, timeout), fall back to whatever is cached.
Optionally add a network timeout — if the network takes more than N seconds, fall back to cache immediately.

Trade-offs:
| Pros | Cons |
|---|---|
| Always shows freshest data when online | Slower — always incurs network latency |
| Graceful offline fallback | Uses more bandwidth than cache-first |
| Simple mental model | Cold cache on first visit = slow |

When to use: News feeds, user profiles, search results, HTML pages.

Interview insight: Adding a networkTimeoutSeconds parameter makes this strategy more resilient — if the network is slow (not offline), you still get a fast response from cache rather than waiting.

3. Stale While Revalidate (SWR)

Best for: Semi-dynamic content where instant load matters but eventual freshness is acceptable.

Request → Check Cache → HIT?  → Return cached (stale) IMMEDIATELY
                              → ALSO fire network request in background
                              → Update cache with fresh response

                      → MISS? → Fetch from network → Store in cache → Return

How it works conceptually:

Returns the cached (potentially stale) version instantly for a fast user experience.
Simultaneously fetches from the network in the background.
Updates the cache with the new response so the next request will get fresh data.
Optionally, the SW can notify the page via postMessage() that new data is available so the UI can refresh.

Trade-offs:
| Pros | Cons |
|---|---|
| Instant load + eventual freshness | User briefly sees stale data |
| Works offline (serves stale) | Complexity in notifying UI of updates |
| Best perceived performance for repeat visits | Two requests per navigation (cache + network) |

When to use: Social feeds, product listings, user avatars, recommendations, non-critical API data.

Interview insight: SWR is the most commonly used strategy in real production PWAs. It's a great balance between performance and freshness. React's useSWR hook and TanStack Query share similar philosophy at the application layer.

4. Network Only

Best for: Requests that must never be cached — auth tokens, payment processing, analytics.

Request → Fetch from network → Return (no caching at all)

When to use: /api/auth, /api/checkout, /analytics, CSRF token endpoints. Caching these could lead to security vulnerabilities or stale authentication states.

5. Cache Only

Best for: Precached assets that are guaranteed to be in cache from the install step.

Request → Return from cache (no network fallback)

When to use: Assets that were precached during the SW install event. Only works if you're certain the asset is in cache.

6. Race (Cache vs Network)

Best for: When you want the absolute fastest response regardless of source.

Request → Fire both cache lookup AND network fetch simultaneously
        → Return whichever resolves first

When to use: Latency-critical requests where both cached and fresh content are acceptable. Rarely used in practice because it wastes bandwidth.

Strategy Decision Matrix (Interview Ready)

Strategy	Speed	Freshness	Offline	Best For
Cache First	⚡ Instant	❌ Stale until SW update	✅ Full	Static assets (JS, CSS, images)
Network First	🐢 Network-dependent	✅ Always fresh online	✅ Fallback	Dynamic content, HTML pages
Stale-While-Revalidate	⚡ Instant	🔄 Eventually fresh	✅ Stale	Feeds, listings, avatars
Network Only	🐢 Network-dependent	✅ Always fresh	❌ None	Auth, checkout, analytics
Cache Only	⚡ Instant	❌ Fixed	✅ Full	Precached app shell assets
Race	⚡ Fastest wins	🔄 Depends	✅ Partial	Latency-critical requests

The Router Pattern (Combining Strategies)

In production, you never use a single strategy. You build a router that maps request types to strategies:

Request Type	Strategy	Why
HTML navigation (`request.mode === 'navigate'`)	Network First	Need fresh page content, cache as fallback
Static assets (`.js`, `.css`, `.woff2` with hashes)	Cache First	Immutable per version — hash changes on update
API calls (`/api/*`)	Stale-While-Revalidate	Fast load + background refresh
Auth/payment endpoints	Network Only	Never cache sensitive data
Precached app shell assets	Cache Only	Guaranteed to be cached from install
User-uploaded images / CDN assets	Cache First + expiration	Cache with size and age limits

// Conceptual router pattern (minimal syntax)
self.addEventListener('fetch', (event) => {
  if (event.request.mode === 'navigate')      → networkFirst()
  if (isStaticAsset(url))                      → cacheFirst()
  if (url.startsWith('/api/auth'))             → networkOnly()
  if (url.startsWith('/api/'))                 → staleWhileRevalidate()
  // default                                   → networkFirst()
});

⬆ Back to Top

Offline First Architecture Patterns

What is Offline First?

Offline-first means your app is designed to work offline by default and sync when connectivity returns — rather than treating offline as an error state.

Traditional Approach              Offline-First Approach
─────────────────────           ─────────────────────────
1. Fetch data from server        1. Read from local store (IndexedDB)
2. If offline → show error       2. Render UI immediately
3. User waits or retries         3. Sync with server in background
                                 4. Merge changes when online

The Four Core Principles

Local-first reads — Always read from local storage (IndexedDB), never from the network for initial render. The network is used for sync, not reads.
Optimistic writes — Write to local storage immediately, show the result to the user, and queue the mutation for server sync. The UI should never wait for the network.
Background sync — Push queued mutations to the server when connectivity returns. Use the Background Sync API where available, or fall back to online/offline event listeners.
Conflict resolution — When the same data is modified on multiple devices while offline, you need a strategy to reconcile divergent states.

Architecture Diagram

┌─────────────────────────────────────────────┐
│                  UI Layer                   │
│          (React, Vue, Angular, etc.)        │
└──────────────────┬──────────────────────────┘
                   │ read/write
┌──────────────────▼──────────────────────────┐
│            Data Access Layer                │
│  ┌──────────────────────────────────────┐   │
│  │         Local Store (IndexedDB)      │   │
│  │  ┌──────────┐  ┌──────────────────┐  │   │
│  │  │ Data     │  │ Mutation Queue   │  │   │
│  │  │ Store    │  │ (pending syncs)  │  │   │
│  │  └──────────┘  └──────────────────┘  │   │
│  └──────────────────────────────────────┘   │
│                    │                        │
│            ┌───────▼────────┐               │
│            │  Sync Engine   │               │
│            │  (online/      │               │
│            │   offline      │               │
│            │   aware)       │               │
│            └───────┬────────┘               │
└────────────────────┼────────────────────────┘
                     │
              ┌──────▼──────┐
              │   Network   │
              │   (REST /   │
              │    GraphQL) │
              └─────────────┘

Data Flow Pattern for Offline First Writes

The critical pattern to understand (and explain in interviews):

User performs an action (e.g., creates a post, sends a message)
Write to IndexedDB immediately — assign a clientId (UUID), set syncStatus: 'pending'
Update UI instantly — the user sees their action reflected with an optimistic indicator (e.g., a clock icon, "Sending...")
Queue the mutation — add to a separate syncQueue object store in IndexedDB, containing the operation type (CREATE/UPDATE/DELETE), the data, and a timestamp
If online → process the queue immediately:
- POST/PUT/DELETE to the server
- On success: update syncStatus to 'synced', remove from queue
- On failure: leave in queue for retry
If offline → register a Background Sync event (or just wait for online event)
When connectivity returns → process the entire queue in FIFO order

Conflict Resolution Strategies

When the same record is modified offline on multiple devices, you need a merge strategy:

Strategy	How It Works	Best For	Complexity
Last Write Wins (LWW)	Highest `updatedAt` timestamp wins, losing changes are discarded	Simple apps, user settings, profiles	Low
Server Wins	Server version always takes priority over client changes	Admin-controlled data, configurations	Low
Client Wins	Client version always takes priority	Very rare — draft-only editing scenarios	Low
Field-Level Merge	Compare each field individually; only conflicting fields need resolution	Form-based data, structured records	Medium
Manual Merge	Show both versions to the user, let them choose or combine	Documents, collaborative editing	Medium
CRDTs	Conflict-free Replicated Data Types — mathematically guaranteed to merge without conflicts	Real-time collab (Figma, Notion, Linear)	High
Operational Transforms (OT)	Transform concurrent operations based on order and context	Google Docs, real-time text editing	Very High

When Interviewers Ask About Conflict Resolution

The LWW (Last Write Wins) approach is sufficient for 80% of use cases. Mention it first, then discuss CRDTs/OT for collaborative scenarios:

LWW — Simple timestamp comparison. Works great for settings, profiles, single-user data.
Field-level merge — Compare a "base" version (before offline edits) with both local and server versions. Fields changed by only one side auto-resolve; fields changed by both sides require a policy (default to server, flag for user review).
CRDTs — Special data structures (G-Counter, LWW-Register, OR-Set) that are designed to be merged from any direction without conflicts. Growing in adoption (Yjs, Automerge libraries).

⬆ Back to Top

Client Side Storage Comparison and Mental Models

The Storage Landscape

Storage	Max Size	Sync/Async	Data Format	Accessible From	Best Use Case
Cookies	~4 KB	Sync	String (key=value)	Server + Client	Auth tokens, server-readable preferences
localStorage	~5 MB	Sync (blocks main thread!)	String only	Main thread only	Small settings, theme preference, simple flags
sessionStorage	~5 MB	Sync	String only	Main thread (tab-only)	Tab-specific temp data, wizard step state
IndexedDB	50 MB – GBs	Async (non-blocking)	JS objects, blobs, arrays	Main thread + Service Worker	App data, offline storage, large datasets
Cache API	Generous (varies)	Async	Request → Response pairs	Main thread + Service Worker	HTTP response caching for Service Workers

Why IndexedDB is the Answer for Offline Apps

Asynchronous — won't block the main thread (unlike localStorage)
Structured data — stores JavaScript objects directly (no JSON.stringify)
Indexed queries — create indexes for fast lookups by field
Large capacity — can store gigabytes of data
Transaction-based — ACID-compliant operations (atomic, consistent, isolated, durable)
Available in Service Workers — unlike localStorage, IndexedDB can be used during background sync and push handling

The localStorage Trap (Interview Red Flag)

Never use localStorage for offline app data. It's synchronous (blocks the main thread), limited to 5 MB, stores only strings (requiring serialization), and is not accessible from Service Workers. It's fine for a theme toggle — not for a data store.

IndexedDB Mental Model

Think of IndexedDB as a NoSQL database in the browser:

Database → one per app/feature (you can have multiple)
Object Store → like a "collection" or "table" (e.g., posts, messages, syncQueue)
Index → like a "secondary key" for fast lookups (e.g., index on category, syncStatus)
Transaction → all reads/writes happen inside a transaction (readonly or readwrite)
Cursor → for iterating over records (like a database cursor)

// Minimal syntax — the essential pattern
const db = indexedDB.open('my-app', 1);
// onupgradeneeded → create object stores and indexes
// onsuccess → start read/write transactions
// transaction('posts', 'readwrite') → objectStore.put(data)
// transaction('posts', 'readonly')  → objectStore.get(key) or getAll()

Tip: Raw IndexedDB is verbose and callback-based. In production, use the idb library (by Jake Archibald) — a tiny Promise wrapper that makes IndexedDB much cleaner to use.

Storage Quotas and Eviction

How much can you store?

Chrome: Up to 80% of total disk space per origin
Firefox: Up to 50% of total disk space
Safari: ~1 GB, but can be evicted aggressively

What is eviction?

When the browser runs low on disk space, it may delete stored data (Cache API, IndexedDB) from origins.
Eviction follows LRU (Least Recently Used) — least-used origins are evicted first.

How to protect against eviction:

Call navigator.storage.persist() — requests the browser to treat your storage as persistent (won't be evicted).
Chrome auto-grants persistent storage for installed PWAs, bookmarked sites, or sites with push permissions.
Always call navigator.storage.estimate() to check available quota before storing large data.

⬆ Back to Top

App Shell Architecture

What is the App Shell?

The App Shell is the minimal HTML, CSS, and JavaScript required to render the structural UI — the navigation bar, sidebar, footer, and loading states — without any dynamic content data.

┌──────────────────────────────────────────┐
│  ┌──────────────────────────────────┐    │
│  │         Header / Navbar          │    │  ← App Shell (cached)
│  └──────────────────────────────────┘    │
│  ┌────────┐  ┌───────────────────┐       │
│  │        │  │                   │       │
│  │ Side   │  │    Content Area   │       │  ← Dynamic content
│  │ Nav    │  │    (loaded from   │       │    (fetched at runtime
│  │        │  │     network or    │       │     from API / IndexedDB)
│  │        │  │     IndexedDB)    │       │
│  │        │  │                   │       │
│  └────────┘  └───────────────────┘       │
│  ┌──────────────────────────────────┐    │
│  │           Footer / Tab Bar       │    │  ← App Shell (cached)
│  └──────────────────────────────────┘    │
└──────────────────────────────────────────┘

How It Works (Flow)

First Visit:
Browser → Server → Full page (HTML + CSS + JS)
→ Service Worker installs → Precaches the app shell assets

Repeat Visits:
Browser → Service Worker → Serves app shell from cache INSTANTLY (< 100ms)
→ JavaScript fetches content data from API or IndexedDB
→ Content fills the skeleton

Why It Matters

Without App Shell	With App Shell
White screen until entire page loads	Instant structural UI from cache
Offline = blank page	Offline = app frame + cached/local data
FCP depends on network	FCP is near-instant on repeat visits
No separation of shell vs content	Clean architecture boundary

App Shell in Framework Terms

Modern frameworks implement the App Shell concept naturally:

Framework Concept	App Shell Equivalent
`layout.tsx` / `_layout.vue`	The shell — nav, sidebar, footer
`page.tsx` / route components	Dynamic content that fills the shell
`loading.tsx` / `Suspense` fallback	Skeleton screens while content loads
`error.tsx` / Error boundaries	Error states within the shell

Interview Ready Explanation

"The App Shell pattern separates your UI into two parts: the shell (structural chrome that's the same on every page) and the content (data-driven portions that change). The shell is precached during Service Worker install, giving users instant repeat loads. Content is loaded dynamically from the API or IndexedDB. Even offline, users see the full app frame — not a blank page."

⬆ Back to Top

Background Sync Concepts and Patterns

The Problem It Solves

User submits a form, sends a message, or likes a post — but they're on a flaky connection. Without Background Sync, that action fails silently or shows an error. With Background Sync, the action is queued locally and automatically retried when connectivity returns.

How Background Sync Works (Conceptual Flow)

User Action (offline)
    │
    ▼
Save to IndexedDB  →  Register sync event  →  User can close the tab
                                                     │
                              ┌───────────────────────┘
                              │ (later, when online)
                              ▼
                     Service Worker wakes up
                              │
                              ▼
                     Read pending actions from IndexedDB
                              │
                              ▼
                     POST/PUT/DELETE to server
                              │
                    ┌─────────┴────────┐
                    │                  │
                 Success            Failure
                    │                  │
                    ▼                  ▼
              Remove from         Re-throw error
              IndexedDB           (browser retries
                                   automatically)

Key Concepts

Tag-based registration — You register a sync with a string tag ('send-messages'). If you register the same tag multiple times before it fires, it coalesces into a single sync event.
Automatic retry — If the sync event handler throws an error, the browser will automatically retry with exponential backoff. You don't manage retries yourself.
Survives tab close — This is the key advantage over a simple online event listener. Background Sync fires even if the user has closed all tabs. The Service Worker wakes up to handle it.
IndexedDB as the queue — You must store pending actions in IndexedDB (not in memory or localStorage). The Service Worker has no access to the page's memory, and it may be terminated and restarted at any time.

One Time Sync vs Periodic Background Sync

Feature	One-Time Background Sync	Periodic Background Sync
Purpose	Retry a failed/queued action when back online	Periodically fetch fresh data in background
Trigger	Connectivity returns after being offline	Time interval (minimum ~12 hours)
Example	Send queued messages, submit forms	Refresh news feed, sync calendar
Tab required?	No — works after tab is closed	No — works in background
Browser support	Chrome, Edge	Chrome, Edge (high-engagement sites only)
Safari/Firefox	❌ Not supported	❌ Not supported

Fallback Strategy (Critical for Interviews)

Since Background Sync is Chromium-only, you must always provide a fallback:

Primary path:   Register background sync → SW handles on connectivity
Fallback path:  Listen for 'online' event in main thread → retry queue manually

The pattern is: always write to IndexedDB first, then try to sync. Whether sync happens via Background Sync API or via an online event listener is an implementation detail.

// Minimal syntax — Background Sync registration
// In main.js:
// 1. Save action to IndexedDB 'outbox' store
// 2. registration.sync.register('send-messages')

// In sw.js:
// self.addEventListener('sync', event => {
//   if (event.tag === 'send-messages') {
//     event.waitUntil( processOutbox() )
//   }
// })

// Fallback in main.js:
// window.addEventListener('online', () => processOutbox())

⬆ Back to Top

Push Notifications How They Actually Work

The Architecture (Three Servers Involved)

Push notifications involve three parties — this is important to understand:

       Your Application                   Push Service                 User's Browser
┌──────────────────────────────┐   ┌────────────────────────┐   ┌────────────────────────┐
│                              │   │                        │   │                        │
│  ┌──────────┐   ┌─────────┐ │   │    FCM / APNs /        │   │    Service Worker      │
│  │  Client  │   │  Server │ │   │    Mozilla Push         │   │                        │
│  │  (sub    │──►│  (store │ │──►│    Service              │──►│    (receives push &    │
│  │  script) │   │  & push)│ │   │                        │   │     shows notification)│
│  └──────────┘   └─────────┘ │   │                        │   │                        │
│                              │   │                        │   │                        │
└──────────────────────────────┘   └────────────────────────┘   └────────────────────────┘

Your App (Client) — Subscribes to push, gets a unique subscription object containing an endpoint URL and encryption keys.
Your Server (Backend) — Stores subscriptions. When it wants to send a notification, it sends an encrypted payload to step 3.
Push Service (Browser Vendor) — Google's FCM (Chrome), Mozilla's Push Service (Firefox), Apple's APNs (Safari). These maintain persistent connections to browsers and deliver the push message.
Service Worker — Receives the push event, decrypts the payload, and calls showNotification().

The Push Flow (Step by Step)

Client subscribes:
- Request Notification.requestPermission() → user grants permission
- Call reg.pushManager.subscribe() with your VAPID public key
- Receive a PushSubscription object (contains endpoint URL + keys)
- Send this subscription to your server for storage
Server sends a push:
- Server takes the stored subscription endpoint + keys
- Encrypts the message payload using the Web Push protocol
- Sends an HTTP POST to the push service endpoint
- The push service queues and delivers it to the browser
Service Worker receives:
- push event fires in the SW (even if all tabs are closed)
- SW reads the payload: event.data.json()
- SW calls self.registration.showNotification(title, options)
User interacts:
- notificationclick event fires in the SW
- SW can open a URL, focus an existing tab, or dismiss

VAPID Keys What and Why

VAPID (Voluntary Application Server Identification) keys are a public/private key pair:

Public key — given to the browser during subscription (identifies your server)
Private key — kept on your server, used to sign push messages

Purpose: The push service verifies that the push message is coming from the same server that created the subscription. Prevents anyone else from sending pushes to your users.

Key Constraints

userVisibleOnly: true — The spec requires that every push notification results in a visible notification to the user. You CANNOT use push for silent background data sync (in most browsers).
Subscription can expire — The push service may invalidate subscriptions (returns HTTP 410 Gone). Your server must handle this and remove stale subscriptions.
iOS requires installation — Push notifications on iOS Safari only work if the PWA is added to the home screen (iOS 16.4+).

Notification Options (Interview Reference)

Option	Purpose
`body`	Notification text content
`icon`	Small icon (appears alongside text)
`badge`	Monochrome icon for status bar (Android)
`image`	Large hero image in the notification
`tag`	Groups notifications — same tag replaces existing notification
`renotify`	Vibrate even if replacing an existing notification (same tag)
`requireInteraction`	Notification stays until user interacts (doesn't auto-dismiss)
`actions`	Array of buttons shown in the notification (max 2-3)
`data`	Arbitrary data passed to `notificationclick` handler
`vibrate`	Array of vibration pattern durations (ms)

⬆ Back to Top

Web App Manifest and Installability

What is the Manifest?

The Web App Manifest is a JSON file (manifest.json) linked from your HTML that tells the browser:

This site can be installed as an app
Here is its name, icon, theme color, and display mode
Here is the start URL when launched from the home screen

Essential Manifest Fields

Field	Purpose	Required for Install?
`name`	Full app name (splash screen, app listing)	✅ (or `short_name`)
`short_name`	Abbreviated name (home screen icon label)	✅ (or `name`)
`start_url`	URL opened when app is launched	✅
`display`	Display mode (`standalone`, `fullscreen`, `minimal-ui`, `browser`)	✅ (must not be `browser`)
`icons`	Array of icon objects with `src`, `sizes`, `type`	✅ (192×192 + 512×512 minimum)
`theme_color`	Color of the title bar / status bar	Recommended
`background_color`	Splash screen background color	Recommended
`scope`	URL scope the app controls	Defaults to manifest directory
`description`	App description	Optional
`screenshots`	App screenshots (used in richer install UI)	Optional
`shortcuts`	Quick actions from long-press on app icon	Optional
`share_target`	Makes app a share target (can receive shared content)	Optional

Display Modes What They Mean

Mode	Behavior	Use When
`fullscreen`	Entire screen, no browser UI at all	Games, immersive experiences
`standalone`	Own window, no URL bar (looks like a native app)	Most PWAs — this is the default choice
`minimal-ui`	Like standalone but with minimal nav controls (back/reload)	Apps where users might need browser controls
`browser`	Normal browser tab	Not installable — defeats the purpose

Installability Criteria (Chrome)

For Chrome to show the install prompt, your app must have:

✅ HTTPS (or localhost for development)
✅ Web App Manifest with: name/short_name, icons (192×192 + 512×512), start_url, display ≠ browser
✅ Registered Service Worker with a fetch event handler
✅ Not already installed

The Install Prompt Flow

The browser fires a beforeinstallprompt event when installability criteria are met. You can:

Capture the event and prevent the default mini-infobar
Store the event reference
Show your own custom install button at the right moment
When user clicks → call deferredPrompt.prompt()
Check userChoice to know if they accepted or dismissed

Interview insight: You CANNOT trigger the install prompt on your own — it's gated by the browser. You can only intercept the browser's prompt and show it at a better time.

Detecting Installed State

// Check if running as installed PWA
window.matchMedia('(display-mode: standalone)').matches // true if installed
window.navigator.standalone === true                     // iOS Safari

You can also detect in CSS:

@media (display-mode: standalone) {
  .install-button { display: none; }
}

⬆ Back to Top

Cache Versioning and Update Strategies

Why Cache Versioning Matters

Without versioning, cached assets can become permanently stale. The user keeps getting old CSS/JS even after you deploy new versions.

The Versioning Pattern

Name caches with a version: shell-v2.1.0, static-v2.1.0
During install: Open the new versioned cache, precache new assets
During activate: Delete all caches that aren't in the current version's cache set

This ensures that when a new SW activates, it cleans up all caches from previous versions.

Cache Size Management

Without limits, caches grow forever. Two strategies:

Strategy	How	When
Entry limit (`maxEntries`)	Keep only the last N items (FIFO eviction)	Image caches, API caches
Time limit (`maxAgeSeconds`)	Delete entries older than N seconds	API responses, dynamic content

TTL Based Cache Expiration Pattern

The Cache API doesn't natively support expiration timestamps. The common workaround:

When caching a response, add a custom header (sw-cache-timestamp) with the current time
When reading from cache, check the timestamp — if older than the max age, delete and return null
Fetch fresh from network on expiry

The Two Layer Caching Problem (Interview Gold)

Browsers have two caching layers: the HTTP cache (controlled by Cache-Control, ETag headers) and the Service Worker Cache API. If you're not careful, the SW might fetch from the HTTP cache (getting stale content) and store that in the Cache API — double stale.

Solution: When fetching for cache updates in the SW, use cache: 'no-cache' or cache: 'reload' in the fetch options to bypass the HTTP cache. Or rely on hashed filenames (app.a1b2c3.js) where each version has a unique URL, making HTTP cache staleness irrelevant.

⬆ Back to Top

Real World Architecture Offline Capable App

System Design: Offline First Chat App

┌─────────────────────────────────────────────────────────────────┐
│                        Chat App PWA                              │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                      UI Layer                             │   │
│  │  ┌─────────┐  ┌────────────┐  ┌──────────────────────┐  │   │
│  │  │ Chat    │  │ Contact    │  │ Settings             │  │   │
│  │  │ View    │  │ List       │  │ View                 │  │   │
│  │  └────┬────┘  └─────┬──────┘  └──────────┬───────────┘  │   │
│  └───────┼──────────────┼───────────────────┼───────────────┘   │
│          │              │                   │                    │
│  ┌───────▼──────────────▼───────────────────▼───────────────┐   │
│  │               Data Access Layer                           │   │
│  │  ┌──────────────────────────────────────────────┐        │   │
│  │  │          IndexedDB                            │        │   │
│  │  │   ┌──────────┐ ┌─────────┐ ┌──────────┐     │        │   │
│  │  │   │ messages │ │ contacts│ │ outbox   │     │        │   │
│  │  │   │          │ │         │ │ (pending │     │        │   │
│  │  │   │          │ │         │ │  sends)  │     │        │   │
│  │  │   └──────────┘ └─────────┘ └──────────┘     │        │   │
│  │  └──────────────────────────────────────────────┘        │   │
│  └──────────────────────┬───────────────────────────────────┘   │
│                         │                                        │
│  ┌──────────────────────▼───────────────────────────────────┐   │
│  │              Service Worker                               │   │
│  │   ┌───────────────┐  ┌──────────────┐  ┌─────────────┐  │   │
│  │   │ Cache API     │  │ Background   │  │ Push        │  │   │
│  │   │ (App Shell +  │  │ Sync         │  │ Handler     │  │   │
│  │   │  API cache)   │  │              │  │             │  │   │
│  │   └───────────────┘  └──────────────┘  └─────────────┘  │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                  │
└──────────────────────────────────┬──────────────────────────────┘
                                   │
                        ┌──────────▼──────────┐
                        │   WebSocket / REST  │
                        │   Server            │
                        └─────────────────────┘

Data Flow: Sending a Message Offline

1. User types message & hits Send
    │
2. ──► Write to IndexedDB "messages" store (status: 'pending')
    │
3. ──► Update UI immediately (show message with '🕐 sending...' indicator)
    │
4. ──► Is online?
    │       ├── YES ──► POST to /api/messages
    │       │            ├── Success ──► Update status to 'sent' in IndexedDB
    │       │            │              ──► Update UI indicator to '✓ sent'
    │       │            └── Failure ──► Add to outbox, register background sync
    │       │
    │       └── NO ──► Add to "outbox" store in IndexedDB
    │                  ──► Register background sync ('send-messages')
    │                  ──► User can now close the tab safely
    │
5. [Later, when connectivity returns]
    ──► Service Worker 'sync' event fires
    ──► Read pending messages from outbox
    ──► POST each to /api/messages (in order)
    ──► On success: remove from outbox, update message status
    ──► On failure: re-throw error (browser will retry with backoff)

Architecture Decisions Explained

Decision	Why
IndexedDB for messages (not Cache API)	Messages are structured data, need indexed queries (by conversation, date). Cache API is for HTTP responses.
Separate "outbox" store	Cleanly separates "data" from "pending mutations." The outbox is a FIFO queue processed in order.
Optimistic UI	User sees the message immediately — no waiting for network. Status indicator shows sync state.
Background Sync	Guarantees delivery even if user closes the tab. Falls back to `online` event for non-Chrome.
WebSocket for real-time + REST for sync	WebSocket for live incoming messages; REST for offline queue processing (more reliable for retries).

⬆ Back to Top

Testing and Debugging PWAs

Chrome DevTools Your Best Friend

DevTools Panel	What to Check
Application → Service Workers	Registration status, update state, "Skip waiting" button, "Update on reload" checkbox
Application → Cache Storage	Inspect cached resources per cache name, verify cache keys
Application → IndexedDB	Browse stored data, verify sync queue
Application → Manifest	Validate manifest fields, check installability warnings
Application → Storage	View quota usage, "Clear site data" button
Network → Offline checkbox	Simulate offline mode
Network → Throttling	Simulate slow 3G, fast 3G
Lighthouse → PWA audit	Comprehensive installability and offline checklist

Testing Checklist (Interview Reference)

Test	What You're Verifying
First load → app works	SW registers, precaching succeeds
Repeat load → instant	App shell served from cache
Toggle offline → app shell loads	Cache-first strategy working
Offline → cached data visible	IndexedDB/Cache API returning stored data
Offline form submit → queued	Data saved to IndexedDB outbox
Back online → queued actions sync	Background Sync or online listener fires
New deployment → update prompt	SW update lifecycle working correctly
Install from browser	Manifest valid, install prompt appears
Push notification → received and clickable	Push subscription + SW push handler working
Cache doesn't grow unbounded	Expiration/trimming policies active
HTTPS on all resources	Required for SW registration
Lighthouse PWA audit → 100	Comprehensive validation

Debugging Tips

"Update on reload" checkbox in DevTools forces a new SW install on every page reload — essential during development.
"Bypass for network" checkbox makes the SW pass all fetches straight to the network — useful for debugging without disabling SW entirely.
Use console.log inside the SW and check the Service Worker console (not the page console) — click the SW file link in Application → Service Workers.
To test the full update flow, uncheck "Update on reload" and test naturally.

⬆ Back to Top

Trade offs, Gotchas and Platform Limitations

Common Pitfalls (Interview Gold)

Pitfall	What Goes Wrong	Prevention
Caching everything	Storage fills up, stale content everywhere	Be selective — cache app shell + critical assets, TTL for API
Not versioning caches	Old JS/CSS served forever after deploy	Name caches with version prefix, clean old on activate
`skipWaiting()` on breaking changes	Old page HTML + new SW = version mismatch	Use prompt-based updates for breaking changes
No fallback for cache miss	App shows blank screen offline	Always provide an `offline.html` fallback
Caching POST responses	Cache API only stores GET by default	Use IndexedDB for write operations
Ignoring opaque responses	Cross-origin `no-cors` responses cache with `status: 0`	Check `response.type` before caching, or use `CacheableResponsePlugin`
No cache size limits	Cache and IndexedDB grow unbounded on heavy use	Always set `maxEntries` and `maxAgeSeconds`
Assuming Background Sync works everywhere	Chrome/Edge only	Always provide `online` event fallback
Storing state in SW global variables	SW gets terminated/restarted — state is lost	Use IndexedDB or Cache API for persistent state

iOS Safari Limitations (Critical for Interviews)

Safari is the most restrictive platform for PWAs:

Limitation	Impact	Workaround
No Background Sync	Cannot queue and retry after tab close	Use `online` event listener; retry on app reopen
No Periodic Background Sync	Cannot refresh data in background	Refresh on app focus/visibility change
Push only when installed	Push notifications work only for home-screen PWAs (iOS 16.4+)	Guide users to install first
~7-day cache eviction	Safari may evict SW caches after 7 days of inactivity	Request persistent storage; remind users to visit regularly
~50 MB storage limit	Less generous than Chrome	Monitor storage quota; compress data
No `beforeinstallprompt`	Cannot show custom install button	Use Safari's native "Add to Home Screen" share menu
No Web App Manifest `shortcuts`	No quick actions on icon long-press	N/A — platform limitation

Service Worker Scope Gotchas

A SW at /scripts/sw.js defaults to scope /scripts/ — it only intercepts requests under /scripts/*.
To control the root scope from a subdirectory, the server must set the Service-Worker-Allowed: / response header.
Best practice: always place sw.js at the root of your site.

The Double Caching Problem

HTTP Cache Layer:   Browser's built-in HTTP cache (Cache-Control, ETag)
SW Cache Layer:     Your Service Worker's Cache API

Problem: SW fetches a resource → HTTP cache returns stale version → SW caches that stale version
Result: Even "fresh" SW cache entries contain stale data

Solution: Use hashed filenames (app.a1b2c3.js) — every version is a unique URL
         OR use fetch(request, { cache: 'no-cache' }) inside the SW

⬆ Back to Top

Decision Frameworks

Should I Build a PWA?

Does the app need offline access?
├── YES → Strong PWA candidate
└── NO  → PWA still valuable for caching/performance
    │
    └── Are users on mobile with poor connectivity?
        ├── YES → Strong PWA candidate
        └── NO  → Still helps with speed & installability
            │
            └── Need push notifications without native app?
                ├── YES → PWA required
                └── NO  │
                    └── Need home screen presence without native app?
                        ├── YES → PWA with manifest
                        └── NO  │
                            └── Budget for native app?
                                ├── NO  → PWA is the answer
                                └── YES → Evaluate native-only features needed

Cache Strategy Quick Decision

What kind of resource?
│
├── Static asset with content hash? (app.a1b2c3.js)
│   └── Cache First
│
├── HTML pages?
│   └── Network First (with optional timeout → cache fallback)
│
├── API data needing speed + freshness?
│   └── Stale-While-Revalidate
│
├── Auth, payment, analytics?
│   └── Network Only (never cache)
│
├── Precached app shell?
│   └── Cache Only
│
└── Large media / CDN assets?
    └── Cache First + expiration limits

Offline First: When Is It Worth the Complexity?

Factor	Offline-First	Online-First (with graceful fallback)
Users frequently offline	✅ Full offline-first	Possible but UX suffers
Collaborative/real-time data	Complex (need CRDTs/OT)	✅ Simpler
Read-heavy app (news, docs)	✅ Great fit	Cache-based approach works too
Write-heavy app (forms, chat)	✅ Worth the investment	Queuing still needed
Single-user data	✅ Simple conflict resolution	Not needed
Multi-user editable data	Complex conflict resolution	✅ Simpler if always online

⬆ Back to Top

Interview Questions and Answers

Q1: What is a Service Worker and how does it differ from a Web Worker?

A: Both run in background threads, but they serve different purposes:

Web Worker: A general-purpose background thread for CPU-intensive tasks. Lives as long as the page that created it. Cannot intercept network requests.
Service Worker: A specific type of worker that acts as a network proxy. It intercepts all fetch requests from the page and decides how to respond. It has its own lifecycle (install → activate → idle), persists across page visits, can run when no tabs are open (for push/sync), and has access to the Cache API.

Key difference: A Web Worker helps you compute in the background. A Service Worker helps you control the network and enable offline support.

Q2: Explain the Service Worker update flow and why `skipWaiting()` can be dangerous.

A: When the browser detects a byte-level change in the SW file, it triggers the update flow: download → install new SW → wait → activate. The "waiting" state exists because the old SW is still controlling open tabs. Activating the new SW would create a version mismatch — old page code with new SW behavior.

skipWaiting() bypasses the waiting phase and activates the new SW immediately. This is dangerous because an open tab with old HTML/JS is now controlled by the new SW. If the new SW changes caching behavior, API response handling, or anything the old page code depends on, the app can break silently.

Safe approach: Detect the update, show a "refresh" banner, and only skipWaiting() when the user explicitly chooses to update.

Q3: What caching strategy would you use for a social media feed?

A: Stale-While-Revalidate (SWR). The feed loads instantly from cache (even if slightly stale), while a background fetch updates the cache. Next time the user pulls up the feed, they'll see the fresh version. Optionally, the SW can postMessage() to the page when fresh data arrives, and the app can show a "New posts available" toast.

For the app shell (header, nav, footer) → Cache First.

For user auth endpoints → Network Only.

For images → Cache First with expiration (max 100 entries, 60-day max age).

Q4: How would you design an offline first form submission?

When user submits the form, save the data to IndexedDB immediately (not just in memory).
Show a success indicator with a "pending" status (optimistic UI).
If online → POST to server immediately. On success → update status to "synced."
If offline → register a Background Sync event with the tag 'submit-form'.
When connectivity returns, the SW wakes up, reads pending submissions from IndexedDB, and POSTs them.
Fallback for Safari/Firefox: listen for the online event in the main thread and retry.

The key principle: IndexedDB is the source of truth, not the server. The server is eventually consistent with the client.

Q5: What are CRDTs and when would you use them?

A: CRDTs (Conflict-free Replicated Data Types) are data structures mathematically designed to be merged from any direction without conflicts. Unlike Last-Write-Wins (which discards changes), CRDTs preserve all concurrent updates and merge them deterministically.

Examples: G-Counter (grow-only counter), PN-Counter (increment/decrement), LWW-Register, OR-Set (observed-remove set).

Use when: Multiple users can edit the same data concurrently (like Figma, Notion, or a shared whiteboard). Libraries like Yjs and Automerge implement CRDTs for JavaScript.

For simpler single-user offline scenarios, LWW (Last Write Wins) is usually sufficient.

Q6: What's the difference between Cache API and IndexedDB?

A: They store different things:

Cache API → Stores HTTP Request/Response pairs. Used by Service Workers to cache network responses. Think of it as a programmable HTTP cache.
IndexedDB → Stores structured JavaScript data (objects, arrays, blobs). Used for application data like user records, messages, settings.

In an offline PWA, you'd use both: Cache API for caching the app shell and API responses (in the SW), and IndexedDB for storing and querying structured app data (in both the main thread and SW).

Q7: How do push notifications work under the hood?

A: Three servers are involved:

Client subscribes via pushManager.subscribe() → gets a subscription object (endpoint URL + encryption keys)
Your server stores the subscription. To send a push, it encrypts the payload and POSTs to the push service endpoint (using the web-push protocol with VAPID keys for authentication)
Browser vendor's push service (FCM for Chrome, Mozilla for Firefox, APNs for Safari) maintains a persistent connection to the browser and delivers the message
Service Worker receives the push event, decrypts the payload, and shows a notification via showNotification()

Key constraint: Every push must result in a visible notification (userVisibleOnly: true). You cannot use push for silent data sync.

Q8: What are the installability requirements for a PWA?

A: In Chrome, four requirements:

HTTPS (or localhost)
Web App Manifest with name/short_name, icons (192px + 512px), start_url, display set to standalone/fullscreen/minimal-ui
Registered Service Worker with a fetch event handler
Not already installed

Note: Safari doesn't support beforeinstallprompt — users must use the "Add to Home Screen" option from the share menu.

Q9: How would you handle the "user on a plane with no connectivity" scenario for a news app?

A: Design for full offline reading:

App Shell → precached at SW install (nav, footer, skeleton screens)
Articles → when user reads articles online, cache them in IndexedDB (full content, images)
SWR for feed → the feed API response is cached. Offline users see the last-synced feed.
Image caching → Cache First with expiration (max 200 entries, 30 days) for article images
Offline indicator → show a subtle banner: "You're offline — showing saved articles"
Periodic sync (if supported) → refresh the feed in the background every 12 hours
Persistent storage → call navigator.storage.persist() to prevent eviction on engaged users

Q10: How do you prevent cache from growing unbounded?

A: Three approaches:

Entry limit — Keep max N items per cache (e.g., 100 images). Evict oldest on overflow (FIFO).
TTL (Time-to-Live) — Add a timestamp header when caching. On read, check age and delete expired entries.
Version cleanup — On SW activate, delete all caches not in the current version's allow-list.

In production, consider using libraries like Workbox that provide built-in ExpirationPlugin handling all three automatically (maxEntries, maxAgeSeconds, purgeOnQuotaError).

⬆ Back to Top

Final Recommendations

Production Checklist

Start with the App Shell — Cache the minimal UI shell for instant repeat loads.
Route-based strategy — Different cache strategies for different request types (static → Cache First, API → SWR, HTML → Network First, auth → Network Only).
Always provide offline fallback — Even if it's just an offline.html page saying "You're offline."
Limit cache size — Use maxEntries and maxAgeSeconds. Caches grow silently until quota is hit.
Version your caches — Clean up old caches on activate event. Old caches are dead weight.
Use prompt-based updates — Don't auto-skipWaiting() for major updates; show a refresh banner.
Request persistent storage — Call navigator.storage.persist() for installed PWAs.
Handle iOS quirks — Provide fallbacks for Background Sync and understand Safari's 7-day eviction policy.
Monitor with Lighthouse — Run PWA audits in CI/CD to catch regressions.
Background Sync as progressive enhancement — Always queue to IndexedDB first; Background Sync is the optimization, not the requirement.
Test offline aggressively — DevTools offline mode, kill network at various states, test slow 3G, test SW update flow.

The One Sentence Summary

A PWA is a web app that works offline (Service Worker + Cache API), feels native (App Shell + Manifest), and stays connected (Background Sync + Push) — all while being a normal website that progressively enhances based on browser capabilities.

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Pagination Patterns — Guide

ZeeshanAli-0704 — Thu, 12 Mar 2026 17:10:44 +0000

Pagination Patterns — Complete Frontend System Design Guide

Offset-based, Cursor-based, Keyset, Page-number, Infinite Scroll, Virtual Scroll, Load More — frontend & backend implementation, trade-offs, and interview questions.

Why Pagination Matters
Pagination Strategies Overview
Offset Based Pagination
Cursor Based Pagination
Keyset (Seek) Pagination
Page Number Pagination
Frontend Patterns
- Infinite Scroll
- Load More Button
- Virtual Windowed Scroll
- Traditional Page Numbers
Comparison Table
Real World Architecture Examples
Edge Cases and Gotchas
Interview Questions and Answers ⬆ Back to Top

Why Pagination Matters

Without Pagination:
┌────────┐   GET /posts    ┌────────┐   SELECT * FROM posts   ┌────┐
│ Client │───────────────► │ Server │────────────────────────►│ DB │
│        │◄─────────────── │        │◄────────────────────────│    │
└────────┘  1M records     └────────┘   Full table scan       └────┘
            (💀 OOM)                    (💀 slow query)

Problems without pagination:

Memory — Browser crashes rendering 100K+ DOM nodes
Bandwidth — Sending megabytes of JSON over the wire
Database — Full table scans, no index usage, locks
UX — User waits 10+ seconds staring at a spinner
SEO — Search engines can't crawl infinite content

Pagination solves this by fetching data in small, manageable pages (or chunks).

⬆ Back to Top

Pagination Strategies Overview

                     Pagination Strategies
                            │
            ┌───────────────┼───────────────┐
            ▼               ▼               ▼
      Offset-Based    Cursor-Based     Keyset (Seek)
      (LIMIT/OFFSET)  (opaque token)   (WHERE + ORDER)
            │               │               │
            ▼               ▼               ▼
     ┌──────────┐    ┌──────────┐    ┌──────────┐
     │ Page 1   │    │ after:   │    │ WHERE    │
     │ Page 2   │    │  abc123  │    │ id > 100 │
     │ Page 3   │    │          │    │ LIMIT 20 │
     └──────────┘    └──────────┘    └──────────┘

                  Frontend Patterns
                        │
         ┌──────────────┼──────────────┐──────────────┐
         ▼              ▼              ▼              ▼
   Page Numbers    Infinite      Load More       Virtual
   [1][2][3]►      Scroll        [ Button ]      Scroll
                   (auto)        (manual)        (windowed)

Key Distinction: Offset / Cursor / Keyset = how you ask the backend for data. Infinite Scroll / Load More / Page Numbers = how you present it on the frontend.

⬆ Back to Top

Offset Based Pagination

3.1 How It Works

The client specifies offset (skip N rows) and limit (take N rows).

Page 1: offset=0,  limit=20  →  rows 1–20
Page 2: offset=20, limit=20  →  rows 21–40
Page 3: offset=40, limit=20  →  rows 41–60

3.2 Backend Implementation

-- SQL Query
SELECT * FROM posts
ORDER BY created_at DESC
LIMIT 20 OFFSET 40;  -- Page 3 (0-indexed)

// ─── Express API ───
app.get('/api/posts', async (req, res) => {
  const page = Math.max(1, parseInt(req.query.page) || 1);
  const limit = Math.min(100, parseInt(req.query.limit) || 20); // cap at 100
  const offset = (page - 1) * limit;

  const [posts, totalCount] = await Promise.all([
    db.query('SELECT * FROM posts ORDER BY created_at DESC LIMIT $1 OFFSET $2', [limit, offset]),
    db.query('SELECT COUNT(*) FROM posts')
  ]);

  const totalPages = Math.ceil(totalCount.rows[0].count / limit);

  res.json({
    data: posts.rows,
    pagination: {
      page,
      limit,
      totalCount: parseInt(totalCount.rows[0].count),
      totalPages,
      hasNextPage: page < totalPages,
      hasPrevPage: page > 1
    }
  });
});

API Response:

{
  "data": [
    { "id": 41, "title": "Post 41", "created_at": "2026-03-10" },
    { "id": 42, "title": "Post 42", "created_at": "2026-03-09" }
  ],
  "pagination": {
    "page": 3,
    "limit": 20,
    "totalCount": 1500,
    "totalPages": 75,
    "hasNextPage": true,
    "hasPrevPage": true
  }
}

3.3 Frontend Implementation

// ─── React: Offset Pagination with TanStack Query ───
import { useQuery, keepPreviousData } from '@tanstack/react-query';

function usePaginatedPosts(page, limit = 20) {
  return useQuery({
    queryKey: ['posts', page, limit],
    queryFn: () =>
      fetch(`/api/posts?page=${page}&limit=${limit}`).then(r => r.json()),
    placeholderData: keepPreviousData, // keep old data while fetching new page
    staleTime: 5 * 60 * 1000, // 5 minutes
  });
}

function PostList() {
  const [page, setPage] = useState(1);
  const { data, isLoading, isPlaceholderData } = usePaginatedPosts(page);

  if (isLoading) return <Skeleton count={20} />;

  return (
    <div>
      {data.data.map(post => (
        <PostCard key={post.id} post={post} />
      ))}

      <div className="pagination-controls">
        <button
          onClick={() => setPage(p => Math.max(1, p - 1))}
          disabled={!data.pagination.hasPrevPage}
        >
          Previous
        </button>

        <span>
          Page {data.pagination.page} of {data.pagination.totalPages}
        </span>

        <button
          onClick={() => setPage(p => p + 1)}
          disabled={!data.pagination.hasNextPage || isPlaceholderData}
        >
          Next
        </button>
      </div>
    </div>
  );
}

3.4 The Offset Problem — Skipping & Duplication

Initial state: [A, B, C, D, E, F, G, H, I, J]  (page size = 3)

Page 1 (offset=0): [A, B, C] ✅

    ↓ User deletes item B while on Page 1

Database now:      [A, C, D, E, F, G, H, I, J]

Page 2 (offset=3): [E, F, G]  ❌ Item D got SKIPPED!

                    A  C  D  E  F  G  H  I  J
                    └──┘  └─ skipped!
                    offset=0..2    offset=3..5

Initial state: [A, B, C, D, E, F, G, H, I, J]  (page size = 3)

Page 1 (offset=0): [A, B, C] ✅

    ↓ New item Z inserted at the top

Database now:      [Z, A, B, C, D, E, F, G, H, I, J]

Page 2 (offset=3): [C, D, E]  ❌ Item C appears AGAIN (duplicate)!

This is the fundamental flaw of offset-based pagination in real-time datasets.

3.5 Performance Problem

-- Page 1: Fast ✅
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 0;
-- DB reads 20 rows

-- Page 500: SLOW ❌
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 9980;
-- DB reads and discards 9980 rows, then returns 20
-- Gets worse linearly: O(offset + limit)

3.6 Pros & Cons

Pros	Cons
Simple to implement	Slow for deep pages (`OFFSET 100000`)
Easy to jump to any page	Items can be skipped or duplicated on writes
`totalCount` enables "Page X of Y"	`COUNT(*)` is expensive on large tables
Stateless	Not suitable for real-time/frequently changing data
Works with any database

3.7 When to Use Offset

Admin panels — Paginated tables with "Go to page" feature
Search results — Google-style page numbers (data is relatively static per query)
Small datasets — Under 100K rows where OFFSET performance is acceptable
When users need random access — "Jump to page 50"

⬆ Back to Top

Cursor Based Pagination

4.1 How It Works

Instead of saying "skip N rows," the client sends a cursor — an opaque string that points to a specific item. The server returns items after (or before) that cursor.

Request 1:  GET /posts?first=20
Response:   { edges: [...20 items], pageInfo: { endCursor: "abc123", hasNextPage: true } }

Request 2:  GET /posts?first=20&after=abc123
Response:   { edges: [...20 items], pageInfo: { endCursor: "def456", hasNextPage: true } }

Request 3:  GET /posts?first=20&after=def456
Response:   { edges: [...15 items], pageInfo: { endCursor: "ghi789", hasNextPage: false } }

The cursor is typically a Base64-encoded value (e.g., the row's ID or timestamp) that the client treats as opaque.

4.2 Backend Implementation

// ─── Express: Cursor-Based Pagination ───
app.get('/api/posts', async (req, res) => {
  const limit = Math.min(100, parseInt(req.query.first) || 20);
  const afterCursor = req.query.after; // opaque cursor string

  let query = 'SELECT * FROM posts';
  const params = [];

  if (afterCursor) {
    // Decode cursor → { id, created_at }
    const decoded = JSON.parse(Buffer.from(afterCursor, 'base64').toString());
    query += ` WHERE (created_at, id) < ($1, $2)`;
    params.push(decoded.created_at, decoded.id);
  }

  query += ` ORDER BY created_at DESC, id DESC LIMIT $${params.length + 1}`;
  params.push(limit + 1); // fetch 1 extra to check hasNextPage

  const result = await db.query(query, params);
  const hasNextPage = result.rows.length > limit;
  const edges = result.rows.slice(0, limit); // remove the extra

  res.json({
    edges: edges.map(node => ({
      node,
      cursor: Buffer.from(JSON.stringify({
        id: node.id,
        created_at: node.created_at
      })).toString('base64')
    })),
    pageInfo: {
      hasNextPage,
      hasPreviousPage: !!afterCursor,
      startCursor: edges[0]
        ? Buffer.from(JSON.stringify({ id: edges[0].id, created_at: edges[0].created_at })).toString('base64')
        : null,
      endCursor: edges.length > 0
        ? Buffer.from(JSON.stringify({ id: edges[edges.length - 1].id, created_at: edges[edges.length - 1].created_at })).toString('base64')
        : null
    }
  });
});

API Response (Relay-style):

{
  "edges": [
    {
      "node": { "id": 1042, "title": "Post A", "created_at": "2026-03-10T10:00:00Z" },
      "cursor": "eyJpZCI6MTA0MiwiY3JlYXRlZF9hdCI6IjIwMjYtMDMtMTBUMTA6MDA6MDBaIn0="
    },
    {
      "node": { "id": 1041, "title": "Post B", "created_at": "2026-03-10T09:30:00Z" },
      "cursor": "eyJpZCI6MTA0MSwiY3JlYXRlZF9hdCI6IjIwMjYtMDMtMTBUMDk6MzA6MDBaIn0="
    }
  ],
  "pageInfo": {
    "hasNextPage": true,
    "hasPreviousPage": true,
    "startCursor": "eyJpZCI6MTA0MiwiY3JlYXRlZF9hdCI6IjIwMjYtMDMtMTBUMTA6MDA6MDBaIn0=",
    "endCursor": "eyJpZCI6MTA0MSwiY3JlYXRlZF9hdCI6IjIwMjYtMDMtMTBUMDk6MzA6MDBaIn0="
  }
}

4.3 GraphQL Relay Connection Spec

The most widely adopted cursor pagination standard:

# Schema
type Query {
  posts(first: Int, after: String, last: Int, before: String): PostConnection!
}

type PostConnection {
  edges: [PostEdge!]!
  pageInfo: PageInfo!
  totalCount: Int
}

type PostEdge {
  node: Post!
  cursor: String!
}

type PageInfo {
  hasNextPage: Boolean!
  hasPreviousPage: Boolean!
  startCursor: String
  endCursor: String
}

type Post {
  id: ID!
  title: String!
  createdAt: DateTime!
}

# Query
query GetPosts($after: String) {
  posts(first: 20, after: $after) {
    edges {
      node {
        id
        title
        createdAt
      }
      cursor
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

4.4 Frontend Implementation

// ─── React: Cursor Pagination with TanStack Query (Infinite) ───
import { useInfiniteQuery } from '@tanstack/react-query';

function useInfinitePosts() {
  return useInfiniteQuery({
    queryKey: ['posts'],
    queryFn: ({ pageParam }) =>
      fetch(`/api/posts?first=20${pageParam ? `&after=${pageParam}` : ''}`)
        .then(r => r.json()),
    initialPageParam: null,
    getNextPageParam: (lastPage) =>
      lastPage.pageInfo.hasNextPage ? lastPage.pageInfo.endCursor : undefined,
  });
}

function PostFeed() {
  const {
    data,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
    isLoading,
  } = useInfinitePosts();

  if (isLoading) return <Skeleton />;

  const allPosts = data.pages.flatMap(page => page.edges.map(e => e.node));

  return (
    <div>
      {allPosts.map(post => (
        <PostCard key={post.id} post={post} />
      ))}

      {hasNextPage && (
        <button
          onClick={() => fetchNextPage()}
          disabled={isFetchingNextPage}
        >
          {isFetchingNextPage ? 'Loading...' : 'Load More'}
        </button>
      )}
    </div>
  );
}

4.5 Why Cursors Fix the Offset Problem

Initial state: [A, B, C, D, E, F, G, H, I, J]  (page size = 3)

Page 1 (no cursor): [A, B, C] → cursor points to C

    ↓ User deletes item B

Database now:      [A, C, D, E, F, G, H, I, J]

Page 2 (after C):  [D, E, F] ✅  No item skipped!

The cursor says "give me everything AFTER item C" — regardless of what was inserted or deleted before C.

4.6 Pros & Cons

Pros	Cons
Consistent results even with inserts/deletes	Cannot jump to arbitrary page
High performance (uses index seek)	No "Page X of Y" without extra `COUNT(*)`
Works perfectly for infinite scroll	Slightly more complex to implement
Scales to billions of rows	Client must store cursor
Standard spec (Relay Connection)	Bi-directional cursoring is more complex

4.7 When to Use Cursor

Social media feeds — Instagram, Twitter, Facebook
Infinite scroll UIs — news feeds, product catalogs
Chat message history — scroll up to load older messages
Real-time / frequently changing data — where offset guarantees break
Large datasets — millions to billions of rows

⬆ Back to Top

Keyset (Seek) Pagination

5.1 How It Works

Keyset pagination is the database-level technique behind cursor-based pagination. Instead of an opaque cursor, the client sends the actual column values to seek from.

-- Instead of OFFSET:
SELECT * FROM posts
WHERE (created_at, id) < ('2026-03-10 09:30:00', 1041)
ORDER BY created_at DESC, id DESC
LIMIT 20;

This is essentially cursor-based pagination but with transparent (non-opaque) parameters.

5.2 Backend Implementation

// ─── Express: Keyset Pagination ───
app.get('/api/posts', async (req, res) => {
  const limit = Math.min(100, parseInt(req.query.limit) || 20);
  const lastCreatedAt = req.query.last_created_at;
  const lastId = req.query.last_id;

  let query, params;

  if (lastCreatedAt && lastId) {
    // Keyset condition: fetch rows "after" the last seen row
    query = `
      SELECT * FROM posts
      WHERE (created_at, id) < ($1, $2)
      ORDER BY created_at DESC, id DESC
      LIMIT $3
    `;
    params = [lastCreatedAt, lastId, limit + 1];
  } else {
    query = `
      SELECT * FROM posts
      ORDER BY created_at DESC, id DESC
      LIMIT $1
    `;
    params = [limit + 1];
  }

  const result = await db.query(query, params);
  const hasMore = result.rows.length > limit;
  const posts = result.rows.slice(0, limit);
  const lastPost = posts[posts.length - 1];

  res.json({
    data: posts,
    pagination: {
      hasMore,
      nextParams: hasMore
        ? { last_created_at: lastPost.created_at, last_id: lastPost.id }
        : null
    }
  });
});

API Response:

{
  "data": [
    { "id": 1042, "title": "Post A", "created_at": "2026-03-10T10:00:00Z" },
    { "id": 1041, "title": "Post B", "created_at": "2026-03-10T09:30:00Z" }
  ],
  "pagination": {
    "hasMore": true,
    "nextParams": {
      "last_created_at": "2026-03-10T09:30:00Z",
      "last_id": 1041
    }
  }
}

5.3 Keyset vs Cursor vs Offset — The DB Perspective

-- OFFSET: Scans and DISCARDS rows → O(offset + limit)
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 10000;
-- ⚠️ DB reads 10,020 rows, returns 20

-- KEYSET: Seeks directly via index → O(limit)
SELECT * FROM posts
WHERE (created_at, id) < ('2026-01-01', 5000)
ORDER BY created_at DESC, id DESC LIMIT 20;
-- ✅ DB reads exactly 20 rows (index seek)

Requires a composite index:

CREATE INDEX idx_posts_created_id ON posts (created_at DESC, id DESC);

5.4 Pros & Cons

Pros	Cons
Fastest for deep pagination (index seek)	Exposes sort columns to client
Consistent results	Cannot jump to arbitrary page
Simple to understand (no encoding)	Need unique sort key (tie-breaking column)
No opaque cursor overhead	Multi-column sort is complex

⬆ Back to Top

Page Number Pagination

6.1 How It Works

A simplified version of offset-based — the client sends a page number, and the server computes the offset internally.

GET /api/posts?page=3&per_page=20
→ Server computes: offset = (3-1) * 20 = 40
→ SQL: LIMIT 20 OFFSET 40

6.2 Backend Implementation

// ─── Express: Page-Number Pagination ───
app.get('/api/posts', async (req, res) => {
  const page = Math.max(1, parseInt(req.query.page) || 1);
  const perPage = Math.min(100, parseInt(req.query.per_page) || 20);
  const offset = (page - 1) * perPage;

  const [posts, countResult] = await Promise.all([
    db.query(
      'SELECT * FROM posts ORDER BY created_at DESC LIMIT $1 OFFSET $2',
      [perPage, offset]
    ),
    db.query('SELECT COUNT(*) as total FROM posts')
  ]);

  const total = parseInt(countResult.rows[0].total);
  const totalPages = Math.ceil(total / perPage);

  res.json({
    data: posts.rows,
    meta: {
      currentPage: page,
      perPage,
      total,
      totalPages,
      hasNextPage: page < totalPages,
      hasPrevPage: page > 1,
      // Generate page links (HATEOAS-style)
      links: {
        first: `/api/posts?page=1&per_page=${perPage}`,
        last: `/api/posts?page=${totalPages}&per_page=${perPage}`,
        prev: page > 1 ? `/api/posts?page=${page - 1}&per_page=${perPage}` : null,
        next: page < totalPages ? `/api/posts?page=${page + 1}&per_page=${perPage}` : null
      }
    }
  });
});

6.3 Frontend: Page Number Navigation Component

// ─── React: Page Number Pagination ───
function Pagination({ currentPage, totalPages, onPageChange }) {
  // Generate visible page numbers with ellipsis
  const getPageNumbers = () => {
    const delta = 2; // pages to show around current
    const pages = [];

    for (
      let i = Math.max(2, currentPage - delta);
      i <= Math.min(totalPages - 1, currentPage + delta);
      i++
    ) {
      pages.push(i);
    }

    // Add first page
    if (pages[0] > 2) pages.unshift('...');
    pages.unshift(1);

    // Add last page
    if (pages[pages.length - 1] < totalPages - 1) pages.push('...');
    if (totalPages > 1) pages.push(totalPages);

    return pages;
  };

  return (
    <nav aria-label="Pagination">
      <button
        onClick={() => onPageChange(currentPage - 1)}
        disabled={currentPage === 1}
        aria-label="Previous page"
      >
        ← Previous
      </button>

      {getPageNumbers().map((page, idx) =>
        page === '...' ? (
          <span key={`ellipsis-${idx}`} className="ellipsis">…</span>
        ) : (
          <button
            key={page}
            onClick={() => onPageChange(page)}
            className={page === currentPage ? 'active' : ''}
            aria-current={page === currentPage ? 'page' : undefined}
            aria-label={`Page ${page}`}
          >
            {page}
          </button>
        )
      )}

      <button
        onClick={() => onPageChange(currentPage + 1)}
        disabled={currentPage === totalPages}
        aria-label="Next page"
      >
        Next →
      </button>
    </nav>
  );
}

// Renders: ← Previous [1] ... [4] [5] [6] ... [50] Next →

// ─── URL-Synced Pagination (Next.js / React Router) ───
import { useSearchParams } from 'react-router-dom';

function PostListPage() {
  const [searchParams, setSearchParams] = useSearchParams();
  const page = parseInt(searchParams.get('page') || '1');

  const { data, isLoading } = useQuery({
    queryKey: ['posts', page],
    queryFn: () => fetch(`/api/posts?page=${page}`).then(r => r.json()),
  });

  const handlePageChange = (newPage) => {
    setSearchParams({ page: newPage.toString() });
    window.scrollTo({ top: 0, behavior: 'smooth' });
  };

  return (
    <div>
      <PostList posts={data?.data} loading={isLoading} />
      <Pagination
        currentPage={page}
        totalPages={data?.meta.totalPages}
        onPageChange={handlePageChange}
      />
    </div>
  );
}

6.4 When to Use

E-commerce product listings — users expect "Page 3 of 50"
Admin tables — sortable, filterable data grids
Search results — Google-style page numbers
Documentation / article listings — SEO-friendly URLs (?page=5)

⬆ Back to Top

Frontend Patterns

7.1 Infinite Scroll

Automatically loads the next page when the user scrolls near the bottom.

┌─────────────────────┐
│  Post 1             │
│  Post 2             │  ← Visible viewport
│  Post 3             │
│  Post 4             │
├─────────────────────┤ ← Intersection trigger (sentinel)
│  ░░░ Loading... ░░░ │
└─────────────────────┘
         │
         ▼ fetches next page
┌─────────────────────┐
│  Post 1             │
│  Post 2             │
│  Post 3             │
│  Post 4             │
│  Post 5  (new)      │  ← Appended
│  Post 6  (new)      │
│  Post 7  (new)      │
├─────────────────────┤ ← New sentinel position
│                     │
└─────────────────────┘

Implementation with Intersection Observer

// ─── React: Infinite Scroll with Intersection Observer ───
function useIntersectionObserver(onIntersect, options = {}) {
  const ref = useRef(null);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) onIntersect();
      },
      { rootMargin: '200px', threshold: 0, ...options }
    );

    const el = ref.current;
    if (el) observer.observe(el);

    return () => {
      if (el) observer.unobserve(el);
    };
  }, [onIntersect, options]);

  return ref;
}

function InfinitePostFeed() {
  const {
    data,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
    isLoading,
  } = useInfiniteQuery({
    queryKey: ['posts'],
    queryFn: ({ pageParam }) =>
      fetch(`/api/posts?first=20${pageParam ? `&after=${pageParam}` : ''}`)
        .then(r => r.json()),
    initialPageParam: null,
    getNextPageParam: (lastPage) =>
      lastPage.pageInfo.hasNextPage ? lastPage.pageInfo.endCursor : undefined,
  });

  // Sentinel ref — triggers fetch when scrolled into view
  const sentinelRef = useIntersectionObserver(
    useCallback(() => {
      if (hasNextPage && !isFetchingNextPage) {
        fetchNextPage();
      }
    }, [hasNextPage, isFetchingNextPage, fetchNextPage])
  );

  if (isLoading) return <PostSkeleton count={6} />;

  const allPosts = data.pages.flatMap(p => p.edges.map(e => e.node));

  return (
    <div role="feed" aria-busy={isFetchingNextPage}>
      {allPosts.map((post, index) => (
        <article key={post.id} aria-setsize={-1} aria-posinset={index + 1}>
          <PostCard post={post} />
        </article>
      ))}

      {/* Sentinel element — loads next page when visible */}
      <div ref={sentinelRef} style={{ height: 1 }} />

      {isFetchingNextPage && <Spinner />}

      {!hasNextPage && <p>You've reached the end!</p>}
    </div>
  );
}

Scroll Position Restoration

// ─── Restore scroll position when user navigates back ───
function useScrollRestoration(key) {
  useEffect(() => {
    // Restore
    const savedPos = sessionStorage.getItem(`scroll-${key}`);
    if (savedPos) {
      window.scrollTo(0, parseInt(savedPos));
    }

    // Save on unmount
    return () => {
      sessionStorage.setItem(`scroll-${key}`, window.scrollY.toString());
    };
  }, [key]);
}

Pros & Cons of Infinite Scroll

Pros	Cons
Seamless UX (no clicks)	Hard to reach footer content
Great for content feeds	Memory grows unbounded (DOM nodes)
Mobile-friendly (natural gesture)	Poor accessibility (no page landmarks)
Higher engagement metrics	Can't bookmark a specific "page"
	No "Page X of Y" information
	Back/forward navigation loses position

7.2 Load More Button

Manual variant of infinite scroll — user clicks a button to load more.

function PostListWithLoadMore() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } = useInfinitePosts();

  const allPosts = data?.pages.flatMap(p => p.edges.map(e => e.node)) || [];

  return (
    <div>
      {allPosts.map(post => <PostCard key={post.id} post={post} />)}

      {hasNextPage && (
        <button
          onClick={() => fetchNextPage()}
          disabled={isFetchingNextPage}
          className="load-more-btn"
        >
          {isFetchingNextPage ? (
            <Spinner size="sm" />
          ) : (
            `Load More (${allPosts.length} of ${data.pages[0].totalCount || '?'})`
          )}
        </button>
      )}
    </div>
  );
}

When to Prefer Load More over Infinite Scroll

User needs to reach the footer (contact info, links)
Content is valuable — users want to decide when to load more (not forced)
Accessibility — Screen readers handle a button better than auto-loading
Monetization — Place ads between "Load More" batches

7.3 Virtual / Windowed Scroll

Renders only the items visible in the viewport (+ a small buffer). Perfect for very long lists.

Full List (10,000 items):
  [Item 0   ] ─── NOT rendered (above viewport)
  [Item 1   ]
  ...
  [Item 98  ]
  ─────────── ← Viewport top
  [Item 99  ] ─── RENDERED
  [Item 100 ] ─── RENDERED
  [Item 101 ] ─── RENDERED
  [Item 102 ] ─── RENDERED
  [Item 103 ] ─── RENDERED
  ─────────── ← Viewport bottom
  [Item 104 ]
  ...
  [Item 9999] ─── NOT rendered (below viewport)

Only 5-15 DOM nodes exist at any time, regardless of list size.

// ─── React: Virtual Scroll with @tanstack/react-virtual ───
import { useVirtualizer } from '@tanstack/react-virtual';

function VirtualPostList({ posts }) {
  const parentRef = useRef(null);

  const virtualizer = useVirtualizer({
    count: posts.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 120, // estimated row height in px
    overscan: 5, // extra items above/below viewport
  });

  return (
    <div
      ref={parentRef}
      style={{ height: '100vh', overflow: 'auto' }}
    >
      <div
        style={{
          height: `${virtualizer.getTotalSize()}px`,
          width: '100%',
          position: 'relative',
        }}
      >
        {virtualizer.getVirtualItems().map(virtualRow => (
          <div
            key={virtualRow.key}
            style={{
              position: 'absolute',
              top: 0,
              left: 0,
              width: '100%',
              height: `${virtualRow.size}px`,
              transform: `translateY(${virtualRow.start}px)`,
            }}
          >
            <PostCard post={posts[virtualRow.index]} />
          </div>
        ))}
      </div>
    </div>
  );
}

// ─── Infinite Scroll + Virtual Scroll (Best combo for huge lists) ───
function VirtualInfiniteList() {
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } = useInfinitePosts();
  const allPosts = data?.pages.flatMap(p => p.edges.map(e => e.node)) || [];
  const parentRef = useRef(null);

  const virtualizer = useVirtualizer({
    count: hasNextPage ? allPosts.length + 1 : allPosts.length,
    getScrollElement: () => parentRef.current,
    estimateSize: () => 120,
    overscan: 5,
  });

  // Trigger next page fetch when scrolling near the end
  useEffect(() => {
    const lastItem = virtualizer.getVirtualItems().at(-1);
    if (!lastItem) return;

    if (
      lastItem.index >= allPosts.length - 1 &&
      hasNextPage &&
      !isFetchingNextPage
    ) {
      fetchNextPage();
    }
  }, [virtualizer.getVirtualItems(), hasNextPage, isFetchingNextPage, allPosts.length]);

  return (
    <div ref={parentRef} style={{ height: '100vh', overflow: 'auto' }}>
      <div style={{ height: `${virtualizer.getTotalSize()}px`, position: 'relative' }}>
        {virtualizer.getVirtualItems().map(virtualRow => {
          const isLoaderRow = virtualRow.index >= allPosts.length;

          return (
            <div
              key={virtualRow.key}
              style={{
                position: 'absolute',
                top: 0,
                left: 0,
                width: '100%',
                transform: `translateY(${virtualRow.start}px)`,
              }}
            >
              {isLoaderRow ? <Spinner /> : <PostCard post={allPosts[virtualRow.index]} />}
            </div>
          );
        })}
      </div>
    </div>
  );
}

When to Use Virtual Scroll

Very long lists (1K+ items already loaded)
Tables with thousands of rows (admin dashboards)
Combined with infinite scroll for memory-efficient infinite lists
Chat message history (Discord, Slack)

7.4 Frontend Pattern Comparison

Pattern	Trigger	UX	DOM Nodes	SEO	A11y
Page Numbers	Click page	Jump between pages	Small (1 page)	✅ `/page/3`	✅ Best
Infinite Scroll	Auto (scroll)	Seamless browsing	Grows unbounded	❌	⚠️ Needs ARIA
Load More	Click button	User-controlled	Grows unbounded	⚠️	✅
Virtual Scroll	Scroll	Smooth, fast	Fixed (~10-20)	❌	⚠️ Needs ARIA
Virtual + Infinite	Auto (scroll)	Best of both	Fixed (~10-20)	❌	⚠️ Needs ARIA

⬆ Back to Top

Comparison Table

Backend Strategies

Feature	Offset-Based	Cursor-Based	Keyset (Seek)	Page-Number
API Params	`offset`, `limit`	`after`, `first`	`last_id`, `limit`	`page`, `per_page`
SQL Technique	`LIMIT/OFFSET`	`WHERE + LIMIT`	`WHERE + LIMIT`	`LIMIT/OFFSET`
Deep Page Performance	❌ O(offset+limit)	✅ O(limit)	✅ O(limit)	❌ O(offset+limit)
Data Consistency	❌ Skip/duplicate	✅ Stable	✅ Stable	❌ Skip/duplicate
Random Page Access	✅ Jump to page N	❌ Sequential only	❌ Sequential only	✅ Jump to page N
Total Count	Optional (expensive)	Optional (expensive)	Optional (expensive)	Required
Implementation	Simple	Moderate	Moderate	Simple
Sorting Flexibility	✅ Any column	⚠️ Needs indexed sort	⚠️ Needs indexed sort	✅ Any column
Best For	Admin panels, search	Feeds, mobile apps	High-volume APIs	E-commerce, blogs

At a Glance

                     Random       Deep Page      Real-Time
                     Access?      Performance?   Consistency?

Offset/Page-Number:   ✅            ❌              ❌
Cursor-Based:         ❌            ✅              ✅
Keyset:               ❌            ✅              ✅

⬆ Back to Top

Real World Architecture Examples

9.1 Instagram Feed (Cursor + Infinite Scroll)

┌─────────────┐  GET /feed?after=cursor  ┌──────────────┐   WHERE (score, id) < (x, y)
│  Mobile App  │──────────────────────────►│  Feed Service │──────────────────────────────►│ DB │
│  (React      │◄──────────────────────────│  (generates  │◄──────────────────────────────│    │
│   Native)    │  { edges, pageInfo }      │   cursors)   │   LIMIT 10 (keyset seek)     └────┘
└─────────────┘                           └──────────────┘

Backend: Cursor-based (opaque cursor encoding score + post_id)
Frontend: Infinite scroll with Intersection Observer
Why: Feed is real-time (new posts constantly), deep pagination must be O(1), users never need "page 50"

9.2 Amazon Product Search (Offset + Page Numbers)

┌──────────┐  GET /search?q=laptop&page=3  ┌───────────────┐
│  Browser  │───────────────────────────────►│  Search API    │──►│ Elasticsearch │
│           │◄───────────────────────────────│  (from: 40,   │◄──│ (from/size)   │
└──────────┘  { results, total, page }      │   size: 20)   │   └───────────────┘
                                            └───────────────┘

Backend: Offset-based (Elasticsearch from/size internally)
Frontend: Page number navigation ("Page 3 of 150")
Why: Users want to jump to specific pages; product catalog changes infrequently relative to reads; Elasticsearch limits from to 10,000 max

9.3 Slack Messages (Keyset + Virtual Scroll)

┌──────────┐  GET /messages?before=ts_123&limit=50  ┌───────────────┐
│  Desktop  │───────────────────────────────────────►│  Message API   │
│  App      │◄───────────────────────────────────────│  (keyset on    │
│           │  { messages, has_more }                 │   timestamp)   │
└──────────┘                                        └───────────────┘

Frontend: Virtual scroll (only renders visible messages)
- Scroll up → loads older messages (fetch before=oldest_ts)
- Scroll down → loads newer messages (fetch after=newest_ts)
- Anchored scroll position on prepend

9.4 GitHub Issues (Hybrid: Cursor + Page Numbers)

GitHub's API supports both:

REST API (offset-based):
GET /repos/facebook/react/issues?page=3&per_page=30

GraphQL API (cursor-based):
query {
  repository(owner: "facebook", name: "react") {
    issues(first: 30, after: "Y3Vyc29yOnYyOpHOBj3...") {
      edges { node { title } cursor }
      pageInfo { hasNextPage endCursor }
    }
  }
}

⬆ Back to Top

Edge Cases and Gotchas

10.1 The COUNT(*) Problem

-- On a table with 50M rows:
SELECT COUNT(*) FROM posts;  -- ⏱️ 2-5 seconds on PostgreSQL!

Solutions:

Approximate count: SELECT reltuples FROM pg_class WHERE relname = 'posts';
Cached count: Store total in a separate counter table/Redis, update on insert/delete
Don't show total at all: Just show "Next" / "Previous" (Twitter, Instagram approach)
Cap it: "About 10,000 results" (Google approach after page ~40)

10.2 Cursor Stability with Changing Sort Orders

Problem: User sorts by "popularity" — scores change constantly.
Post A (score: 100) is on page 1.
User fetches page 2 with cursor pointing after Post A.
Post A's score drops to 5 — it would now be on page 50.
But cursor already passed it → NO DUPLICATE. ✅

New problem: Post Z's score jumps from 1 to 999.
It should now be on page 1, but cursor is past it → MISSED. ❌

Solution: For volatile sort orders, use offset-based pagination or accept eventual consistency.

10.3 Infinite Scroll Memory Management

// Problem: User scrolls through 5000 posts → DOM has 5000 nodes → 💀
// Solution 1: Virtual scroll (renders only ~20 nodes)
// Solution 2: Unload old pages:

const MAX_PAGES = 5; // only keep 5 pages in memory

const { data, fetchNextPage } = useInfiniteQuery({
  queryKey: ['posts'],
  queryFn: fetchPosts,
  // Remove old pages to limit memory
  maxPages: MAX_PAGES,
  getNextPageParam: (lastPage) => lastPage.pageInfo.endCursor,
});

10.4 SEO and Pagination

<!-- For page-number pagination, use rel="next"/"prev" and canonical -->
<link rel="canonical" href="https://example.com/posts?page=3" />
<link rel="prev" href="https://example.com/posts?page=2" />
<link rel="next" href="https://example.com/posts?page=4" />

// Next.js example
import Head from 'next/head';

function PostsPage({ page, totalPages }) {
  return (
    <Head>
      <link rel="canonical" href={`https://example.com/posts?page=${page}`} />
      {page > 1 && <link rel="prev" href={`https://example.com/posts?page=${page - 1}`} />}
      {page < totalPages && <link rel="next" href={`https://example.com/posts?page=${page + 1}`} />}
    </Head>
  );
}

Infinite scroll is not SEO-friendly — search engines can't trigger scroll events. Use SSR with page-number URLs as a fallback.

10.5 Race Conditions with Fast Scrolling

// Problem: User scrolls fast → multiple concurrent fetches → results arrive out of order

// Solution: AbortController
function usePaginatedPosts(page) {
  return useQuery({
    queryKey: ['posts', page],
    queryFn: ({ signal }) =>
      fetch(`/api/posts?page=${page}`, { signal }).then(r => r.json()),
    // TanStack Query automatically aborts previous request
    // when queryKey changes
  });
}

⬆ Back to Top

Interview Questions and Answers

Q1: What's the difference between offset-based and cursor-based pagination?

Answer:

Aspect	Offset	Cursor
Mechanism	Skip N rows (`OFFSET 40`)	Seek after a specific row (`WHERE id < cursor`)
Deep page perf	❌ O(offset + limit)	✅ O(limit)
Data consistency	❌ Items can be skipped/duplicated if data changes	✅ Stable — always continues from last seen item
Random access	✅ Can jump to any page	❌ Must traverse sequentially
Best for	Admin panels, search results	Social feeds, infinite scroll

Key insight: Offset = "give me rows 40–60." Cursor = "give me 20 rows after THIS item." Cursor is immune to inserts/deletes shifting positions.

Q2: How would you implement infinite scroll?

Answer:

API: Use cursor-based pagination (GET /posts?after=cursor&first=20).
Trigger: Use IntersectionObserver on a sentinel element near the bottom.
State Management: TanStack Query's useInfiniteQuery manages page accumulation.
Memory: Use virtual scrolling (@tanstack/react-virtual) for large lists to keep DOM node count constant.
Loading UX: Show skeleton placeholders while fetching.
End state: When hasNextPage is false, show "You've reached the end."
Error handling: Show retry button on failure, don't remove existing content.
Scroll restoration: Save position in sessionStorage for back/forward navigation.

Q3: When would you choose page numbers over infinite scroll?

Answer:

Choose Page Numbers When...	Choose Infinite Scroll When...
User needs to reach the footer	Content is exploratory (feeds, social)
SEO is important (crawlable URLs)	Mobile app (natural scroll gesture)
User wants to bookmark a specific page	Maximizing engagement metrics
Content has a clear total ("142 results")	Content is time-ordered (newest first)
Admin/data tables with sorting + filtering	No need to jump to specific position
E-commerce product listings

Q4: How does cursor-based pagination work under the hood?

Answer:

Cursor is an opaque string (usually Base64-encoded) containing sort key values.
Decoding eyJpZCI6MTAwfQ== → { "id": 100 }
Server uses this to build a WHERE clause:

-- Cursor decoded to id=100
SELECT * FROM posts WHERE id < 100 ORDER BY id DESC LIMIT 20;

Server encodes the last item's values as the new endCursor.
This is a keyset seek — it uses an index, so performance is O(limit), not O(offset + limit).
The cursor must include ALL columns used in the sort order + a unique tie-breaker:

-- Sort by created_at DESC, with id as tie-breaker
WHERE (created_at, id) < ($1, $2) ORDER BY created_at DESC, id DESC LIMIT 20;

Q5: How do you handle the COUNT(*) problem in pagination?

Answer:

COUNT(*) on large tables can take seconds. Strategies:

Avoid it entirely — Use cursor-based pagination with hasNextPage instead of "Page X of Y"
Approximate count — PostgreSQL: SELECT reltuples FROM pg_class; MySQL: SHOW TABLE STATUS
Cached count — Maintain a counter in Redis, increment/decrement on insert/delete
Materialized view — Pre-compute counts for filtered queries
Cap display — "About 10,000+ results" (stop counting after reaching a threshold)
Count in background — Return results immediately; send total count asynchronously

Q6: What's the problem with OFFSET 1000000?

Answer:

SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 1000000;

The database must:

Perform a full sort (or index scan) on created_at
Read and discard 1,000,000 rows
Return the next 20 rows

This is O(offset + limit) — linear time. On a table with 50M rows, OFFSET 1M scans ~1M index entries. It gets progressively slower as the user goes deeper.

Solutions:

Switch to keyset/cursor pagination for O(limit) performance
Enforce a max page depth (Google caps at ~page 40)
Use a covering index so the DB doesn't need table lookups for the offset scan

Q7: How would you build pagination for a real-time chat app?

Answer:

Bidirectional cursor pagination — user can scroll up (older messages) and down (newer messages).

API:
GET /messages?channel=general&before=cursor_A&limit=50  (older)
GET /messages?channel=general&after=cursor_B&limit=50   (newer)

Frontend approach:

Load initial batch (latest 50 messages)
Scroll up → fetch older messages with before cursor
New messages arrive via WebSocket → append at bottom
Virtual scroll to handle thousands of messages efficiently
Anchor scroll position — when prepending older messages, maintain the user's scroll position so they don't jump

// Anchor scroll on prepend
function usePrependScrollAnchor(containerRef, data) {
  const prevScrollHeight = useRef(0);

  useLayoutEffect(() => {
    const el = containerRef.current;
    if (prevScrollHeight.current > 0) {
      // Adjust scroll position by the difference in height
      el.scrollTop += el.scrollHeight - prevScrollHeight.current;
    }
    prevScrollHeight.current = el.scrollHeight;
  }, [data]);
}

Q8: How do you make infinite scroll accessible?

Answer:

ARIA role="feed" — Announces the feed to screen readers
aria-busy="true" while fetching
aria-setsize and aria-posinset on each article (or -1 if total unknown)
Focus management — Don't steal focus on auto-load; let screen reader users navigate naturally
Announce new content — Use a live region: <div aria-live="polite">20 more posts loaded</div>
Provide alternative — Offer a "View All Pages" link for traditional pagination
Keyboard navigation — Ensure items are focusable and follow logical tab order

<div role="feed" aria-busy={isFetching} aria-label="News feed">
  {posts.map((post, i) => (
    <article
      key={post.id}
      aria-setsize={-1}
      aria-posinset={i + 1}
      tabIndex={0}
    >
      <PostCard post={post} />
    </article>
  ))}

  {/* Screen reader announcement */}
  <div aria-live="polite" className="sr-only">
    {isFetching ? 'Loading more posts...' : ''}
  </div>
</div>

Q9: Compare REST pagination vs GraphQL pagination.

Answer:

REST — Offset style:

GET /api/posts?page=2&per_page=20

{
  "data": [...],
  "meta": { "page": 2, "totalPages": 50 }
}

REST — Cursor style:

GET /api/posts?after=abc123&limit=20

{
  "data": [...],
  "next_cursor": "def456",
  "has_more": true
}

GraphQL — Relay Connection Spec (cursor):

query {
  posts(first: 20, after: "abc123") {
    edges {
      node { id title }
      cursor
    }
    pageInfo {
      hasNextPage
      endCursor
    }
    totalCount
  }
}

Feature	REST Offset	REST Cursor	GraphQL Relay
Standardization	No standard	No standard	Relay Connection Spec
Client flexibility	Fixed fields	Fixed fields	Client picks fields
Page metadata	Custom	Custom	Standardized `pageInfo`
Caching	Easy (URL-based)	Hard (cursor changes)	Normalized cache (Apollo)

Q10: Explain pagination in Elasticsearch / search engines.

Answer:

Elasticsearch supports multiple strategies:

from / size (offset-based): Limited to 10,000 hits by default.

   { "from": 40, "size": 20, "query": { "match": { "title": "react" } } }

search_after (keyset): For deep pagination.

   { "size": 20, "search_after": [1609459200, "post-123"], "sort": [{ "date": "desc" }, { "id": "desc" }] }

Scroll API: For processing all results (batch jobs, not user-facing).

   { "scroll": "5m", "size": 1000, "query": { "match_all": {} } }

Point-in-Time (PIT): Consistent snapshot for paginating through changing data.

Frontend rule: Use from/size for pages 1–500. Switch to search_after beyond that. Never expose Scroll API to end users.

Bonus: Quick Decision Reference

Scenario	Backend Strategy	Frontend Pattern
Social media feed	Cursor	Infinite Scroll
E-commerce product grid	Offset / Page-number	Page Numbers
Admin data table	Offset / Keyset	Page Numbers + Sorting
Chat messages (load older)	Cursor (bidirectional)	Virtual + Load on scroll up
Search results	Offset (capped) + Keyset fallback	Page Numbers
Activity log / audit trail	Cursor	Load More
Image gallery	Cursor	Infinite + Virtual Grid
Blog / documentation	Page-number	Page Numbers (SEO)
Notification list	Cursor	Load More
Analytics dashboard table	Offset	Page Numbers + Export

Interview Tip: When asked "How would you paginate X?", structure your answer as:

Identify the data pattern — Static or real-time? How large? User access pattern?

Pick the backend strategy — Offset for random access, Cursor for streams

Pick the frontend pattern — Page numbers, infinite scroll, load more, virtual scroll

Address edge cases — COUNT(*) cost, consistency, SEO, accessibility, scroll position

Mention performance — Index design, caching, memory management

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Authentication Flows -- Guide

ZeeshanAli-0704 — Thu, 12 Mar 2026 12:58:05 +0000

Authentication Flows — Frontend System Design Guide

A comprehensive guide to authentication flows (Session, JWT, OAuth 2.0, SSO) from a frontend engineer's perspective.

Authentication vs Authorization
Session Based Authentication
JWT (JSON Web Token) Authentication
OAuth 2.0
Single Sign On (SSO)
Comparison Table Auth Flows
Interview Cheat Sheet

⬆ Back to Top

Authentication vs Authorization

Concept	Authentication (AuthN)	Authorization (AuthZ)
What	Who are you?	What can you do?
When	At login / token exchange	On every protected resource access
Example	Entering username + password	Checking if user has `admin` role
Frontend role	Collect credentials, store tokens	Guard routes, hide/show UI per role

⬆ Back to Top

Session Based Authentication

How It Works

┌──────────┐         ┌──────────────┐         ┌──────────┐
│  Browser  │──POST──▶│   Server     │──────▶  │   DB /   │
│           │ /login  │  (creates    │         │  Session  │
│           │◀─Set────│   session)   │◀────────│  Store    │
│           │ Cookie  │              │         │ (Redis)   │
└──────────┘         └──────────────┘         └──────────┘

Subsequent requests carry the session cookie automatically.

Concept

User submits credentials (username + password).
Server validates, creates a session in a store (memory, Redis, DB).
Server sends back a session ID inside a Set-Cookie header.
Browser automatically attaches this cookie on every subsequent request.
Server reads session ID → looks up session store → identifies user.

Code — Express Server (Session Auth)

// server.js — session-based auth with express-session
const express = require("express");
const session = require("express-session");
const app = express();

app.use(express.json());
app.use(
  session({
    secret: "my-secret-key",
    resave: false,
    saveUninitialized: false,
    cookie: {
      httpOnly: true,   // JS cannot access this cookie
      secure: true,     // only sent over HTTPS
      sameSite: "lax",  // CSRF protection
      maxAge: 1000 * 60 * 30, // 30 min
    },
  })
);

// Login
app.post("/login", (req, res) => {
  const { username, password } = req.body;
  const user = authenticateUser(username, password); // your DB check
  if (!user) return res.status(401).json({ error: "Invalid credentials" });

  req.session.userId = user.id; // store user in session
  res.json({ message: "Logged in" });
});

// Protected route
app.get("/profile", (req, res) => {
  if (!req.session.userId) return res.status(401).json({ error: "Not authenticated" });
  res.json({ userId: req.session.userId });
});

// Logout
app.post("/logout", (req, res) => {
  req.session.destroy(() => {
    res.clearCookie("connect.sid");
    res.json({ message: "Logged out" });
  });
});

Code — Frontend (Session Auth)

// login.js — browser side
async function login(username, password) {
  const res = await fetch("/login", {
    method: "POST",
    credentials: "include", // ← IMPORTANT: sends cookies cross-origin
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ username, password }),
  });
  return res.json();
}

async function getProfile() {
  const res = await fetch("/profile", {
    credentials: "include", // cookie sent automatically
  });
  return res.json();
}

Pros & Cons

✅ Pros	❌ Cons
Simple & battle-tested	Server must store session (stateful)
Revocation is instant (delete session)	Hard to scale horizontally without shared store (Redis)
Cookie sent automatically by browser	Vulnerable to CSRF if `SameSite` not set
HttpOnly cookie = safe from XSS token theft	Not ideal for mobile apps / cross-domain APIs

⬆ Back to Top

JWT (JSON Web Token) Authentication

How It Works (Overview)

┌──────────┐         ┌──────────────┐
│  Browser  │──POST──▶│   Server     │
│           │ /login  │  (creates    │
│           │◀─JSON───│   JWT)       │  No session store needed!
│  stores   │  token  │              │
│  token    │         └──────────────┘
└──────────┘
     │
     │  Authorization: Bearer <token>
     ▼
┌──────────────┐
│   Server     │  Verifies signature → extracts payload
│  (stateless) │
└──────────────┘

JWT Auth Flow — Step by Step

┌──────────┐                              ┌──────────────┐
│  Browser  │                              │    Server     │
└────┬─────┘                              └──────┬───────┘
     │                                           │
     │──1. POST /login ─────────────────────────▶│
     │   { username, password }                  │
     │                                           │
     │                          2. Validate credentials against DB
     │                          3. Generate Access Token (short: 15m)
     │                             + Refresh Token (long: 7d)
     │                                           │
     │◀─4. Response ─────────────────────────────│
     │   Body: { accessToken: "eyJ..." }         │
     │   Set-Cookie: refreshToken=eyJ...         │
     │   (HttpOnly, Secure, SameSite)            │
     │                                           │
     │  5. Store access token                    │
     │     in memory (JS variable)               │
     │                                           │
     │──6. GET /api/profile ────────────────────▶│
     │   Header: Authorization: Bearer eyJ...    │
     │                                           │
     │                          7. Verify signature (HMAC/RSA)
     │                          8. Check exp claim (not expired?)
     │                          9. Extract payload { userId, role }
     │                                           │
     │◀─10. Response { user: { ... } } ─────────│
     │                                           │

── When Access Token Expires (after ~15 min) ──

     │──11. GET /api/data ──────────────────────▶│
     │   Header: Authorization: Bearer eyJ...    │
     │                                           │
     │◀─12. 401 Unauthorized (token expired) ────│
     │                                           │
     │──13. POST /refresh ──────────────────────▶│
     │   Cookie: refreshToken=eyJ... (auto-sent) │
     │                                           │
     │                         14. Verify refresh token
     │                         15. Issue NEW access token
     │                             (optionally rotate refresh token)
     │                                           │
     │◀─16. { accessToken: "new_eyJ..." } ──────│
     │                                           │
     │  17. Retry original request               │
     │      with new access token                │
     │──18. GET /api/data ──────────────────────▶│
     │   Header: Authorization: Bearer new_eyJ.. │
     │                                           │
     │◀─19. 200 OK { data: [...] } ─────────────│

Key points:

Step 1–4: Login returns two tokens — a short-lived access token (in response body) and a long-lived refresh token (as HttpOnly cookie).
Step 5: Access token is stored in memory (JS variable) — NOT in localStorage. This prevents XSS from stealing it.
Step 6–9: Every API request sends the access token in the Authorization: Bearer header. Server verifies the signature and expiry without hitting a database — that's why it's stateless.
Steps 11–19: When the access token expires, the client silently refreshes using the refresh token cookie. The user never sees a login screen. This is typically done via an Axios interceptor or a fetchWithAuth wrapper.

Why two tokens? The access token is short-lived (15 min) to limit damage if stolen. The refresh token is long-lived but stored in an HttpOnly cookie (JS can't read it) and only sent to the /refresh endpoint.

Concept

A JWT has three parts separated by dots:

header.payload.signature

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiJ9.HMAC_SIGNATURE
│                      │                                          │
│  Header              │  Payload (claims)                        │  Signature
│  { alg, typ }        │  { userId, role, exp, iat }              │  HMAC(header+payload, secret)

Header — algorithm + token type
Payload — claims (user data, expiry, issuer)
Signature — ensures the token was not tampered with

⚠️ JWT is encoded, NOT encrypted. Anyone can decode the payload. Never put secrets in it.

Code — Server (JWT Auth)

const jwt = require("jsonwebtoken");
const SECRET = process.env.JWT_SECRET; // keep this safe!

// Login — issue tokens
app.post("/login", (req, res) => {
  const user = authenticateUser(req.body.username, req.body.password);
  if (!user) return res.status(401).json({ error: "Invalid credentials" });

  const accessToken = jwt.sign(
    { userId: user.id, role: user.role },
    SECRET,
    { expiresIn: "15m" }  // short-lived
  );

  const refreshToken = jwt.sign(
    { userId: user.id },
    SECRET,
    { expiresIn: "7d" }   // long-lived
  );

  // Send refresh token as HttpOnly cookie
  res.cookie("refreshToken", refreshToken, {
    httpOnly: true,
    secure: true,
    sameSite: "strict",
    maxAge: 7 * 24 * 60 * 60 * 1000,
  });

  res.json({ accessToken }); // access token in response body
});

// Middleware — verify JWT
function authMiddleware(req, res, next) {
  const authHeader = req.headers.authorization; // "Bearer <token>"
  if (!authHeader) return res.status(401).json({ error: "No token" });

  const token = authHeader.split(" ")[1];
  try {
    const decoded = jwt.verify(token, SECRET);
    req.user = decoded; // { userId, role, iat, exp }
    next();
  } catch (err) {
    return res.status(401).json({ error: "Invalid or expired token" });
  }
}

app.get("/profile", authMiddleware, (req, res) => {
  res.json({ user: req.user });
});

Code — Frontend (JWT with Refresh Token Rotation)

// auth.js — token management on the client
let accessToken = null;

async function login(username, password) {
  const res = await fetch("/login", {
    method: "POST",
    credentials: "include", // for refresh token cookie
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ username, password }),
  });
  const data = await res.json();
  accessToken = data.accessToken; // store in memory (NOT localStorage)
}

// Wrapper with auto-refresh
async function fetchWithAuth(url, options = {}) {
  let res = await fetch(url, {
    ...options,
    headers: {
      ...options.headers,
      Authorization: `Bearer ${accessToken}`,
    },
  });

  // If 401, try refreshing
  if (res.status === 401) {
    const refreshRes = await fetch("/refresh", {
      method: "POST",
      credentials: "include", // sends refresh token cookie
    });

    if (refreshRes.ok) {
      const data = await refreshRes.json();
      accessToken = data.accessToken;

      // Retry original request with new token
      res = await fetch(url, {
        ...options,
        headers: {
          ...options.headers,
          Authorization: `Bearer ${accessToken}`,
        },
      });
    } else {
      // Refresh failed — force logout
      window.location.href = "/login";
    }
  }

  return res;
}

Where to Store JWT on the Frontend?

Storage	XSS Safe?	CSRF Safe?	Recommendation
`localStorage`	❌ JS can read it	✅ Not sent automatically	Avoid — XSS can steal tokens
`sessionStorage`	❌ JS can read it	✅ Not sent automatically	Slightly better (tab-scoped)
`HttpOnly Cookie`	✅ JS cannot read it	❌ Sent automatically	Best — combine with CSRF token
In-memory variable	✅ Hard to steal	✅ Not sent automatically	Best for access token — lost on refresh

Best Practice: Access token in memory, refresh token in HttpOnly secure cookie.

Pros & Cons

✅ Pros	❌ Cons
Stateless — no server-side session store	Cannot revoke a specific token easily
Works great for APIs, mobile, microservices	Larger payload than session ID
Can carry claims (roles, permissions)	Must handle token refresh logic
Scales horizontally easily	If secret is leaked, all tokens are compromised

⬆ Back to Top

OAuth 2.0

Concept

OAuth 2.0 is a delegation protocol — it lets a user grant a third-party app limited access to their resources without sharing their password.

Key Actors:

Role	Example
Resource Owner	The user (you)
Client	Your frontend app
Authorization Server	Google, GitHub, Auth0
Resource Server	Google API, GitHub API

Authorization Code Flow (Most Secure — for web apps)

┌──────────┐                        ┌─────────────────┐
│  Browser  │──1. Click "Login"────▶│  Authorization  │
│  (Client) │   (redirect directly  │  Server         │
│           │    to Auth Server)    │  (Google/GitHub) │
│           │                       │                 │
│           │──2. User logs in ────▶│                 │
│           │   & grants consent    │                 │
│           │◀─3. Redirect back ────│                 │
│           │   to YOUR app with    └─────────────────┘
│           │   AUTH CODE (in URL)
│           │
│           │──4. Send auth code──▶┌─────────────────┐
│           │   (to your backend)  │  Your Server    │
│           │                      │  (Backend)      │
│           │                      │                 │
│           │                      │──5. code→token──▶ Auth Server
│           │                      │   + client_secret│
│           │                      │◀─ access_token──│
│           │                      │   + id_token    │
│           │◀─6. Set session/JWT──│                 │
└──────────┘                      └─────────────────┘

Key points:

Step 1: The browser redirects directly to the Authorization Server (Google, GitHub, etc.) — your backend is NOT involved yet.
Step 2: The user logs in at the Auth Server's page (e.g. Google's login screen) and grants consent (e.g. "Allow this app to access your profile & email"). Your app never sees the user's Google/GitHub password.
Step 3: After login + consent, the Auth Server redirects back to your app's callback URL with a short-lived authorization code in the query string (?code=abc123).
Steps 4–5: Your backend exchanges the code for tokens. This is where the client_secret is used — it never leaves the server.
Why the code exchange? The access token is never exposed to the browser. Only the backend sees it.

Code — Step 1: Redirect User to OAuth Provider

// frontend — initiate OAuth login
function loginWithGoogle() {
  const params = new URLSearchParams({
    client_id: "YOUR_CLIENT_ID",
    redirect_uri: "https://yourapp.com/callback",
    response_type: "code",          // Authorization Code flow
    scope: "openid profile email",
    state: generateRandomState(),   // CSRF protection
  });
  window.location.href = `https://accounts.google.com/o/oauth2/v2/auth?${params}`;
}

// Generate random state for CSRF mitigation
function generateRandomState() {
  const state = crypto.randomUUID();
  sessionStorage.setItem("oauth_state", state);
  return state;
}

Code — Step 2: Handle Callback (Backend)

// server.js — handle OAuth callback
app.get("/callback", async (req, res) => {
  const { code, state } = req.query;

  // Verify state to prevent CSRF
  if (state !== expectedState) return res.status(403).send("Invalid state");

  // Exchange authorization code for tokens
  const tokenRes = await fetch("https://oauth2.googleapis.com/token", {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded" },
    body: new URLSearchParams({
      code,
      client_id: process.env.GOOGLE_CLIENT_ID,
      client_secret: process.env.GOOGLE_CLIENT_SECRET, // NEVER expose to frontend
      redirect_uri: "https://yourapp.com/callback",
      grant_type: "authorization_code",
    }),
  });

  const { access_token, id_token, refresh_token } = await tokenRes.json();

  // Decode id_token to get user info (or call /userinfo endpoint)
  const userInfo = jwt.decode(id_token); // { sub, email, name, picture }

  // Create session or issue your own JWT
  req.session.user = {
    id: userInfo.sub,
    email: userInfo.email,
    name: userInfo.name,
  };

  res.redirect("/dashboard");
});

Code — Step 3: Protected Route on Frontend (React)

// ProtectedRoute.jsx
import { Navigate } from "react-router-dom";
import { useAuth } from "./AuthContext";

export function ProtectedRoute({ children }) {
  const { user, isLoading } = useAuth();

  if (isLoading) return <div>Loading...</div>;
  if (!user) return <Navigate to="/login" replace />;

  return children;
}

// Usage in router
<Route path="/dashboard" element={
  <ProtectedRoute>
    <Dashboard />
  </ProtectedRoute>
} />

OAuth 2.0 Flow Variants

Flow	Use Case	Token exposed to browser?
Authorization Code	Server-side web apps	❌ No (most secure)
Authorization Code + PKCE	SPAs, mobile apps (no client_secret)	Access token in memory
Implicit (deprecated)	Legacy SPAs	✅ Yes (insecure)
Client Credentials	Machine-to-machine	N/A (no user)
Resource Owner Password (deprecated)	Trusted first-party apps only	✅ Yes

PKCE (Proof Key for Code Exchange) — For SPAs

Why PKCE Exists

The standard Authorization Code flow relies on a client_secret to exchange the code for tokens. But SPAs and mobile apps are public clients — their code runs entirely on the user's device, so there's no safe place to store a secret.

Without PKCE, if an attacker intercepts the authorization code (e.g. via a malicious browser extension, redirect hijack, or OS-level URL scheme interception on mobile), they can exchange it for tokens since no secret is needed.

PKCE solves this by proving that the app that started the flow is the same app finishing it — using a one-time cryptographic challenge.

How PKCE Works (Step by Step)

┌──────────────┐                              ┌─────────────────┐
│  Browser/SPA │                              │  Authorization  │
│              │                              │  Server         │
│  1. Generate │                              │                 │
│  code_verifier                              │                 │
│  (random)    │                              │                 │
│              │                              │                 │
│  2. Hash it: │                              │                 │
│  code_challenge                             │                 │
│  = SHA256(   │                              │                 │
│    verifier) │                              │                 │
│              │                              │                 │
│  3. Redirect │──/authorize?──────────────▶  │                 │
│              │  code_challenge=abc123        │  4. Auth Server │
│              │  code_challenge_method=S256   │  stores the     │
│              │  client_id=...               │  code_challenge  │
│              │  redirect_uri=...            │  alongside the   │
│              │                              │  auth code       │
│              │  (User logs in & consents)   │                 │
│              │                              │                 │
│              │◀─redirect with AUTH CODE──── │                 │
│              │  ?code=xyz789                │                 │
│              │                              │                 │
│  5. Exchange │──POST /token ─────────────▶  │  6. Auth Server │
│     code     │  code=xyz789                 │  computes       │
│              │  code_verifier=original_rand │  SHA256(verifier)│
│              │  client_id=...               │  and checks:    │
│              │                              │  SHA256(verifier)│
│              │                              │  == stored       │
│              │                              │  code_challenge? │
│              │                              │                 │
│              │◀─ access_token ──────────────│  ✅ Match! Issue │
│              │   + id_token                 │  tokens          │
└──────────────┘                              └─────────────────┘

The Cryptographic Proof

code_verifier  = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"   ← random string (kept secret in browser)
                         │
                    SHA-256 hash
                         │
                         ▼
code_challenge = "E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM"   ← sent to auth server

Attacker intercepts the auth code but does NOT have the code_verifier.
When they try to exchange the code → Auth server says: "Prove it. Send the verifier." → ❌ Fails.

Without PKCE	With PKCE
Attacker intercepts `?code=xyz`	Attacker intercepts `?code=xyz`
Attacker calls `/token` with the code	Attacker calls `/token` with the code
✅ Gets tokens (no secret needed)	❌ Rejected — can't provide matching `code_verifier`

Code — Generate PKCE Pair

// pkce.js — generate code_verifier + code_challenge

async function generatePKCE() {
  // 1. Generate random code_verifier (43-128 chars, URL-safe)
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  const codeVerifier = base64URLEncode(array);

  // 2. Create code_challenge = SHA256(code_verifier), base64url-encoded
  const digest = await crypto.subtle.digest(
    "SHA-256",
    new TextEncoder().encode(codeVerifier)
  );
  const codeChallenge = base64URLEncode(new Uint8Array(digest));

  return { codeVerifier, codeChallenge };
}

function base64URLEncode(buffer) {
  return btoa(String.fromCharCode(...buffer))
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/, "");
}

Code — Step 1: Start Auth Flow with Challenge

async function loginWithPKCE() {
  const { codeVerifier, codeChallenge } = await generatePKCE();

  // Store verifier — we'll need it after redirect
  sessionStorage.setItem("pkce_verifier", codeVerifier);

  const params = new URLSearchParams({
    client_id: "YOUR_CLIENT_ID",
    redirect_uri: "https://yourapp.com/callback",
    response_type: "code",
    scope: "openid profile email",
    code_challenge: codeChallenge,         // ← hashed verifier
    code_challenge_method: "S256",          // ← tells server we used SHA-256
    state: crypto.randomUUID(),             // ← CSRF protection
  });

  // Redirect user to auth server
  window.location.href = `https://auth-server.com/authorize?${params}`;
}

Code — Step 2: Exchange Code with Verifier (After Redirect)

async function handleCallback() {
  const params = new URLSearchParams(window.location.search);
  const code = params.get("code");
  const codeVerifier = sessionStorage.getItem("pkce_verifier");

  // Exchange auth code + code_verifier for tokens
  const res = await fetch("https://auth-server.com/token", {
    method: "POST",
    headers: { "Content-Type": "application/x-www-form-urlencoded" },
    body: new URLSearchParams({
      grant_type: "authorization_code",
      code,
      redirect_uri: "https://yourapp.com/callback",
      client_id: "YOUR_CLIENT_ID",
      code_verifier: codeVerifier,  // ← proof we started the flow
    }),
  });

  if (!res.ok) throw new Error("Token exchange failed");

  const { access_token, id_token } = await res.json();

  // Clean up
  sessionStorage.removeItem("pkce_verifier");

  // Store access_token in memory (NOT localStorage)
  return { access_token, id_token };
}

When to Use PKCE

Client Type	Has `client_secret`?	Use PKCE?
SPA (React, Vue, Angular)	❌ No	✅ Yes (required)
Mobile app (iOS, Android)	❌ No	✅ Yes (required)
Desktop app (Electron)	❌ No	✅ Yes (required)
Server-side web app	✅ Yes	✅ Recommended (defense in depth)
Machine-to-machine	✅ Yes	❌ Not applicable (no user)

Best Practice (2024+): OAuth 2.1 draft spec requires PKCE for ALL authorization code flows, even for confidential clients with a client_secret. It's defense in depth.

⬆ Back to Top

Single Sign On (SSO)

What Is SSO?

SSO (Single Sign-On) allows a user to authenticate once with a central Identity Provider (IdP) and then access multiple independent applications without logging in again.

Real-world example:

You log in at accounts.google.com once.
You can now visit Gmail, YouTube, Google Drive, Google Docs — all without re-entering your password.
That's SSO.

Key Terminology

Term	Meaning	Example
IdP (Identity Provider)	The central server that authenticates users and issues identity assertions	Okta, Auth0, Azure AD, Google Accounts
SP (Service Provider)	The app that trusts the IdP and relies on its assertions	Gmail, Your internal CRM, HR portal
SSO Session	A session cookie at the IdP's domain that proves "this user already authenticated"	Cookie on `accounts.google.com`
App Session	A local session/token in each SP after the IdP confirms identity	Cookie on `mail.google.com`
Assertion	The identity proof the IdP gives to the SP	SAML XML assertion or OIDC `id_token` (JWT)
Federated Identity	A user identity that is shared/trusted across security domains	Your company Google account working across all SaaS tools

How SSO Works — The Big Picture

┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│    App A      │    │    App B      │    │    App C      │
│  mail.com     │    │  drive.com    │    │  crm.com      │
│               │    │               │    │               │
│  Has its own  │    │  Has its own  │    │  Has its own  │
│  app session  │    │  app session  │    │  app session  │
└──────┬────────┘    └──────┬────────┘    └──────┬────────┘
       │                    │                    │
       │    "Is this user   │                    │
       │     logged in?"    │                    │
       └────────────────────┼────────────────────┘
                            │
                    ┌───────▼────────┐
                    │   Identity     │
                    │   Provider     │
                    │   (IdP)        │
                    │                │
                    │  ● Authenticates│
                    │    the user    │
                    │  ● Maintains   │
                    │    SSO session │
                    │  ● Issues      │
                    │    assertions  │
                    └────────────────┘

SSO Flow — Step by Step (First App Login)

User visits App A for the first time (not logged in anywhere)

┌──────┐         ┌──────────┐         ┌─────────────────┐
│ User │         │  App A   │         │  IdP            │
│      │         │  (SP)    │         │  (sso.company   │
│      │         │          │         │   .com)         │
└──┬───┘         └────┬─────┘         └───────┬─────────┘
   │                  │                       │
   │──1. Visit app──▶│                       │
   │  (no session)    │                       │
   │                  │──2. Redirect to IdP──▶│
   │                  │  "User not authed,    │
   │                  │   go log in"          │
   │◀─────────────────│                       │
   │  (302 redirect)  │                       │
   │                  │                       │
   │──3. Browser goes to IdP ──────────────▶ │
   │   (no SSO session cookie yet)           │
   │                  │                       │
   │◀─4. IdP shows login page ──────────────│
   │                  │                       │
   │──5. User enters credentials ──────────▶│
   │   (username + password / MFA)           │
   │                  │                       │
   │                  │         6. IdP validates credentials
   │                  │            Creates SSO SESSION COOKIE
   │                  │            on sso.company.com domain
   │                  │                       │
   │◀─7. Redirect back to App A ─────────── │
   │   WITH identity assertion               │
   │   (auth code, SAML assertion, or token) │
   │                  │                       │
   │──8. Land at ───▶│                       │
   │   App A callback │                       │
   │                  │──9. Validate assertion│
   │                  │   (or exchange code   │
   │                  │    for tokens)        │
   │                  │                       │
   │                  │──10. Create LOCAL ─── │
   │                  │   app session for     │
   │                  │   App A               │
   │                  │                       │
   │◀─11. Logged in!──│                       │
   │   (App A session │                       │
   │    cookie set)   │                       │

SSO Flow — Subsequent App (Already Logged In at IdP)

This is where the magic happens:

User visits App B (already authenticated at IdP from App A login)

┌──────┐         ┌──────────┐         ┌─────────────────┐
│ User │         │  App B   │         │  IdP            │
│      │         │  (SP)    │         │  (sso.company   │
│      │         │          │         │   .com)         │
└──┬───┘         └────┬─────┘         └───────┬─────────┘
   │                  │                       │
   │──1. Visit app──▶│                       │
   │  (no App B      │                       │
   │   session)      │                       │
   │                  │──2. Redirect to IdP──▶│
   │◀─────────────────│                       │
   │                  │                       │
   │──3. Browser goes to IdP ──────────────▶ │
   │   (SSO session cookie EXISTS! ✅)       │
   │                  │                       │
   │                  │         4. IdP checks SSO session
   │                  │            → User already authenticated!
   │                  │            → NO login page shown
   │                  │                       │
   │◀─5. IMMEDIATELY redirect back ──────── │
   │   to App B with assertion               │
   │   (user never saw a login screen!)      │
   │                  │                       │
   │──6. Land at ───▶│                       │
   │   App B callback │                       │
   │                  │──7. Validate, create──│
   │                  │   App B session       │
   │                  │                       │
   │◀─8. Logged in!──│                       │
   │   (seamless!)   │                       │

Key insight: The SSO magic is the IdP session cookie. When the browser is redirected to the IdP, the browser automatically sends this cookie. The IdP sees "oh, this user already authenticated" and immediately redirects back — no login screen.

SSO Protocols Compared

	SAML 2.0	OpenID Connect (OIDC)	CAS
Format	XML assertions	JWT tokens (built on OAuth 2.0)	Ticket-based
Transport	Browser redirect (POST/Redirect binding)	Browser redirect + backend token exchange	Browser redirect
Token	SAML Assertion (XML, signed)	`id_token` (JWT) + `access_token`	Service Ticket
Common In	Enterprise (Okta, ADFS, Salesforce)	Modern web/mobile (Auth0, Google, Azure)	Universities
Complexity	High (XML parsing, certificate management)	Medium (JSON, standard HTTP)	Low-Medium
Mobile Friendly	❌ Poor (XML, browser-dependent)	✅ Great (JSON, token-based)	❌ Poor
Year Introduced	2005	2014	2004

SAML 2.0 SSO Flow (Enterprise)

┌──────┐         ┌──────────┐         ┌─────────────────┐
│ User │         │  SP      │         │  IdP            │
│      │         │(your app)│         │  (Okta/ADFS)    │
└──┬───┘         └────┬─────┘         └───────┬─────────┘
   │──Visit app──────▶│                       │
   │                  │──SAML AuthnRequest───▶│  (XML, base64-encoded
   │                  │  (who are you? prove  │   in URL or POST form)
   │                  │   this user's identity)│
   │                  │                       │
   │   (User logs in at IdP if needed)       │
   │                  │                       │
   │                  │◀─SAML Response────────│  (XML, digitally signed)
   │                  │  Contains:            │
   │                  │  • NameID (user email) │
   │                  │  • Attributes (roles) │
   │                  │  • Signature          │
   │                  │  • Conditions (expiry)│
   │                  │                       │
   │                  │  SP validates XML     │
   │                  │  signature against    │
   │                  │  IdP's public cert    │
   │                  │                       │
   │◀─Logged in!──────│                       │

OIDC SSO Flow (Modern — Recommended)

┌──────┐         ┌──────────┐         ┌─────────────────┐
│ User │         │  SP      │         │  IdP            │
│      │         │(your app)│         │  (Auth0/Google)  │
└──┬───┘         └────┬─────┘         └───────┬─────────┘
   │──Visit app──────▶│                       │
   │                  │──/authorize───────────▶│  (standard OAuth 2.0
   │                  │  response_type=code   │   authorization request)
   │                  │  scope=openid profile │
   │                  │                       │
   │   (User logs in at IdP if needed)       │
   │                  │                       │
   │                  │◀─?code=abc123─────────│  (redirect with auth code)
   │                  │                       │
   │                  │──POST /token──────────▶│  (backend exchanges code)
   │                  │  code + client_secret │
   │                  │                       │
   │                  │◀─────────────────────│
   │                  │  {                    │
   │                  │    access_token: "...",│
   │                  │    id_token: "eyJ...", │ ← JWT with user identity
   │                  │    refresh_token:"..." │
   │                  │  }                    │
   │                  │                       │
   │                  │  Decode id_token:     │
   │                  │  { sub, email, name,  │
   │                  │    iss, aud, exp }    │
   │                  │                       │
   │◀─Logged in!──────│                       │

SSO Session vs App Session — The Two Layers

This is a crucial concept people often miss:

┌─────────────────────────────────────────────────────┐
│                    IdP Domain                        │
│                 sso.company.com                      │
│                                                     │
│   ┌─────────────────────────────────────┐           │
│   │  SSO Session Cookie                 │           │
│   │  (e.g. "sso_sid=abc123")           │           │
│   │  Domain: sso.company.com           │           │
│   │  Lives as long as IdP decides      │           │
│   │  (e.g. 8 hours for a work day)     │           │
│   └─────────────────────────────────────┘           │
└─────────────────────────────────────────────────────┘

┌─────────────────────┐  ┌─────────────────────┐  ┌─────────────────────┐
│  App A Domain       │  │  App B Domain       │  │  App C Domain       │
│  mail.company.com   │  │  crm.company.com    │  │  hr.company.com     │
│                     │  │                     │  │                     │
│  App Session Cookie │  │  App Session Cookie │  │  App Session Cookie │
│  (independent!)     │  │  (independent!)     │  │  (independent!)     │
│  maxAge: 30min      │  │  maxAge: 1hr        │  │  maxAge: 15min      │
└─────────────────────┘  └─────────────────────┘  └─────────────────────┘

Layer	Where	Controlled By	Purpose
SSO Session	IdP's domain cookie	IdP (Okta, Auth0)	Proves "this user authenticated at the IdP"
App Session	Each app's own cookie/token	Each SP individually	Proves "this user is logged into THIS app"

Important: Deleting App A's session does NOT affect App B or the SSO session. Deleting the SSO session means future redirects to the IdP will require re-login, but existing app sessions remain until they expire.

How the Frontend Triggers SSO

From the frontend's perspective, initiating SSO is just a redirect:

window.location.href = "https://sso.company.com/authorize?client_id=...&redirect_uri=...&scope=openid"

Key parameters in the redirect URL:

Parameter	Purpose
`client_id`	Identifies your app to the IdP
`redirect_uri`	Where to send the user after auth
`response_type=code`	Requests an authorization code
`scope=openid profile email`	What user info you want
`state`	Random string for CSRF protection
`prompt=none`	Skip login screen if SSO session exists (silent check)
`prompt=login`	Force login screen even if SSO session exists

After authentication, the IdP redirects back to your redirect_uri with an authorization code. Your backend exchanges this code for tokens (same as OAuth 2.0 Authorization Code flow).

The `prompt` Parameter — Key to SSO UX

Value	Behavior	Use Case
(omitted)	Show login if no SSO session, skip if session exists	Default — best for most cases
`none`	Never show login UI. If no SSO session → return `error=login_required`	Silent checks, iframe-based renewal
`login`	Always show login UI, even if SSO session exists	Force re-authentication (sensitive actions)
`consent`	Always show consent screen	Re-authorize permissions

Silent Token Renewal

When the access token expires, you can silently get a new one without showing a login screen — as long as the SSO session at the IdP is still active.

How it works:

┌──────────────┐                          ┌──────────────┐
│  Your App    │                          │     IdP      │
│              │                          │              │
│  Token       │   ┌─────────────────┐    │              │
│  expired!    │──▶│ Hidden <iframe>  │──▶│              │
│              │   │ src=/authorize?  │   │  SSO cookie  │
│              │   │ prompt=none      │   │  exists? ✅  │
│              │   │                  │◀──│  Issue new   │
│              │   │ Gets code via    │   │  auth code   │
│              │   │ redirect in      │   │              │
│              │   │ iframe           │   │              │
│              │   └────────┬────────┘    │              │
│              │            │             │              │
│              │◀─postMessage(token)──    │              │
│              │                          │              │
│  New token!  │                          │              │
│  Continue    │                          │              │
│  working     │                          │              │
└──────────────┘                          └──────────────┘

The process:

Your app creates a hidden iframe pointing to the IdP's /authorize endpoint with prompt=none.
The browser sends the IdP's SSO session cookie along with the iframe request.
If the SSO session is valid, the IdP redirects the iframe to your callback URL with a new auth code.
The callback page inside the iframe uses postMessage to send the code/token back to the parent window.
Your app schedules the next renewal ~60 seconds before the new token expires.

If the SSO session has expired: The IdP returns error=login_required, and your app redirects the user to the full login page.

Note: Some modern IdPs also support refresh tokens as an alternative to iframe-based silent renewal, avoiding iframe-related issues (CSP restrictions, third-party cookie blocking).

SSO Logout — The Hard Part

Logout in SSO is more complex than login because you need to consider all apps the user accessed.

The problem: User clicks "Logout" in App A. But they also have active sessions in App B and App C. What happens to those?

Logout Strategies

Strategy	How	Pros	Cons
Local Logout Only	Destroy only the current app's session	Simple	User still logged in to other apps & IdP
IdP Logout (RP-Initiated)	Redirect user to IdP's `/logout` endpoint	Clears SSO session, prevents future silent logins	Other apps still have active local sessions until they expire
Front-Channel Logout	IdP renders a page with hidden iframes to each SP's logout URL	All apps get notified via browser	Unreliable (blocked iframes, CSP rules, ad blockers)
Back-Channel Logout	IdP sends server-to-server HTTP POST to each SP's logout webhook	Most reliable, no browser dependency	Each SP must expose a logout endpoint

Front-Channel Logout (via browser)

User clicks "Logout"
         │
         ▼
┌────────────────────┐
│  IdP Logout Page   │
│                    │
│  Renders hidden    │
│  iframes:          │
│  ┌───────────────┐ │
│  │ <iframe>      │ │    → app-a.com/logout → destroys App A session
│  │ <iframe>      │ │    → app-b.com/logout → destroys App B session
│  │ <iframe>      │ │    → app-c.com/logout → destroys App C session
│  └───────────────┘ │
│                    │
│  Then redirect to  │
│  post-logout URL   │
└────────────────────┘

Back-Channel Logout (server-to-server — most reliable)

┌─────────────────┐
│      IdP        │
│                 │
│  User logged    │──POST → app-a.com/backchannel-logout  { logout_token: "eyJ..." }
│  out            │──POST → app-b.com/backchannel-logout  { logout_token: "eyJ..." }
│                 │──POST → app-c.com/backchannel-logout  { logout_token: "eyJ..." }
└─────────────────┘

Each SP validates the logout_token JWT → destroys the matching session.

Best Practice for SSO Logout

Redirect user to IdP's /logout endpoint (RP-initiated logout).
Configure back-channel logout on each SP so the IdP can notify them server-to-server.
Keep app session lifetimes short (15–60 min) as a safety net — even if logout notification fails, sessions expire quickly.

SSO — Common Real-World Architectures

Architecture	Example	How Apps Share Identity
Subdomain SSO	`*.company.com`	Shared cookie on `.company.com` domain
Central IdP (OIDC/SAML)	Okta + various SaaS apps	Each app redirects to Okta for auth
Token-based SSO	Microservices behind API gateway	Gateway validates JWT, forwards claims
Social Login SSO	"Login with Google" across indie apps	Each app is a separate OIDC client

SSO Pros & Cons

✅ Pros	❌ Cons
Users log in once, access everything	Single point of failure (IdP goes down = all apps down)
Centralized user management (disable one account = disabled everywhere)	Complex logout (must notify all SPs)
Consistent security policies (MFA, password rules) in one place	Increased security risk if IdP is compromised
Better UX — no password fatigue	Initial setup complexity (SAML certs, OIDC config)
Easier compliance & audit trail	Token/session lifetime management across apps

SSO Interview Quick Reference

Q: How does SSO work without sharing cookies across domains?

The IdP maintains its own session cookie on its domain. Each app redirects to the IdP. The browser sends the IdP's cookie automatically. If valid, the IdP redirects back with an assertion — no cross-domain cookie sharing needed.

Q: What happens if the SSO session expires but an app session is still active?

The app continues working until its own session expires. Next time the app tries to silently renew via the IdP, it will fail (login_required), and the user will need to re-authenticate.

Q: SAML vs OIDC — when to use which?

SAML: Legacy enterprise integrations, apps that only support SAML (Salesforce, older SaaS). OIDC: Everything new — SPAs, mobile apps, microservices. It's simpler, JSON-based, and mobile-friendly.

Q: How do you handle SSO logout properly?

Best approach: back-channel logout (IdP sends server-to-server calls to each SP). Fallback: RP-initiated logout (redirect user to IdP /logout which triggers front-channel iframes). Always set short app session lifetimes as a safety net.

⬆ Back to Top

Comparison Table Auth Flows

Feature	Session-Based	JWT	OAuth 2.0	SSO (OIDC)
Stateful/Stateless	Stateful	Stateless	Depends	Depends
Token Storage	Cookie (session ID)	Memory / Cookie	Backend stores tokens	Cookie / Memory
Scalability	Needs shared session store	Excellent	Excellent	Excellent
Revocation	Instant	Hard (need blocklist)	Revoke at auth server	Revoke at IdP
Best For	Traditional web apps	APIs, microservices	Third-party login	Enterprise multi-app
Complexity	Low	Medium	High	High
Cross-Domain	Hard (cookies)	Easy (header-based)	Built for it	Built for it

⬆ Back to Top

Interview Cheat Sheet

Quick Answers for System Design Interviews

Q: Where should I store tokens on the frontend?

Access token in memory (JS variable). Refresh token in an HttpOnly, Secure, SameSite cookie.

Q: JWT vs Session — when to pick which?

Session for traditional server-rendered apps (simple, instant revocation).

JWT for APIs serving multiple clients (mobile, SPA, microservices) where statelessness matters.

Q: What is PKCE and why?

PKCE prevents authorization code interception for public clients (SPAs, mobile) that can't securely store a client_secret.

Q: How does silent token renewal work in SSO?

Hidden iframe hits the IdP's /authorize endpoint with prompt=none. If the SSO session is still active, a new token is returned via postMessage.

Q: OAuth 2.0 vs OpenID Connect?

OAuth 2.0 handles authorization (what can you access). OIDC adds an identity layer on top (who are you) via the id_token.

Further Reading:

OAuth 2.0 RFC 6749

JWT RFC 7519

OWASP Top 10

Frontend Security Guide — XSS, CSRF, CORS, CSP, and more

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Network Optimization – Performance

ZeeshanAli-0704 — Thu, 12 Mar 2026 12:56:38 +0000

Network Optimization – Frontend Performance

Network optimization focuses on reducing the number, size, and latency of HTTP requests. Even with perfectly optimized assets, poor network strategy can bottleneck performance.

HTTP 2 and HTTP 3
Resource Hints (preload, prefetch, preconnect, dns prefetch)
Caching Strategies
Compression (Gzip, Brotli)
CDN (Content Delivery Network)
Bundle Splitting and Code Splitting
Service Workers and Offline Caching
103 Early Hints
Stale While Revalidate Deep Dive
Key Takeaways ⬆ Back to Top

HTTP 2 and HTTP 3

Concept:
HTTP/1.1 sends requests one at a time per connection (head-of-line blocking). HTTP/2 and HTTP/3 remove this bottleneck with multiplexing, allowing many requests over a single connection.

Evolution:

Feature	HTTP/1.1	HTTP/2	HTTP/3
Multiplexing	No (1 req/connection)	Yes (many streams)	Yes (many streams)
Header compression	No	HPACK	QPACK
Server Push	No	Yes (deprecated in Chrome 106)	Spec allows, but no browser implements
Transport	TCP	TCP	QUIC (UDP-based)
Head-of-line blocking	Per connection	Per TCP connection	None (per-stream)
Connection setup	TCP + TLS (2-3 RTT)	TCP + TLS (2-3 RTT)	0-1 RTT

Note on Server Push: HTTP/2 Server Push was designed to let the server proactively send resources before the browser requested them. However, Chrome removed Server Push support in Chrome 106 (October 2022) due to low adoption and complexity. No major browser actively supports it in practice. Use <link rel="preload"> or 103 Early Hints (see Section 8) instead.

Impact on optimization strategy:

In HTTP/1.1 era:

Concatenate files (fewer requests better)
Use CSS sprites
Domain sharding (multiple domains for parallel downloads)

In HTTP/2+ era:

Smaller, granular files are fine (multiplexing handles many requests)
CSS sprites are less necessary
Domain sharding actually hurts (breaks multiplexing)
Focus on reducing total bytes, not total requests

Verification:

// Check HTTP protocol version in browser DevTools
// Network tab → Right-click header → Enable "Protocol" column
// Look for h2 (HTTP/2) or h3 (HTTP/3)

// Performance API check
const entries = performance.getEntriesByType('resource');
entries.forEach(entry => {
  console.log(entry.name, entry.nextHopProtocol);
  // Output: "script.js" "h2" or "h3"
});

⬆ Back to Top

Resource Hints (preload, prefetch, preconnect, dns prefetch)

Concept:
Resource hints tell the browser about resources it will need soon, allowing it to start fetching or connecting earlier than it normally would.

Four resource hints:

Hint	Purpose	Priority	When to Use
`dns-prefetch`	Resolve DNS for a domain	Low	Third-party domains
`preconnect`	DNS + TCP + TLS handshake	Medium	Critical third-party origins
`preload`	Download specific resource NOW	High	Critical current-page resources
`prefetch`	Download resource for NEXT page	Low	Next-page navigation resources

Example – All four in practice:

<head>
  <!-- DNS Prefetch: resolve domain name early -->
  <link rel="dns-prefetch" href="https://analytics.example.com">

  <!-- Preconnect: full connection setup to critical third-party -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://cdn.example.com" crossorigin>

  <!-- Preload: fetch critical resources for THIS page immediately -->
  <link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/css/critical.css" as="style">
  <link rel="preload" href="/images/hero.webp" as="image">

  <!-- Prefetch: fetch resources for NEXT likely page -->
  <link rel="prefetch" href="/next-page/bundle.js" as="script">
  <link rel="prefetch" href="/next-page/data.json" as="fetch">
</head>

Timeline comparison:

Without hints:
  HTML → Parse → Discover CSS → Download CSS → Parse CSS → Discover font → Download font
                                                                            ^^^^ Very late

With preconnect + preload:
  HTML → Preconnect to CDN + Preload font (parallel with everything)
      → Parse → Discover CSS → Download CSS (connection already open!)
      → Font already downloading or downloaded
  Savings: 200-500ms per resource

Best practices:

Limit preconnect to 2-4 critical origins (each one costs CPU)
Preload only resources needed within first 3 seconds
Prefetch only highly likely next-page resources
dns-prefetch is cheap, use for all known third-party domains
Over-using preload can hurt – it competes with other critical resources

⬆ Back to Top

Caching Strategies

Concept:
Caching stores responses locally so repeat visits or requests do not require network round-trips. An effective caching strategy can make second visits near-instant.

Two levels of caching:

1. Browser Cache (HTTP Cache Headers):

Cache-Control: public, max-age=31536000, immutable

Directive	Meaning
`public`	Any cache (browser, CDN) can store
`private`	Only browser can store (user-specific data)
`max-age=N`	Cache is valid for N seconds
`immutable`	File will never change (skip revalidation)
`no-cache`	Always revalidate with server before using
`no-store`	Never cache (sensitive data)
`stale-while-revalidate=N`	Use stale cache while revalidating in background

Recommended cache strategy by file type:

HTML pages:
  Cache-Control: no-cache
  (Always check for latest version, server may return 304 Not Modified)

CSS/JS with hash in filename (main.a1b2c3.js):
  Cache-Control: public, max-age=31536000, immutable
  (Cache forever – filename changes when content changes)

Images:
  Cache-Control: public, max-age=86400
  (Cache for 1 day – or use immutable with hashed filenames)

API responses:
  Cache-Control: private, max-age=0, must-revalidate
  (User-specific, always fresh)

Fonts:
  Cache-Control: public, max-age=31536000, immutable
  (Fonts rarely change)

2. ETag / Last-Modified (Conditional Requests):

First request:
  Server → ETag: "abc123"
  Browser caches response

Second request:
  Browser → If-None-Match: "abc123"
  Server checks: file unchanged → 304 Not Modified (no body, saves bandwidth)
  Server checks: file changed → 200 OK with new content

⬆ Back to Top

Compression (Gzip, Brotli)

Concept:
Text-based assets (HTML, CSS, JS, JSON, SVG) are compressed on the server before transmission. The browser decompresses them automatically. This reduces transfer size by 60-90%.

Compression comparison:

Algorithm	Compression Ratio	Speed	Browser Support
None	1x (baseline)	N/A	Universal
Gzip	5-8x smaller	Fast	Universal
Brotli	6-10x smaller	Slower to compress	96%+ browsers

Typical savings:

Asset	Original	Gzip	Brotli
React bundle (200KB)	200KB	55KB	45KB
CSS file (100KB)	100KB	18KB	15KB
JSON API (50KB)	50KB	8KB	6KB

Server configuration examples:

# Nginx – Enable both Brotli and Gzip
# Brotli (preferred)
brotli on;
brotli_types text/html text/css application/javascript application/json image/svg+xml;
brotli_comp_level 6;

# Gzip (fallback)
gzip on;
gzip_types text/html text/css application/javascript application/json image/svg+xml;
gzip_min_size 256;

How browser negotiation works:

Browser sends:
  Accept-Encoding: br, gzip, deflate

Server responds with best match:
  Content-Encoding: br       (if Brotli supported)
  Content-Encoding: gzip     (fallback if not)

Build-time pre-compression (Webpack):

const CompressionPlugin = require('compression-webpack-plugin');

module.exports = {
  plugins: [
    // Gzip
    new CompressionPlugin({
      algorithm: 'gzip',
      filename: '[path][base].gz',
    }),
    // Brotli
    new CompressionPlugin({
      algorithm: 'brotliCompress',
      filename: '[path][base].br',
      compressionOptions: { level: 11 },
    }),
  ],
};

Benefits of pre-compression:

Server serves pre-compressed files instantly (no CPU cost per request)
Can use maximum Brotli level 11 (too slow for real-time, but fine for build)
Gzip as fallback for older clients

⬆ Back to Top

CDN (Content Delivery Network)

Concept:
A CDN distributes copies of your assets to servers spread across the globe (edge locations). Users fetch assets from the nearest edge server instead of your origin server, reducing latency dramatically.

How CDN reduces latency:

Without CDN:
  User in Tokyo → Request to origin in US → 200ms RTT
  Total for CSS + JS + images = 200ms x 10 resources = 2000ms

With CDN:
  User in Tokyo → Request to CDN edge in Tokyo → 10ms RTT
  Total for CSS + JS + images = 10ms x 10 resources = 100ms
  (Plus HTTP/2 multiplexing reduces this further)

What to serve from CDN:

Static assets: CSS, JS, images, fonts, videos
Build artifacts with content hashes
Third-party libraries

What NOT to serve from CDN:

HTML pages that change frequently (or use short cache + stale-while-revalidate)
User-specific or authenticated content
Real-time API endpoints

CDN configuration example (Cloudflare):

Page Rules:
  *.example.com/static/*
    Cache Level: Cache Everything
    Edge Cache TTL: 1 month
    Browser Cache TTL: 1 year

  example.com/*.html
    Cache Level: Standard
    Edge Cache TTL: 10 minutes

Multi-CDN strategy:

Use primary CDN for your assets
Use specialized Image CDN for image optimization
Use separate CDN for video streaming
Implement failover between CDNs

⬆ Back to Top

Bundle Splitting and Code Splitting

Concept:
Instead of sending one massive JavaScript bundle, split it into smaller chunks that load on demand. Users only download the code they actually need for the current page or interaction.

Types of splitting:

Strategy	What It Does	Example
Vendor splitting	Separate third-party libraries	React, Lodash → vendor.js
Route splitting	Separate code per page/route	/home → home.js, /about → about.js
Component splitting	Lazy load heavy components	Modal, Chart → separate chunks

Webpack vendor splitting:

// webpack.config.js
module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'all',
      cacheGroups: {
        vendor: {
          test: /[\\/]node_modules[\\/]/,
          name: 'vendor',
          chunks: 'all',
          priority: 10,
        },
        common: {
          minChunks: 2,
          name: 'common',
          chunks: 'all',
          priority: 5,
        },
      },
    },
  },
};

React route-based code splitting:

import { lazy, Suspense } from 'react';
import { BrowserRouter, Routes, Route } from 'react-router-dom';

// Each route loads its own chunk
const Home = lazy(() => import('./pages/Home'));
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Settings = lazy(() => import('./pages/Settings'));

function App() {
  return (
    <BrowserRouter>
      <Suspense fallback={<PageLoader />}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/dashboard" element={<Dashboard />} />
          <Route path="/settings" element={<Settings />} />
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

Result:

/ loads home.[hash].js (~30KB)
/dashboard loads dashboard.[hash].js (~80KB)
/settings loads settings.[hash].js (~20KB)
User visiting only / never downloads dashboard or settings code

Component-level splitting:

import { lazy, Suspense, useState } from 'react';

// Heavy chart library (~200KB) loaded only when user opens analytics
const AnalyticsChart = lazy(() => import('./AnalyticsChart'));

function Dashboard() {
  const [showAnalytics, setShowAnalytics] = useState(false);

  return (
    <div>
      <h1>Dashboard</h1>
      <button onClick={() => setShowAnalytics(true)}>Show Analytics</button>

      {showAnalytics && (
        <Suspense fallback={<ChartSkeleton />}>
          <AnalyticsChart />
        </Suspense>
      )}
    </div>
  );
}

⬆ Back to Top

Service Workers and Offline Caching

Concept:
A Service Worker is a JavaScript file that runs in the background, separate from the web page. It intercepts network requests and can serve cached responses, enabling offline functionality and instant repeat loads.

Service Worker lifecycle:

1. Register → Browser downloads and installs the SW
2. Install → SW caches critical assets (precaching)
3. Activate → SW takes control of pages
4. Fetch → SW intercepts every network request and decides: cache or network

Basic Service Worker registration:

// main.js – Register service worker
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered:', reg.scope))
    .catch(err => console.log('SW registration failed:', err));
}

Service Worker with caching strategies:

// sw.js
const CACHE_NAME = 'app-v1';
const PRECACHE_ASSETS = [
  '/',
  '/css/main.css',
  '/js/app.js',
  '/images/logo.svg',
  '/offline.html',
];

// Install: precache critical assets
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => cache.addAll(PRECACHE_ASSETS))
  );
});

// Activate: clean old caches
self.addEventListener('activate', event => {
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(keys.filter(k => k !== CACHE_NAME).map(k => caches.delete(k)))
    )
  );
});

// Fetch: serve from cache, fallback to network
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      if (cached) return cached;               // Cache hit
      return fetch(event.request).then(response => {
        // Cache new resources for next time
        const clone = response.clone();
        caches.open(CACHE_NAME).then(cache => cache.put(event.request, clone));
        return response;
      });
    }).catch(() => caches.match('/offline.html'))  // Offline fallback
  );
});

Common caching strategies:

Strategy	Behavior	Best For
Cache First	Check cache → fallback to network	Static assets, fonts, images
Network First	Check network → fallback to cache	API data, HTML pages
Stale While Revalidate	Serve cache immediately → update cache from network	Frequently updated content
Cache Only	Only cache, never network	Precached app shell
Network Only	Only network, never cache	Real-time data, auth

Workbox (Google's SW library) example:

// sw.js using Workbox
import { precacheAndRoute } from 'workbox-precaching';
import { registerRoute } from 'workbox-routing';
import { CacheFirst, StaleWhileRevalidate, NetworkFirst } from 'workbox-strategies';
import { ExpirationPlugin } from 'workbox-expiration';

// Precache build assets
precacheAndRoute(self.__WB_MANIFEST);

// Cache images: Cache First, expire after 30 days
registerRoute(
  ({ request }) => request.destination === 'image',
  new CacheFirst({
    cacheName: 'images',
    plugins: [new ExpirationPlugin({ maxEntries: 100, maxAgeSeconds: 30 * 24 * 60 * 60 })],
  })
);

// Cache API: Network First
registerRoute(
  ({ url }) => url.pathname.startsWith('/api/'),
  new NetworkFirst({ cacheName: 'api-cache' })
);

// Cache CSS/JS: Stale While Revalidate
registerRoute(
  ({ request }) => request.destination === 'style' || request.destination === 'script',
  new StaleWhileRevalidate({ cacheName: 'static-resources' })
);

⬆ Back to Top

103 Early Hints

Concept:
103 Early Hints is an HTTP status code that allows the server to send preload and preconnect hints to the browser before the final response is ready. While the server is still computing the full response (querying a database, rendering HTML), it can immediately tell the browser to start fetching critical resources.

The problem without Early Hints:

Browser ──── GET /page ────────────► Server
                                      │
                                      │  Processing... (500ms)
                                      │  DB query, render HTML
                                      │
Browser ◄──── 200 OK + HTML ──────── Server
  │
  │  NOW discovers <link rel="preload" href="/style.css">
  │  NOW discovers <link rel="preconnect" href="https://fonts.googleapis.com">
  │
  │── GET /style.css ─────────────►
  │── DNS+TCP+TLS to fonts.gstatic ►

With 103 Early Hints:

Browser ──── GET /page ────────────► Server
                                      │
Browser ◄── 103 Early Hints ──────── Server (sent immediately!)
  │   Link: </style.css>; rel=preload; as=style
  │   Link: <https://fonts.googleapis.com>; rel=preconnect
  │
  │── GET /style.css ─────────────►  (starts NOW, in parallel with server processing)
  │── DNS+TCP+TLS to fonts.gstatic ► (starts NOW)
  │                                   │
  │                                   │  Server still processing... (500ms)
  │                                   │
Browser ◄──── 200 OK + HTML ──────── Server
  │
  │  style.css already downloaded! ✅
  │  fonts.googleapis.com already connected! ✅

Savings: 200-500ms off critical resource loading — the browser gets a head start during time that was previously wasted waiting.

Server implementation (Node.js):

app.get('/page', (req, res) => {
  // Send 103 Early Hints immediately
  res.writeEarlyHints({
    link: [
      '</css/main.css>; rel=preload; as=style',
      '</fonts/body.woff2>; rel=preload; as=font; crossorigin',
      '<https://api.example.com>; rel=preconnect',
    ],
  });

  // Now do the slow work
  const data = await fetchFromDatabase();
  const html = renderPage(data);
  res.status(200).send(html);
});

Nginx configuration:

location / {
  http2_push_preload on;  # Converts Link headers to 103 Early Hints
  add_header Link "</css/main.css>; rel=preload; as=style" early;
  add_header Link "</js/app.js>; rel=preload; as=script" early;
}

Browser support: Chrome 103+, Edge 103+, Firefox 102+. Safari does not yet support 103.

When to use 103 Early Hints:

Scenario	Use 103?	Why
Server takes > 200ms to generate HTML	✅ Yes	Browser wastes time waiting — give it a head start
Pages with known critical resources	✅ Yes	CSS, fonts, key API endpoints are predictable
Static HTML served from CDN	❌ No	Response is fast enough, no idle time to exploit
Highly dynamic resource URLs	❌ No	Server doesn't know which resources to hint

103 Early Hints vs Server Push: Early Hints replaced Server Push as the recommended way to get resources to the browser early. Unlike Server Push (which was removed from Chrome), Early Hints simply tells the browser what to fetch — the browser retains full control and can skip resources it already has cached.

⬆ Back to Top

Stale While Revalidate Deep Dive

Concept:
The stale-while-revalidate Cache-Control directive allows the browser to immediately serve a cached (stale) response while simultaneously fetching a fresh copy from the network in the background. The next request gets the updated version.

This is one of the most powerful caching directives because it gives you instant loads (from cache) with eventual freshness (background update).

How it works:

Cache-Control: max-age=600, stale-while-revalidate=3600

Timeline:
┌─────────────────┬──────────────────────────────┬──────────────┐
│  0 – 600s       │  600s – 4200s                │  After 4200s │
│  (max-age)      │  (stale-while-revalidate)    │              │
│                 │                              │              │
│  Serve from     │  Serve stale IMMEDIATELY     │  Must fetch  │
│  cache directly │  + revalidate in background  │  from network│
│  (no network)   │  (user gets instant response)│  (slow)      │
└─────────────────┴──────────────────────────────┴──────────────┘

Practical examples:

# API responses – fresh for 1 minute, serve stale for up to 1 hour while revalidating
Cache-Control: public, max-age=60, stale-while-revalidate=3600

# Static assets with version hashing – long cache, moderate SWR window
Cache-Control: public, max-age=86400, stale-while-revalidate=604800

# User profile data – short freshness, but cached response OK briefly
Cache-Control: private, max-age=30, stale-while-revalidate=300

Server configuration (Nginx):

location /api/ {
  proxy_cache_valid 200 60s;
  add_header Cache-Control "public, max-age=60, stale-while-revalidate=3600";
}

CDN configuration (Cloudflare, Vercel):

Most CDN edge servers also honor stale-while-revalidate at the edge layer, meaning the CDN serves stale content to users while fetching a fresh copy from your origin in the background.

# Vercel (vercel.json)
{
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        {
          "key": "Cache-Control",
          "value": "public, max-age=60, stale-while-revalidate=3600"
        }
      ]
    }
  ]
}

When to use stale-while-revalidate:

Resource Type	Recommended Value	Why
API responses (feeds, listings)	`max-age=60, s-w-r=3600`	Instant load, background refresh
CMS/blog content	`max-age=3600, s-w-r=86400`	Content changes rarely, instant revisits
User avatars / profile images	`max-age=300, s-w-r=86400`	Rarely change, OK to serve stale briefly
Auth / payment endpoints	Never use	Always needs fresh data
Hashed static assets (main.a1b2c3.js)	Not needed	Use `immutable` instead — content never changes per URL

Key insight for interviews: stale-while-revalidate at the HTTP layer is the same philosophy as React's useSWR hook and TanStack Query's staleTime — return cached data instantly, refresh in the background.

⬆ Back to Top

Key Takeaways

Leverage HTTP/2+ multiplexing (many small files are fine, avoid bundling everything)
Use resource hints strategically: preconnect for critical origins, preload for critical assets, prefetch for next-page resources
Cache aggressively with content-hashed filenames (max-age=31536000, immutable)
Enable Brotli compression (Gzip as fallback) – 60-90% smaller text assets
Serve static assets from CDN edge locations for minimal latency
Split bundles by vendor, route, and component – users download only what they need
Use Service Workers for offline support, instant repeat loads, and background sync

Performance Metrics Impact

Optimization	LCP	FCP	TTI	TTFB
HTTP/2-3	+	+	+	++
Resource hints	++	++	+	+
Caching	+++	+++	+++	+++
Compression	+	+	+	++
CDN	++	++	+	+++
Code splitting			+++
Service Workers	+++	+++	+++	+++

+++ = Major impact, ++ = Moderate impact, + = Minor impact

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: CSS, JavaScript & UI Optimization – Performance

ZeeshanAli-0704 — Thu, 12 Mar 2026 12:55:29 +0000

CSS, JavaScript & UI Optimization – Frontend Performance

CSS and JavaScript are render-blocking resources by default. The browser cannot paint anything until CSS is parsed (CSSOM) and synchronous JS is executed. Optimizing how these resources load is critical for First Contentful Paint (FCP) and Time to Interactive (TTI).

Critical CSS Rendering
Non Critical CSS (Async Loading)
Lazy Loading CSS (Media Based)
JS Based CSS Loading
Async and Defer Strategy
Module Loading and Tree Shaking
Configurable UI (Conditional Rendering)
Streaming UI Rendering
Avoiding import and Eliminating Dead CSS
Key Takeaways

⬆ Back to Top

Critical CSS Rendering

Concept:
Extract only the CSS rules needed to render above-the-fold content and inline them directly in the HTML. The rest of the CSS loads asynchronously. This eliminates the render-blocking CSS download for initial paint.

Normal CSS loading:

HTML downloaded
  → External CSS file requested (blocks rendering)
  → Entire CSS downloaded (50-200KB)
  → CSSOM built
  → First paint happens
  ⏱ Total blocking time: 200-800ms

With Critical CSS:

HTML downloaded (includes inlined critical CSS ~5-15KB)
  → CSSOM for above-the-fold built immediately
  → First paint happens FAST
  → Full CSS loads asynchronously in background
  ⏱ Total blocking time: ~0ms

Example:

<head>
  <!-- Critical CSS inlined -->
  <style>
    /* Only above-the-fold styles (~5-15KB) */
    body { margin: 0; font-family: system-ui, sans-serif; }
    .header { background: #1a1a2e; color: white; padding: 16px; }
    .hero { max-width: 1200px; margin: 0 auto; padding: 40px 20px; }
    .hero h1 { font-size: 2.5rem; margin-bottom: 16px; }
    .hero img { width: 100%; height: auto; }
  </style>

  <!-- Full CSS loads asynchronously -->
  <link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>

How to extract Critical CSS automatically:

// Using the 'critical' npm package in build step
const critical = require('critical');

critical.generate({
  inline: true,
  base: 'dist/',
  src: 'index.html',
  target: 'index-critical.html',
  width: 1300,
  height: 900,
  dimensions: [
    { width: 414, height: 896 },   // Mobile
    { width: 1300, height: 900 }   // Desktop
  ]
});

Tools for Critical CSS extraction:

critical (npm) – Automated extraction and inlining
critters (Webpack plugin) – Build-time critical CSS
penthouse – Headless browser-based extraction
Next.js – Automatic CSS inlining for pages

⬆ Back to Top

Non Critical CSS (Async Loading)

Concept:
CSS that is not needed for the initial viewport (below-the-fold styles, modal styles, footer styles) should load without blocking rendering.

Technique 1 – Preload then apply:

<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="non-critical.css"></noscript>

How it works:

rel="preload" downloads the file without applying it
onload fires when download completes
this.rel='stylesheet' applies the CSS
this.onload=null prevents infinite loop in some browsers
noscript fallback for JavaScript-disabled browsers

Technique 2 – Media attribute trick:

<!-- Browser downloads but does not apply (media doesn't match) -->
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">

How it works:

media="print" tells browser this CSS is only for printing → non-blocking
Browser still downloads it (lower priority)
onload fires → this.media='all' applies it for all media types

⬆ Back to Top

Lazy Loading CSS (Media Based)

Concept:
Load CSS files only under specific conditions using the media attribute. The browser downloads all stylesheets but only applies those whose media query matches.

Example – Load only when conditions match:

<!-- Always loaded and applied -->
<link rel="stylesheet" href="base.css">

<!-- Downloaded but applied ONLY when printing -->
<link rel="stylesheet" href="print.css" media="print">

<!-- Applied only on screens wider than 768px -->
<link rel="stylesheet" href="desktop.css" media="(min-width: 768px)">

<!-- Applied only in portrait orientation -->
<link rel="stylesheet" href="portrait.css" media="(orientation: portrait)">

<!-- Applied only when user prefers dark mode -->
<link rel="stylesheet" href="dark-theme.css" media="(prefers-color-scheme: dark)">

Key behavior:

Browser downloads ALL linked stylesheets regardless of media match
But non-matching stylesheets are downloaded at lowest priority
Non-matching stylesheets do NOT block rendering
This is a native browser optimization, no JavaScript needed

Practical example – Conditional component CSS:

<!-- Critical above-the-fold styles – render-blocking (intentional) -->
<link rel="stylesheet" href="header.css">
<link rel="stylesheet" href="hero.css">

<!-- Below-the-fold – non-blocking via media trick -->
<link rel="stylesheet" href="footer.css" media="print" onload="this.media='all'">
<link rel="stylesheet" href="comments.css" media="print" onload="this.media='all'">

⬆ Back to Top

JS Based CSS Loading

Concept:
Use JavaScript to load additional stylesheets after the initial page render. This gives complete programmatic control over when and which CSS files are loaded.

Example – Dynamic stylesheet injection:

// Load CSS after page is interactive
function loadCSS(href) {
  const link = document.createElement('link');
  link.rel = 'stylesheet';
  link.href = href;
  document.head.appendChild(link);
}

// Load non-critical styles after DOM is ready
document.addEventListener('DOMContentLoaded', () => {
  loadCSS('/css/animations.css');
  loadCSS('/css/below-fold.css');
});

Example – Load CSS on user interaction:

// Load modal styles only when modal is triggered
document.querySelector('.open-modal').addEventListener('click', () => {
  loadCSS('/css/modal.css');
  // Then open modal after styles are ready
}, { once: true });

Example – Load CSS based on feature detection:

// Load CSS only if the browser supports a feature
if ('IntersectionObserver' in window) {
  loadCSS('/css/lazy-images.css');
}

// Load CSS based on viewport
if (window.innerWidth > 1024) {
  loadCSS('/css/desktop-sidebar.css');
}

Benefits:

Complete control over loading conditions
Load styles only when actually needed
Avoid blocking page render with unused CSS
Can combine with feature detection and user interaction

⬆ Back to Top

Async and Defer Strategy

Concept:
By default, <script> tags block HTML parsing. The browser stops building the DOM, downloads the script, executes it, then resumes parsing. async and defer change this behavior.

Three loading modes:

Normal <script>:
HTML parsing ████████░░░░░░░░░░░████████████
Script download      ░░░█████░░░░░░░░
Script execution         ░░░░░███░░░░░

async <script>:
HTML parsing ████████████████░░░█████████████
Script download  ░░░█████░░░░░░░░░░░
Script execution         ░░░███░░░░░░░

defer <script>:
HTML parsing ████████████████████████████████
Script download  ░░░█████░░░░░░░░░░░░░░░░░░
Script execution                             ███
                                             ^ After HTML parsing complete

Comparison:

Feature	Normal	async	defer
Blocks HTML parsing	Yes	Only during execution	No
Download	Sequential	Parallel	Parallel
Execution timing	Immediately	When downloaded	After DOM ready
Execution order	Ordered	NOT guaranteed	Guaranteed order
DOMContentLoaded	Waits for script	May fire before/after	Fires after scripts

Example:

<head>
  <!-- Critical: must run before DOM (rare) -->
  <script src="critical-polyfill.js"></script>

  <!-- Analytics: order doesn't matter, run when ready -->
  <script src="analytics.js" async></script>
  <script src="tracking.js" async></script>

  <!-- App scripts: need DOM, order matters -->
  <script src="vendor.js" defer></script>
  <script src="utils.js" defer></script>
  <script src="app.js" defer></script>
</head>

When to use which:

Use Case	Strategy
Third-party analytics/ads	`async`
Chat widgets, social embeds	`async`
Main app bundle	`defer`
Library dependencies (React, Vue)	`defer`
Critical polyfills	Normal (no attribute)
A/B testing scripts	Normal (must run before render)

⬆ Back to Top

Module Loading and Tree Shaking

Concept:
ES Modules enable the browser (and bundlers) to understand dependency relationships between files. This unlocks tree shaking – the ability to remove unused code from the final bundle.

ES Module loading in browser:

<!-- Module script: automatically deferred, strict mode -->
<script type="module" src="app.js"></script>

<!-- Fallback for old browsers -->
<script nomodule src="app-legacy.js"></script>

Module behavior:

type="module" scripts are deferred by default (no need for defer)
They run in strict mode automatically
They support import / export syntax
nomodule is ignored by modern browsers, runs in legacy browsers

Tree shaking example:

// math.js – Library with multiple exports
export function add(a, b) { return a + b; }
export function subtract(a, b) { return a - b; }
export function multiply(a, b) { return a * b; }
export function divide(a, b) { return a / b; }

// app.js – Only imports 'add'
import { add } from './math.js';
console.log(add(2, 3));

// After tree shaking:
// subtract, multiply, divide are REMOVED from bundle
// Only 'add' function is included

Requirements for tree shaking to work:

Must use ES Module syntax (import / export)
Must NOT use CommonJS (require / module.exports)
Bundler must be configured for production mode
Code must be free of side effects (or marked via sideEffects in package.json)

package.json sideEffects configuration:

{
  "name": "my-library",
  "sideEffects": false
}

{
  "name": "my-library",
  "sideEffects": [
    "**/*.css",
    "./src/polyfills.js"
  ]
}

Dynamic imports for code splitting:

// Static import – always included in bundle
import { heavyFunction } from './heavy-module.js';

// Dynamic import – loaded only when needed (separate chunk)
async function handleUserAction() {
  const { heavyFunction } = await import('./heavy-module.js');
  heavyFunction();
}

// React lazy loading
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));

⬆ Back to Top

Configurable UI (Conditional Rendering)

Concept:
Render only the components and features that are actually needed for the current user, device, or context. Avoid rendering invisible or unnecessary UI elements that consume memory, CPU, and bandwidth.

Core principles:

Render only what is visible
Load components on demand
Adapt UI based on device, network, and user context

Example 1 – Conditional component rendering:

function SearchPage({ config }) {
  return (
    <div>
      {/* Render search bar only if enabled in config */}
      {config.showSearchBar && <SearchBar />}

      {/* Render filters only on desktop */}
      {!isMobile && <FilterSidebar />}

      {/* Render recommendations only for logged-in users */}
      {user.isLoggedIn && <Recommendations userId={user.id} />}

      <SearchResults />
    </div>
  );
}

Example 2 – Feature flags for conditional loading:

// Feature flag configuration (from API or config file)
const featureFlags = {
  enableChat: true,
  enableVideoPlayer: false,
  enableAdvancedSearch: true,
};

function App() {
  return (
    <div>
      <Header />
      <MainContent />

      {/* Components only load if feature is enabled */}
      {featureFlags.enableChat && <ChatWidget />}
      {featureFlags.enableVideoPlayer && <VideoPlayer />}
      {featureFlags.enableAdvancedSearch && <AdvancedSearch />}
    </div>
  );
}

Example 3 – Network-aware rendering:

function MediaSection() {
  const connection = navigator.connection;
  const isSlowNetwork = connection?.effectiveType === '2g' || connection?.effectiveType === '3g';

  if (isSlowNetwork) {
    // Show lightweight version on slow networks
    return <ImageThumbnails />;
  }

  // Show rich media on fast networks
  return <VideoCarousel />;
}

Benefits:

Smaller initial DOM size → Faster rendering
Less JavaScript parsed and executed
Reduced memory usage
Better experience on low-end devices

⬆ Back to Top

Streaming UI Rendering

Concept:
Instead of waiting for all data and components to be ready before showing anything, stream the UI in chunks. Show important sections first, then progressively fill in secondary content.

Traditional rendering vs Streaming:

Traditional SSR:
  Server fetches ALL data → Server renders ALL HTML → Sends complete HTML → Browser shows page
  User sees blank page for entire duration ████████████████████████░░

Streaming SSR:
  Server sends shell immediately → Streams components as data arrives → Browser shows incrementally
  User sees header/shell instantly ██░░ → content fills in ████ → complete ████████████████████

React 18 Streaming SSR with Suspense:

import { Suspense } from 'react';

function ProductPage() {
  return (
    <div>
      {/* Streamed immediately – no data dependency */}
      <Header />
      <ProductTitle />

      {/* Streamed when product details data is ready */}
      <Suspense fallback={<ProductDetailsSkeleton />}>
        <ProductDetails />
      </Suspense>

      {/* Streamed when reviews data is ready */}
      <Suspense fallback={<ReviewsSkeleton />}>
        <ProductReviews />
      </Suspense>

      {/* Streamed when recommendations data is ready */}
      <Suspense fallback={<RecommendationsSkeleton />}>
        <Recommendations />
      </Suspense>

      {/* Streamed immediately – no data dependency */}
      <Footer />
    </div>
  );
}

How React Streaming works:

Server sends HTML shell with Header, ProductTitle, Footer immediately
ProductDetailsSkeleton placeholder is sent while data fetches
When product details data is ready, server streams the real HTML to replace skeleton
Same for reviews and recommendations – each streams independently
Browser progressively replaces skeletons with real content using inline scripts

Next.js App Router streaming example:

// app/product/[id]/page.js
import { Suspense } from 'react';
import { ProductDetails, Reviews, Recommendations } from './components';
import { Skeleton } from './skeletons';

export default function ProductPage({ params }) {
  return (
    <main>
      <h1>Product Page</h1>

      <Suspense fallback={<Skeleton type="details" />}>
        <ProductDetails id={params.id} />
      </Suspense>

      <Suspense fallback={<Skeleton type="reviews" />}>
        <Reviews productId={params.id} />
      </Suspense>

      <Suspense fallback={<Skeleton type="recommendations" />}>
        <Recommendations productId={params.id} />
      </Suspense>
    </main>
  );
}

Benefits of streaming UI:

TTFB (Time to First Byte) drops dramatically – shell arrives in milliseconds
Users see meaningful content while data-heavy sections load
Slow API calls don't block the entire page
Each section is independent – one slow section doesn't delay others
Skeleton screens provide visual structure immediately

⬆ Back to Top

Avoiding import and Eliminating Dead CSS

The `@import` Penalty

Concept:
CSS @import rules create sequential (waterfall) downloads — each imported file must finish downloading before the next one begins. This is in contrast to multiple <link> tags which browsers download in parallel.

The problem:

Using @import (sequential — slow):
  main.css downloads (200ms)
    → Parser finds @import 'typography.css'
    → typography.css downloads (150ms)
      → Parser finds @import 'colors.css'
      → colors.css downloads (100ms)
  Total: 200 + 150 + 100 = 450ms (waterfall!) ❌

Using <link> tags (parallel — fast):
  main.css    ─────  (200ms)
  typography  ────   (150ms)   All downloaded simultaneously
  colors      ───    (100ms)
  Total: max(200, 150, 100) = 200ms ✅

Example — what to avoid:

/* ❌ main.css — creates waterfall */
@import url('reset.css');
@import url('typography.css');
@import url('components.css');

<!-- ✅ Use separate <link> tags instead — parallel downloads -->
<link rel="stylesheet" href="reset.css">
<link rel="stylesheet" href="typography.css">
<link rel="stylesheet" href="components.css">

When @import is acceptable:

Inside a build-time preprocessor (Sass/Less @import compiles to a single file)
Inside PostCSS pipelines (resolved at build time, not runtime)
Never in production CSS that the browser parses directly

Dead CSS Elimination (PurgeCSS)

Concept:
Most production websites ship 30-90% unused CSS. A typical project that imports a full CSS framework (Bootstrap, Tailwind base) may only use a fraction of its classes. Unused CSS:

Increases download size
Slows CSSOM construction (browser parses ALL rules, even unused ones)
Increases style recalculation cost

PurgeCSS and similar tools analyze your HTML/JSX/template files and remove any CSS selectors that are never referenced.

Build-time integration (PostCSS):

// postcss.config.js
const purgecss = require('@fullhuman/postcss-purgecss');

module.exports = {
  plugins: [
    purgecss({
      content: [
        './src/**/*.html',
        './src/**/*.jsx',
        './src/**/*.tsx',
        './src/**/*.vue',
      ],
      // Safelist classes that are dynamically generated
      safelist: ['active', 'is-open', /^modal-/],
    }),
  ],
};

Webpack plugin:

const { PurgeCSSPlugin } = require('purgecss-webpack-plugin');
const glob = require('glob-all');
const path = require('path');

module.exports = {
  plugins: [
    new PurgeCSSPlugin({
      paths: glob.sync([
        path.join(__dirname, 'src/**/*.{js,jsx,tsx,html}'),
      ]),
    }),
  ],
};

Tailwind CSS has PurgeCSS built-in — it scans your source files and only includes the utility classes you actually use:

// tailwind.config.js
module.exports = {
  content: ['./src/**/*.{js,jsx,tsx,html}'],  // PurgeCSS scans these files
  // ...
};

Tools for dead CSS detection and removal:

Tool	Type	How It Works
PurgeCSS	Build-time	Scans HTML/JSX, removes unused selectors from CSS
Tailwind JIT	Build-time	Generates only used utility classes (never includes unused)
Chrome Coverage Tab	Dev tool	Shows % of each CSS file used on current page
UnCSS	Build-time	Loads pages in headless browser, detects used CSS
cssnano	Build-time	Minifies + optimizes CSS (removes whitespace, duplicate rules)

Typical savings:

Before	After PurgeCSS	Savings
Bootstrap 5 (190KB)	~10KB (only used classes)	95%
Tailwind (3.5MB raw)	~10-30KB (JIT mode)	99%
Custom CSS (100KB)	~40-60KB	40-60%

Best practice: Integrate PurgeCSS (or equivalent) into your CI/CD pipeline so dead CSS is automatically removed on every build. Never rely on manual cleanup.

⬆ Back to Top

Key Takeaways

CSS Optimization

Inline critical CSS for above-the-fold content, async-load the rest
Use the media attribute trick to make non-critical CSS non-blocking
Use media-based lazy loading for conditional CSS (print, dark mode, orientation)
Load CSS via JavaScript for interaction-dependent styles

JavaScript Optimization

Use defer for app scripts (preserves order, runs after DOM parsing)
Use async for independent third-party scripts (analytics, ads)
Enable tree shaking with ES Modules and sideEffects: false
Use dynamic import() for code splitting heavy features

UI Optimization

Conditionally render components based on device, network, and user context
Use feature flags to control which components load
Stream UI with React 18 Suspense for progressive rendering
Show skeletons while streaming data-heavy sections

Performance Metrics Impact

Optimization	FCP	CLS	TTI	TTFB
Critical CSS	+++	+
Async CSS loading	++		+
JS async/defer	+		+++
Tree shaking			++
Code splitting			+++
Conditional rendering	+		++
Streaming SSR	++		++	+++

+++ = Major impact, ++ = Moderate impact, + = Minor impact

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Frontend System Design: Font Optimization - Performance

ZeeshanAli-0704 — Thu, 12 Mar 2026 12:54:37 +0000

Font Optimization – Frontend Performance

Custom fonts enhance brand identity but can severely hurt performance. An unoptimized font setup can delay text rendering by 1-3 seconds, causing Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT).

Common Font Loading Issues (FOUT, FOIT)
Font Display Strategy
Font Format Optimization (WOFF2, WOFF)
Font Preloading
Font Face Observer
Key Takeaways ⬆ Back to Top

Common Font Loading Issues (FOUT, FOIT)

Concept:
When a browser encounters custom fonts, it must decide what to show while the font downloads. This creates two well-known problems:

FOUT (Flash of Unstyled Text):

Timeline:
[0ms]    HTML parsed, text visible in fallback font (e.g., Arial)
[800ms]  Custom font downloads
[800ms]  Text re-renders with custom font → visible style jump

Text is always visible (good for readability)
Causes a visible style change (bad for visual polish)
Layout may shift if fallback and custom font have different metrics

FOIT (Flash of Invisible Text):

Timeline:
[0ms]     HTML parsed, text is HIDDEN (invisible)
[800ms]   Custom font downloads
[800ms]   Text appears with custom font
[3000ms]  If font fails → fallback shows after timeout (browser-dependent)

Text is hidden until font loads (bad for readability)
No style flash (good for visual consistency)
Can block reading for seconds on slow networks

Which is worse?

FOIT is generally worse – users see blank space and may think content is missing
FOUT is acceptable – content is readable from the start
Best approach: Control the behavior explicitly with font-display

⬆ Back to Top

Font Display Strategy

Concept:
The font-display CSS property controls how a font face is displayed based on whether and when it is downloaded and ready to use.

font-display values:

Value	Block Period	Swap Period	Behavior
`auto`	Browser decides	Browser decides	Default, unpredictable
`block`	Short (3s)	Infinite	FOIT – hides text, then swaps
`swap`	None	Infinite	FOUT – shows fallback, then swaps
`fallback`	Very short (100ms)	Short (3s)	Brief FOIT, then fallback permanently
`optional`	Very short (100ms)	None	Uses cached font or fallback, no swap

Example:

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2'),
       url('/fonts/custom.woff') format('woff');
  font-display: swap;   /* Show fallback immediately, swap when ready */
  font-weight: 400;
  font-style: normal;
}

When to use each value:

swap → Body text, headings – content must be readable immediately
optional → Non-critical decorative fonts – use if cached, skip if not
fallback → Important text where brief invisible flash is acceptable
block → Icon fonts where fallback would show wrong characters

Recommended approach for most sites:

/* Body font → must be readable immediately */
@font-face {
  font-family: 'BodyFont';
  src: url('body.woff2') format('woff2');
  font-display: swap;
}

/* Decorative font → optional, use if cached */
@font-face {
  font-family: 'FancyHeading';
  src: url('fancy.woff2') format('woff2');
  font-display: optional;
}

⬆ Back to Top

Font Format Optimization (WOFF2, WOFF)

Concept:
Font file format directly impacts download size. WOFF2 uses Brotli compression and is 30% smaller than WOFF, which uses gzip compression.

Format comparison:

Format	Compression	Size (typical)	Browser Support
TTF/OTF	None	100% (baseline)	Universal
WOFF	gzip	~60% of TTF	98%+ browsers
WOFF2	Brotli	~40% of TTF	96%+ browsers
EOT	Proprietary	~70% of TTF	IE only (dead)

Example – Modern @font-face with format priority:

@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2') format('woff2'),   /* Best: try first */
       url('font.woff') format('woff');      /* Fallback */
  font-display: swap;
}

Additional font file optimizations:

Subsetting – Remove unused characters:

# Using pyftsubset (fonttools)
pyftsubset font.ttf \
  --output-file=font-subset.woff2 \
  --flavor=woff2 \
  --text="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"

# Result: 80-90% smaller for Latin-only sites

Variable fonts – One file for all weights:

/* Instead of loading 4 separate font files for 4 weights... */
@font-face {
  font-family: 'Inter';
  src: url('Inter-Variable.woff2') format('woff2-variations');
  font-weight: 100 900;  /* Supports entire weight range */
  font-display: swap;
}

/* Use any weight */
h1 { font-weight: 700; }
p  { font-weight: 400; }

One variable font file replaces 4-8 individual files
Total size is typically smaller than 2-3 static files combined

⬆ Back to Top

Font Preloading

Concept:
Fonts are discovered late in the rendering process (CSS must be parsed first). Preloading tells the browser to start downloading the font file early, before CSS parsing discovers it.

Normal font loading timeline:

HTML downloaded → CSS downloaded → CSS parsed → Font URL found → Font download starts
                                                                  ^^^^ Late discovery!

With preloading:

HTML downloaded → Font download starts immediately (parallel with CSS)

Example:

<head>
  <!-- Preload critical fonts -->
  <link rel="preload" href="/fonts/body-font.woff2" as="font" type="font/woff2" crossorigin>
  <link rel="preload" href="/fonts/heading-font.woff2" as="font" type="font/woff2" crossorigin>

  <!-- Regular CSS that uses these fonts -->
  <link rel="stylesheet" href="/styles/main.css">
</head>

Important rules:

crossorigin attribute is required even for same-origin fonts (font spec requirement)
as="font" tells the browser it is a font resource (correct priority)
type="font/woff2" lets the browser skip if it doesn't support WOFF2
Only preload fonts actually used on the current page
Preloading too many fonts wastes bandwidth and hurts other resources

What to preload (and what not to):

Preload	Don't Preload
Body text font (used on every page)	Fonts for rarely visited pages
Primary heading font	Icon fonts loaded later
Above-the-fold fonts	Secondary decorative fonts

⬆ Back to Top

Font Face Observer

Concept:
A JavaScript library that detects when a specific font has fully loaded and is ready to use. This gives you programmatic control over font-dependent styling and transitions.

Why use it:

CSS font-display gives basic control, but no JavaScript hooks
Font Face Observer lets you run code exactly when a font loads
Useful for adding/removing CSS classes, triggering animations, removing placeholders

Example:

import FontFaceObserver from 'fontfaceobserver';

// Create observers for each font
const bodyFont = new FontFaceObserver('CustomBody');
const headingFont = new FontFaceObserver('CustomHeading', { weight: 700 });

// Wait for fonts to load
Promise.all([
  bodyFont.load(null, 5000),     // 5s timeout
  headingFont.load(null, 5000)
]).then(() => {
  // Fonts loaded – apply custom font class
  document.documentElement.classList.add('fonts-loaded');
}).catch(() => {
  // Fonts failed – keep fallback, no flash
  document.documentElement.classList.add('fonts-failed');
});

/* Default: fallback font */
body {
  font-family: Arial, sans-serif;
}

/* Applied only after fonts load */
.fonts-loaded body {
  font-family: 'CustomBody', Arial, sans-serif;
}

.fonts-loaded h1, .fonts-loaded h2 {
  font-family: 'CustomHeading', Arial, sans-serif;
}

Benefits of this approach:

Zero FOIT (text is always visible)
Controlled font swap with smooth transition
Can add CSS transition for opacity/color during swap
Graceful degradation if font fails to load
Can combine with localStorage to remember if fonts are cached

Advanced – Cache-aware font loading:

// Check if fonts are already cached
if (sessionStorage.getItem('fonts-loaded')) {
  document.documentElement.classList.add('fonts-loaded');
} else {
  const font = new FontFaceObserver('CustomBody');
  font.load().then(() => {
    document.documentElement.classList.add('fonts-loaded');
    sessionStorage.setItem('fonts-loaded', 'true');
  });
}

⬆ Back to Top

Key Takeaways

Use font-display: swap for body text to avoid FOIT
Prefer WOFF2 format (30% smaller than WOFF, 60% smaller than TTF)
Preload critical fonts in <head> with crossorigin attribute
Subset fonts to remove unused characters (80-90% smaller)
Use variable fonts to replace multiple font weight files
Use Font Face Observer for precise JavaScript-based font loading control
Cache-aware loading prevents redundant font downloads on repeat visits

Performance Metrics Impact

Metric	Impact
FCP (First Contentful Paint)	++ Moderate – font-display and preloading speed up text rendering
CLS (Cumulative Layout Shift)	++ Moderate – font swapping causes layout shifts if metrics differ
LCP (Largest Contentful Paint)	+ Minor – text elements can be LCP if they are the largest visible element

⬆ Back to Top

More Details:

Get all articles related to system design
Hashtag: SystemDesignWithZeeshanAli

systemdesignwithzeeshanali

Git: https://github.com/ZeeshanAli-0704/front-end-system-design

⬆ Back to Top

Forem: ZeeshanAli-0704

Frontend System Design: Virtualization & Handling Large Data Sets

Virtualization & Handling Large Data Sets

Table of Contents

Why Virtualization

The Problem — DOM Is Expensive

Without vs With Virtualization

Performance Numbers

How Virtualization Works

Core Math (Fixed Height)

Fixed vs Variable Height

Architecture of a Virtualizer

Three Positioning Strategies

Core Principles Summary

Library Comparison and Decision Guide

Library Evolution

Comparison Table

Decision Flowchart

Usage Syntax At a Glance

Infinite Scrolling Patterns

Pattern Overview

Pattern 1: Intersection Observer

Pattern 2: Virtualized + Infinite Scroll (Gold Standard)

Pattern 3: Bidirectional Scroll (Chat UIs)

Cursor-Based vs Offset-Based Pagination

Large Table Rendering

The Challenge — 2D Virtualization

Row Virtualization

Column Virtualization

Approach: TanStack Table + TanStack Virtual

Sticky Headers & Columns

Canvas Based Rendering (Extreme Data)

When DOM vs Canvas

How Canvas Grids Work

Canvas Libraries

Canvas vs DOM Trade-offs

Performance Optimization

Overscan Tuning

Key Optimization Techniques

Scroll Performance Pattern

Accessibility (A11y)

Challenge

ARIA Attributes Approach

Keyboard Navigation

A11y Checklist

Architecture Decision Guide

Choosing the Right Pattern

Full Architecture for Data-Heavy App

Real World Case Studies

Twitter/X Feed

Google Sheets

Slack Messages

Bloomberg Terminal

Common Pitfalls

Memory Management for Infinite Scroll

Interview Questions

Q1: What is virtualization and why is it needed?

Q2: How does a virtualizer calculate which items to render?

Q3: How would you implement infinite scroll with virtualization?

Q4: How do you handle column virtualization?

Q5: What are the accessibility challenges?

Q6: When would you use canvas over DOM virtualization?

Q7: How do you prevent scroll position jumping?

Q8: Design a virtualized grid — 100K rows, 50 columns, sortable, filterable.

Q9: How does "scroll to item" work with variable heights?

Q10: Compare transform: translateY() vs position: absolute; top:

Quick Reference Card

Frontend System Design: Performance Monitoring & Observability

Performance Monitoring & Observability

A Complete Frontend System Design Guide — Theory, Patterns & Interview Focus

Table of Contents

Core Web Vitals What They Are and Why They Matter

The 75th Percentile Rule

LCP — Largest Contentful Paint

INP — Interaction to Next Paint

CLS — Cumulative Layout Shift

Supplementary Metrics Worth Knowing

Identifying Performance Bottlenecks

The Performance Investigation Funnel

The Six Categories of Frontend Bottlenecks

Q10: Compare `transform: translateY()` vs `position: absolute; top:`