Designing a Frontend System from A to Z

In an interview, you typically have 45–60 minutes to design a client-side product (e.g., News Feed, Autocomplete, Chat, Photo Gallery). The interviewer evaluates how systematically you think, not how many APIs you remember.

The RADIO framework — the backbone of every answer.

RADIO is a popular mnemonic to help you not miss any steps. Proceed sequentially but be flexible to revisit steps when needed. The RADIO framework is referenced from greatfrontend.com.

Self-assessment quick check

Classification of requirements

Essential questions to ask.

• Users & Scale: Who uses it? How many concurrent users? Primary device types?
• Core features: Which features are mandatory for MVP? Which are "nice-to-have"?
• Data: Does the data change frequently? Is real-time required?
• Performance: Are there specific targets (e.g., LCP < 2.5s)?
• SEO: Does the page need to be indexed by Google? (Significantly impacts rendering pattern)
• Offline: Does it need to work when there is no network connection?
• Cross-platform: Web-only or need to share logic with mobile app?
• i18n / a11y: Do you need to support multiple languages, RTL, and screen readers?

Common client architecture (layered)

Idea: data flows from Server → Network → Store → View Model → View, while events flow in the opposite direction. Each layer can be tested and replaced independently.

Container / Presentational pattern

When to use Micro-frontends?

Micro-frontend splits a large application into multiple independent parts, each owned by a team (potentially using different frameworks). It is effective for **large organizations with many teams**, but increases complexity in build processes, duplicate bundles, and UX consistency.

Visually compare the timeline.

Hydration & modern variants

Hydration is the process of attaching JavaScript event handlers to server-generated HTML, turning a "static" page into an "interactive" one. The issue: it can be heavy and delay Time to Interactive (TTI). Techniques to reduce cost:

• Streaming SSR: the server sends HTML in chunks, and the browser renders progressively instead of waiting for the entire page.
• Progressive / Selective Hydration: hydrate critical parts first (e.g., the portion the user is currently viewing).
• Islands Architecture: most of the page is static HTML, only a few interactive "islands" require JavaScript (Astro, Qwik).
• RSC (React Server Components): components run on the server, no JavaScript is sent to the client for that part.

Flashcards: quick review of concepts

Core Web Vitals — 3 metrics to remember.

Optimal levers — categorized by type.

Code splitting and lazy loading are techniques used to optimize the loading performance of web applications. Code splitting allows you to break your application into smaller chunks, which can be loaded on demand rather than all at once. This reduces the initial load time and improves the user experience. Lazy loading is a strategy that delays the loading of non-essential resources until they are needed. This means that components or modules are only loaded when they are required, further enhancing performance and reducing the amount of data that needs to be transferred during the initial load. Together, these techniques help in creating more efficient and responsive applications.

Instead of sending all JavaScript at once, only load the necessary parts. This is one of the most effective optimizations for FCP/LCP.

// Split bundle by route — load only when needed
const Dashboard = React.lazy(() => import('./Dashboard'));

function App() {
  return (
    <Suspense fallback={<Skeleton />}>
      <Dashboard />
    </Suspense>
  );
}

List Virtualization — a key technique for handling long lists.

Rendering 10,000 rows at once will kill performance. Virtualization only renders items within the viewport (plus a small buffer), reusing DOM elements when scrolling.

Popular libraries: react-window, react-virtuoso, @tanstack/virtual.

Flashcards Performance

REST vs GraphQL REST (Representational State Transfer) and GraphQL are two different approaches to building APIs. REST is an architectural style that uses standard HTTP methods (GET, POST, PUT, DELETE) to interact with resources. Each resource is identified by a unique URL, and the server responds with the entire resource representation. This can lead to over-fetching or under-fetching of data, as clients may receive more or less information than needed. GraphQL, on the other hand, is a query language for APIs that allows clients to request exactly the data they need. It provides a single endpoint and enables clients to specify the structure of the response. This reduces over-fetching and under-fetching issues, as clients can tailor their requests to their specific requirements. In summary, REST is resource-oriented and can lead to inefficiencies in data retrieval, while GraphQL is query-oriented and offers more flexibility in data fetching.

Pagination: 3 strategies

Handling Race Condition in search/autocomplete.

When a user types "rea" quickly → "react", the request for "rea" may arrive AFTER "react" and overwrite the correct result. Solution:

let controller;
async function search(query) {
  controller?.abort();           // Cancel the old request.
  controller = new AbortController();
  const res = await fetch(`/api?q=${query}`, {
    signal: controller.signal
  });
  return res.json();
}

Combine with debounce (~300ms) to reduce the number of requests, and check "whether this request is still the latest" before calling setState.

Resilience: retry, timeout, backoff

• Timeout: do not leave requests hanging indefinitely — cancel after N seconds.
• Retry with exponential backoff: retry at 1s → 2s → 4s to avoid overwhelming the server.
• Idempotency: For POST requests that create data, use an idempotency key to retry without creating duplicates.
• Graceful degradation: serve stale cache / display user-friendly error messages instead of a white screen.

State classification — decision diagram

Four types of state to distinguish:

One-way Flux / Redux

One-way data flow makes debugging easier: every state change goes through action → reducer, so we always know "why the state changed."

Principles of Component API Design

• Single Responsibility: each component does one thing well.
• Composition over configuration: prioritize composing smaller components rather than a single massive component with 30 props.
• Controlled vs Uncontrolled: allow both when appropriate (value + onChange, or defaultValue).
• Sensible defaults: works immediately with minimal props.
• Default accessibility: ARIA roles and focus management are built-in.

Example: design an API for the Autocomplete component.

interface AutocompleteProps<T> {
  // Data & How to Retrieve It
  fetchOptions: (query: string) => Promise<T[]>;
  // Custom display
  renderOption?: (item: T) => ReactNode;
  getOptionLabel: (item: T) => string;
  // Behavior
  debounceMs?: number;        // default 300
  minChars?: number;          // default 1
  // Controlled
  value?: T | null;
  onChange?: (item: T | null) => void;
  // State
  loading?: boolean;
  emptyMessage?: string;
}

The Compound Components pattern is a design pattern in React that allows you to create components that work together as a single unit. This pattern enables better composition and flexibility by allowing child components to communicate with their parent component without needing to pass props explicitly. It promotes a more intuitive API and enhances the reusability of components.

Allows users to compose child components flexibly, sharing state implicitly via Context.

<Tabs defaultValue="profile">
  <Tabs.List>
    <Tabs.Trigger value="profile">Profile</Tabs.Trigger>
    <Tabs.Trigger value="settings">Settings</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Panel value="profile">...</Tabs.Panel>
  <Tabs.Panel value="settings">...</Tabs.Panel>
</Tabs>

Client-side cache layers

Choose client-side storage.

Cache invalidation strategy

Stale-while-revalidate (core of SWR/React Query): immediately returns stale data to the UI for smoothness, while fetching in the background to update → users see fast results and always have fresh data.

Optimistic UI for a real-time feel.

When liking a post, update the UI immediately before the server responds, then rollback if an error occurs. The user experiences instant feedback even with network latency.

Core Accessibility Checklist

Internationalization (i18n)

• String externalization: do not hardcode text; use translation keys.
• Plural & gender: "1 item" vs "2 items" — use ICU MessageFormat.
• Format according to locale: dates, numbers, and currency via the Intl API.
• RTL: right-to-left support (Arabic, Hebrew) — use logical CSS properties (margin-inline-start).
• Lazy-load language packs: only load the current locale to reduce bundle size.

new Intl.NumberFormat('vi-VN', {
  style: 'currency', currency: 'VND'
}).format(1500000); // "1.500.000 ₫"

Common threats

XSS — the number one enemy of Frontend.

Critical Rendering Path — 6 Steps

Reflow vs Repaint — why is it important?

Mechanism: Call Stack, Queue & Loop

Execution order — classic example

console.log('1');
setTimeout(() => console.log('2'), 0);
Promise.resolve().then(() => console.log('3'));
console.log('4');
// Output: 1, 4, 3, 2
// Synchronous (1,4) runs first → microtask (3) → macrotask (2)

Compare the versions.

TLS handshake and why HTTPS is "slow the first time."

V8's compilation pipeline

Hidden Classes & Inline Caching

V8 does not know your object's "shape" in advance. It creates a hidden class (shape) for each object structure. Objects with the same shape share a hidden class → property access is extremely fast. Changing the shape (adding/deleting properties, adding in a different order) breaks this optimization.

// GOOD: same shape, V8 can optimize
function Point(x, y) { this.x = x; this.y = y; }
const a = new Point(1, 2);
const b = new Point(3, 4); // The same hidden class as A.

// BAD: Adding a property later, different order → different shape
a.z = 5;            // Now you have a different shape.
delete a.x;         // Deleting properties breaks hidden classes → slow, avoid using it.

Garbage Collection — Generational

Important caching headers

CORS — why is the request blocked?

The layers of a Design System.

Design Tokens — the heart of theming.

/* Token semantic points to the original token → changing the theme is easy. */
:root {
  --blue-500: #3b82f6;        /* primitive */
  --color-primary: var(--blue-500); /* semantic */
}
[data-theme="dark"] {
  --color-primary: var(--blue-300);
}
/* The component only uses semantic tokens, no hardcoded colors. */
.btn { background: var(--color-primary); }

Testing Pyramid (and the variant "Trophy")

What type of tests catch which bugs?

Three pillars to monitor.

Performance Budget — set limits to avoid "drifting."

// Warn/block the build if it exceeds the threshold.
{
  "budgets": [
    { "resourceType": "script", "maximumError": "170kb" },
    { "metric": "LCP", "maximumWarning": "2500ms" }
  ]
}

What does a bundler do?

CI/CD Pipeline & Deployment Strategy

Overview comparison

Why is Vite fast during development?

Mock vs Stub vs Spy — don't get confused.

Testing asynchronous code & timers

// Use fake timers to test debounce WITHOUT waiting in real time.
vi.useFakeTimers();
const spy = vi.fn();
const debounced = debounce(spy, 300);
debounced(); debounced(); // Call 2 times consecutively.
vi.advanceTimersByTime(300); // "tua" 300ms
expect(spy).toHaveBeenCalledTimes(1); // runs only once

Contract Testing — preventing "API changes without anyone knowing"

When frontend and backend develop independently, contract tests ensure both sides still "understand each other": the frontend declares what response format it expects, and the backend confirms it provides that exact format. If the backend changes a field, the contract test fails immediately — catching the error before production.

Why develop isolated components?

Structure of a "story"

// Button.stories.tsx — each export is one state
export default { title: 'UI/Button', component: Button };

export const Primary = { args: { variant: 'primary', children: 'Save' } };
export const Loading = { args: { loading: true } };
export const Disabled = { args: { disabled: true } };

Host & Remote

Issues to address

Trace, Span & Context Propagation

Three Pillars of Observability

Properly using alerts — combating "alert fatigue"

Image formats — choose the right one.

Responsive images and lazy loading are techniques used to optimize web performance and improve user experience. Responsive images allow different image sizes to be served based on the user's device and screen resolution, ensuring that images are displayed at the appropriate size without unnecessary loading of large files on smaller screens. Lazy loading defers the loading of images until they are needed, typically when they come into the viewport. This reduces initial page load time and saves bandwidth, as images that are not immediately visible are not loaded until the user scrolls down to them. Implementing these techniques can significantly enhance the performance of a website, especially on mobile devices.

<!-- The browser automatically selects the best source + appropriate size. -->
<picture>
  <source type="image/avif" srcset="hero.avif">
  <source type="image/webp" srcset="hero.webp">
  <img src="hero.jpg" width="1200" height="630"
       loading="lazy" decoding="async" alt="...">
</picture>

Where does the Service Worker stand?

Cache strategy

Monorepo vs Polyrepo

Micro-frontends — when to use them.

R — Requirements

• Key clarification questions: One-to-one only or group chat? Max group size?
• File/image attachments or text only? File size limit?
• Push notifications when app is backgrounded?
• End-to-end encryption required?

A — Architecture

Key design decision: WebSocket (not SSE) because chat is bidirectional — the user both sends and receives over the same persistent connection. The Local Queue stores outgoing messages while offline, draining them in order when the WebSocket reconnects.

D — Data Model

interface Message {
  id: string;              // server ID (replaces tempId after ack)
  tempId?: string;         // client-generated, used for optimistic send
  conversationId: string;
  senderId: string;
  text: string;
  attachments: Attachment[];
  status: 'sending' | 'sent' | 'delivered' | 'read' | 'failed';
  sentAt: string;          // ISO 8601
}

// Normalized state: O(1) lookup, easy status updates
interface ChatState {
  messages: {
    byId: Record<string, Message>;
    byConversation: Record<string, string[]>;  // conversationId → messageIds
  };
  conversations: { byId: Record<string, Conversation> };
  ui: {
    typingUsers: Record<string, string[]>;     // conversationId → userIds
    localQueue: Message[];                     // pending offline messages
  };
}

I — Interface (API & WebSocket Events)

// REST: initial data load
GET  /conversations
  → [{ id, participants, lastMessage, unreadCount }]

GET  /conversations/:id/messages?before=<cursor>&limit=30
  → { messages: Message[], prevCursor: string | null }

POST /media/upload-url
  → { uploadUrl: string; attachmentId: string }

// WebSocket JSON frames
// Client → Server
{ type: 'message', conversationId, tempId, text, attachmentIds }
{ type: 'read',    conversationId, upToMessageId }
{ type: 'typing',  conversationId, isTyping: true }

// Server → Client
{ type: 'message',  message: Message }          // new incoming message
{ type: 'ack',      tempId, serverId, status }   // delivery confirmation
{ type: 'typing',   conversationId, userId, isTyping }
{ type: 'read',     conversationId, userId, upToMessageId }

O — Optimizations

• A11y: role="log" + aria-live="polite" on message list — screen readers announce new messages without interrupting the user.
• Security: sanitize message content before rendering (prevent XSS via DOMPurify), validate file types server-side, use Content-Security-Policy headers.
• Message ordering: always sort by server timestamp on display — client clocks drift, so client timestamps are only for optimistic ordering.

R — Requirements

• Key clarification questions: Local static list or remote API? (changes architecture significantly)
• Maximum number of suggestions shown at once? (affects virtualization need)
• Should partial matches highlight the matching substring?
• Multi-select or single-select?

A — Architecture & Data Flow

D — Data Model

interface AutocompleteState {
  query: string;
  results: Suggestion[];
  selectedIndex: number;          // -1 = none, 0..n = highlighted item
  isOpen: boolean;
  isLoading: boolean;
  error: string | null;
  cache: Map<string, Suggestion[]>; // query → results, cleared on unmount
}

interface Suggestion {
  id: string;
  label: string;                  // displayed text
  metadata?: Record<string, unknown>; // caller-defined extra data
}

I — Interface (Props API)

interface AutocompleteProps<T extends Suggestion> {
  // Data source — caller owns the fetching logic
  fetchSuggestions: (query: string) => Promise<T[]>;

  // Display customization
  renderOption?: (item: T, isHighlighted: boolean) => ReactNode;
  getOptionLabel: (item: T) => string;

  // Behavior tuning
  debounceMs?: number;    // default 300
  minChars?: number;      // default 1 — no fetch until N chars typed
  maxResults?: number;    // default 10

  // Controlled mode
  value?: T | null;
  onChange?: (item: T | null) => void;

  // Slots
  placeholder?: string;
  emptyMessage?: string;
  loadingMessage?: string;
}

// Server endpoint
GET /search?q={query}&limit=10
  → { suggestions: [{ id, label, ...metadata }] }

O — Key Optimizations

Handling Race Conditions

useEffect(() => {
  if (query.length < minChars) return;

  // Check cache first
  if (cache.has(query)) {
    setResults(cache.get(query)!);
    return;
  }

  const controller = new AbortController();
  setIsLoading(true);

  fetchSuggestions(query, { signal: controller.signal })
    .then(results => {
      cache.set(query, results);   // store in session cache
      setResults(results);
    })
    .catch(e => { if (e.name !== 'AbortError') setError(e.message); })
    .finally(() => setIsLoading(false));

  // Cancel the in-flight request when query changes or unmount
  return () => controller.abort();
}, [query]);

R — Requirements

• Key clarification questions: Fixed grid (equal tiles) or justified layout (variable width, consistent row height)?
• User's own photos only or shared albums?
• Upload feature required or read-only gallery?
• Max photos per gallery? (affects pagination strategy)

A — Architecture & Key Techniques

Key design decisions: Server must return width and height for each photo so the browser can reserve the correct space before the image loads — essential for a CLS-free justified layout. Virtual DOM recycling keeps memory flat regardless of gallery size.

D — Data Model

interface Photo {
  id: string;
  url: string;           // full-resolution URL (lazy-loaded in lightbox)
  thumbnailUrl: string;  // 400px thumbnail URL
  blurDataUrl: string;   // tiny base64 LQIP placeholder
  width: number;         // original pixel width — required for layout calc
  height: number;        // original pixel height
  takenAt: string;       // ISO 8601
  alt: string;
}

interface GalleryState {
  photos: {
    byId: Record<string, Photo>;
    displayOrder: string[];     // ordered photo IDs
    nextCursor: string | null;
  };
  layout: PhotoLayout[];       // pre-calculated positions (top, left, w, h)
  lightbox: {
    isOpen: boolean;
    currentId: string | null;
    isTransitioning: boolean;
  };
}

I — Interface (API)

// Paginated photo list
GET /photos?cursor=<c>&limit=30&albumId=<id>
  → {
      photos: [{ id, thumbnailUrl, blurDataUrl, width, height, takenAt, alt }],
      nextCursor: string | null
    }

// Full-res on demand (only fetched when lightbox opens)
GET /photos/:id
  → { ...Photo, url: string }   // includes full-resolution URL

// Upload (if required)
POST /photos/upload-url
  → { uploadUrl: string; photoId: string }
// Client PUTs binary directly to CDN via uploadUrl

O — Optimizations

• Justified layout math: server returns width/height per photo. Client runs a layout algorithm (e.g., Google's bin-packing) to compute row heights and positions. Cache layout to avoid recalculation on every scroll.
• Scroll anchor on load more: when fetching older photos above, record scrollTop before appending and restore it after to prevent the viewport jumping.
• IntersectionObserver on bottom sentinel → fetch next batch when within 300px of fold.
• Lightbox keyboard a11y: trap focus inside lightbox (Tab/Shift+Tab), ArrowLeft/ArrowRight navigate, Escape closes, role="dialog" + aria-label.
• Pinch-to-zoom: use native CSS touch-action: manipulation + a library like react-zoom-pan-pinch for mobile lightbox.

R — Requirements

• Key clarification questions: Fixed or variable row height? (variable height dramatically increases virtualization complexity)
• Real-time collaborative editing or single-user?
• How many columns max? Are columns user-configurable?
• Export format requirements? (CSV, Excel, PDF)

A — Architecture

Key design decision: virtualize both rows and columns — a table with 50 columns and 1M rows could generate 50M DOM nodes without virtualization. The render window is typically ~20 rows × visible columns, with a small buffer. Libraries like @tanstack/virtual or ag-grid handle this well.

D — Data Model

interface Column {
  id: string;
  label: string;
  type: 'text' | 'number' | 'date' | 'select';
  width: number;         // pixel width — resizable
  pinned?: 'left';       // sticky column
}

interface Row {
  id: string;
  cells: Record<string, CellValue>; // columnId → value
  _version: number;                 // optimistic concurrency
}

interface TableState {
  columns: Column[];
  rows: { byId: Record<string, Row>; order: string[] };
  sort: { columnId: string; direction: 'asc' | 'desc' } | null;
  filters: Record<string, FilterValue>;
  cursor: string | null;   // for server-side pagination
  editingCell: { rowId: string; columnId: string } | null;
}

I — Interface (API)

// Never load all rows — server handles sort/filter/paginate
GET /rows
  ?sort=price:desc
  &filter={"status":"active","price":{"gte":100}}
  &cursor=<c>
  &limit=100
  → { rows: Row[], totalCount: number, nextCursor: string | null }

// Inline cell edit — optimistic with version check
PATCH /rows/:id
  body: { cells: { [columnId]: newValue }, _version: number }
  → { row: Row }           // 409 Conflict if version mismatch

// Real-time updates (SSE or WebSocket)
GET /rows/changes  (EventSource)
  ← data: { type: 'update', rowId, cells, _version }

O — Optimizations

• Optimistic cell edit: update cell in local state immediately, send PATCH in background, rollback on 409 conflict (another user edited same row).
• Debounce column resize: update column width in local state on every mouse move, but only persist to server on mouseup.
• Web Worker for large exports: CSV generation for 100k rows blocks the main thread. Offload to a Web Worker or stream the download from the server.
• Row selection: track selected row IDs in a Set, not booleans on each row — avoids re-rendering unselected rows on selection change.
• A11y: use role="grid", role="row", role="gridcell", arrow key navigation between cells, announce sort direction changes with aria-sort.

R — Requirements

• Key clarification questions: Live stream or VOD (Video on Demand)?
• DRM (Digital Rights Management) required?
• Captions mandatory (legal requirement in some regions)?
• Picture-in-picture support required?

A — Architecture

Key design decision: use an established ABR library (hls.js for HLS, dash.js for DASH) rather than implementing ABR from scratch. The player UI is a custom React layer on top of a native <video> element — native controls are hidden, custom ones overlay it.

D — Data Model

interface PlayerState {
  // Playback
  isPlaying: boolean;
  currentTime: number;        // seconds
  duration: number;
  buffered: [number, number][]; // array of [start, end] buffered ranges

  // Quality
  quality: 'auto' | '1080p' | '720p' | '480p' | '360p';
  currentBandwidth: number;   // estimated kbps

  // Controls
  volume: number;             // 0..1
  isMuted: boolean;
  playbackRate: number;       // 0.5 | 1 | 1.25 | 1.5 | 2
  isFullscreen: boolean;

  // Captions
  captionsEnabled: boolean;
  activeCaptionTrack: string | null; // e.g. 'en', 'fr'

  // Persistence
  savedPosition: number;      // loaded from server on init
}

I — Interface (API)

// Video metadata + stream manifest
GET /videos/:id
  → { id, title, duration, thumbnailUrl,
      manifestUrl: string,   // .m3u8 (HLS) or .mpd (DASH)
      captions: [{ lang, label, url }],
      chapters: [{ startTime, title }] }

// Player saves progress every 15s (or on pause/unload)
POST /videos/:id/progress
  body: { position: number }  // seconds
  → 204 No Content

// Captions fetched on demand
GET <captionUrl>  → WebVTT file

// HLS manifest from CDN
GET <manifestUrl>  → m3u8 playlist
GET <chunkUrl>     → .ts segment (fetched by hls.js internally)

O — Optimizations

Buffer & States

• Preload next segment: buffer several chunks ahead of playhead to absorb bandwidth spikes. Tune buffer goal (e.g., 15s) for VOD; use smaller buffer for live streams to reduce latency.
• Thumbnail scrubbing: pre-generate a sprite sheet of thumbnails at 1-per-second intervals. When user hovers the scrubber, show the sprite at that timestamp without seeking.
• Save position on unload: use visibilitychange + pagehide events (not beforeunload — unreliable on mobile) to POST progress to server.
• Reduced motion: respect prefers-reduced-motion — disable animated transitions in controls.
• Performance: hide custom controls overlay during playback (opacity:0, pointer-events:none) — a transparent overlay intercepts events but adds no paint cost.

R — Requirements

• Key clarification questions: Rich text (Google Docs) or plain text/code (like Replit)?
• Max concurrent editors per document?
• Is offline editing required? (fundamentally changes the architecture)
• Comment threads and suggestions, or just live editing?

A — Architecture & Core Challenge

Core issue: concurrent editing

Key design decision: use an established CRDT library (Yjs with y-websocket provider) rather than implementing OT/CRDT from scratch. Yjs handles conflict resolution, offline sync, and presence out of the box. Custom OT implementations are notoriously difficult to get correct.

D — Data Model

// Using Yjs CRDT
import * as Y from 'yjs';

const ydoc = new Y.Doc();
const ytext = ydoc.getText('content');  // shared text with CRDT semantics

// Client state
interface CollabState {
  syncStatus: 'synced' | 'pending' | 'offline';
  localVersion: number;
  collaborators: {
    [userId: string]: {
      name: string;
      color: string;         // unique color per user
      cursor: number | null; // character offset in document
      selection: { from: number; to: number } | null;
    };
  };
  comments: Comment[];
  pendingOps: Y.UpdateType[]; // buffered while offline
}

// Version history snapshot
interface Snapshot {
  id: string;
  createdAt: string;
  createdBy: string;
  description: string;
  stateVector: Uint8Array;   // Yjs state vector for this point in time
}

I — Interface (WebSocket Protocol)

// WebSocket (y-websocket protocol)
// Initial sync
Client → Server: { type: 'sync-step-1', stateVector: Uint8Array }
Server → Client: { type: 'sync-step-2', update: Uint8Array }  // missing ops

// Incremental updates
Client → Server: { type: 'update', update: Uint8Array }        // local edit
Server → Client: { type: 'update', update: Uint8Array }        // remote edit

// Presence (cursor/selection — ephemeral, not persisted)
Client → Server: { type: 'awareness', state: { cursor, selection, user } }
Server → Client: { type: 'awareness', changes: { [clientId]: state } }

// REST: document management
GET  /docs/:id          → { id, title, createdAt, collaborators }
GET  /docs/:id/history  → { snapshots: Snapshot[] }
POST /docs/:id/snapshot → create a named checkpoint
GET  /docs/:id/snapshot/:snapshotId → { content: Uint8Array }

OT vs CRDT — two approaches.

O — Optimizations

• Local-first rendering: apply keystrokes to local Yjs document immediately (no round-trip) → zero typing lag. Sync to server in background.
• Presence throttling: send cursor position updates at most 50ms intervals (throttle) — presence is ephemeral and lossy delivery is acceptable.
• Offline buffer: store pending Yjs updates in IndexedDB. On reconnect, replay in order — Yjs merges them correctly with server state.
• Large document performance: use a ProseMirror or CodeMirror editor that supports incremental rendering — never re-render the entire document on each change.
• A11y: announce collaborator joins/leaves via aria-live="polite", expose cursor positions in a non-obtrusive way, ensure the editor remains keyboard-navigable.
• Security: validate all operations server-side (reject ops from users without write permission), use CRDT for conflict resolution but authorize each op independently.

R — Requirements

• Key clarification questions: Personalized algorithmic feed or strictly chronological?
• Who can post — all users or verified accounts only?
• Video support? (affects CDN strategy and player complexity)
• Real-time updates required, or eventual consistency (5s poll) acceptable?
• Offline read access required?

A — Architecture

Key design decisions: FeedContainer is ‘smart’ (owns all data fetching + pagination state); PostCard is ‘dumb’ (pure rendering from props) — trivially testable and reusable. VirtualizedList is critical: without it, 1,000+ posts render all DOM nodes at once and lag on mobile. Rendering pattern: CSR + React Query — feed is post-login and personalized, so SSR adds server cost with no SEO benefit.

D — Data Model

interface Post {
  id: string;
  authorId: string;
  text: string;
  mediaUrls: string[];       // CDN URLs for images/video thumbnails
  likeCount: number;
  commentCount: number;
  likedByMe: boolean;
  createdAt: string;         // ISO 8601
}

// Normalized client state — avoids duplication across feed + profile views
interface FeedState {
  posts: {
    byId: Record<string, Post>;
    feedOrder: string[];           // ordered post IDs
    nextCursor: string | null;
  };
  users: { byId: Record<string, User> };
  ui: {
    composerDraft: string;
    newPostCount: number;          // from SSE — drives the "N new posts" pill
  };
}

I — Interface (API)

// REST endpoints
GET  /feed?cursor=<c>&limit=10
  → { posts: Post[], users: User[], nextCursor: string | null }

POST /posts
  body: { text: string; mediaIds?: string[] }
  → { post: Post }

POST   /posts/:id/like    → { likeCount: number; likedByMe: true }
DELETE /posts/:id/like    → { likeCount: number; likedByMe: false }

// Two-step media upload — keeps API server lean
POST /media/upload-url
  → { uploadUrl: string; mediaId: string }  // pre-signed S3 URL
// Client PUTs binary directly to CDN via uploadUrl

// Server-Sent Events for real-time new post count
GET  /feed/updates  (EventSource)
  ← data: { type: ‘new_posts’, count: 3 }   // drives the "3 new posts" pill

// PostCard — dumb component, no internal async state
interface PostCardProps {
  post: Post;
  author: User;
  onLike: (postId: string) => void;
  onComment: (postId: string) => void;
  onShare: (postId: string) => void;
}

// FeedContainer — smart component, owns data fetching
const { data, fetchNextPage } = useInfiniteQuery({
  queryKey: [‘feed’],
  queryFn: ({ pageParam }) => fetchFeed({ cursor: pageParam }),
  staleTime: 30_000,   // 30s before background refetch
});

O — Optimizations

• Virtualization: windowing with react-virtuoso — DOM stays at ~10–15 nodes regardless of feed length.
• IntersectionObserver on sentinel element → auto-triggers next page fetch.
• Images: LQIP blur-up placeholder + srcset for responsive sizes + explicit width/height → zero CLS.
• Optimistic UI: like/comment update immediately, rollback on API error.
• New posts pill: SSE pushes count → show pill, never auto-insert (would shift user’s reading position).
• Resilience: stale cache shown offline, exponential backoff retry on reconnect.
• Code splitting: PostComposer and media viewer lazily loaded — excluded from critical path bundle.
• A11y: aria-live="polite" region for new-post count, role="article" on PostCard, keyboard-focusable like/comment buttons.

// Optimistic like — instant feedback, rollback on error
function handleLike(postId: string) {
  const prevData = queryClient.getQueryData([‘post’, postId]);

  queryClient.setQueryData([‘post’, postId], (old: Post) => ({
    ...old,
    likedByMe: !old.likedByMe,
    likeCount: old.likedByMe ? old.likeCount - 1 : old.likeCount + 1,
  }));

  likeMutation.mutate(postId, {
    onError: () => queryClient.setQueryData([‘post’, postId], prevData), // rollback
  });
}

// CLS-free image with LQIP blur-up placeholder
// Server returns blurDataUrl: a tiny ~20×20 base64-encoded image
<img
  src={post.blurDataUrl}      // renders immediately — reserves space
  data-src={post.imageUrl}    // swapped in by IntersectionObserver
  width={post.imageWidth}
  height={post.imageHeight}   // correct aspect ratio → zero CLS
  loading="lazy"
  style={{
    filter: isLoaded ? ‘none’ : ‘blur(px)’,
    transition: ‘filter 0.s ease’,
  }}
  alt={post.imageAlt}
/>

60-Minute Agenda

Always mention "trade-off" questions.

Comprehensive flashcard set