Frontend system design cheatsheet

01Start with five answers

1. Who is the user, and what is the one action they must complete?
2. Which features are required now, and which are excluded?
3. Which devices, browsers, locales, and accessibility needs matter?
4. How much data and traffic do we expect, and how fresh must the UI be?
5. What would count as failure: slow interaction, lost work, stale information, or unauthorized access?

When a number is unavailable, state an assumption and explain what changes if it is wrong. “I will design for thousands of feed items, but only a small window rendered at once” is more useful than an unsupported claim of unlimited scale.

02Keep a RADIO checklist beside the diagram

For a 45-minute rehearsal, try 5 minutes on scope, 8 on architecture, 7 on data, 8 on interfaces, 12 on deep dives, and 5 on review. This is a practice aid; follow the interviewer when priorities change.

03Specify a contract, not just an endpoint

For a feed, model a post's stable ID, author reference, content, media, timestamps, and viewer permissions. Store list order separately from records if several views reuse them. Define the cursor's ordering guarantees with the server; a cursor alone does not guarantee stable pagination.

type FeedPage = {
  items: Array<{
    id: string;
    authorId: string;
    text: string;
    updatedAt: string;
    canEdit: boolean;
  }>;
  nextCursor: string | null;
};

// GET /api/feed?limit=20&cursor=opaque-token
// Authentication and visibility are checked on the server.
// A null nextCursor means there is no next page.

• Name validation, authentication, authorization, conflict, rate-limit, and temporary failure responses.
• For mutations, define the canonical server result, optimistic reconciliation, and duplicate-request policy.

04Give each kind of state a home

Define cache identity, freshness, invalidation after writes, and logout cleanup. private limits shared-cache storage; no-store disallows storage by HTTP caches. Application caches and local storage need their own policy. Cancel obsolete requests and guard against results from an older query replacing the current one.

05Choose rendering and transport for the journey

For any live transport, define reconnect backoff, event IDs, deduplication, and how to recover missed changes. Pause unnecessary work when appropriate and cap retained data. Explain a fallback if the live channel fails.

06Review the states the screenshot does not show

• Initial loading: reserve useful space and show progress without blocking unrelated controls.
• Empty results: distinguish no content from an invalid filter or failed request.
• Refreshing: retain useful data when safe, and make stale or pending status clear.
• Failure: preserve input, give an actionable message, and avoid blindly replaying a write.
• Offline: state what can be viewed or edited and when pending work becomes confirmed.
• Accessibility: native semantics, labels, keyboard operation, focus management, and understandable status announcements.
• Responsive and international use: zoom, narrow layouts, long labels, right-to-left text, localized dates and numbers.

For autocomplete, describe selection with arrow keys, Enter, and Escape as well as pointer interaction. Decide what happens to focus when results change. A live region should inform the user without announcing every keystroke unnecessarily.

07Set measurable performance goals

Current good Core Web Vitals thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds, and CLS at most 0.1, assessed at the 75th percentile of field visits and segmented by mobile and desktop. These measure loading, responsiveness, and visual stability; add a product-specific metric such as time until search results become usable.

• Inspect requests, JavaScript size, image dimensions, main-thread work, and retained memory before choosing an optimization.
• Use realistic lists, images, low-end devices, and slow connections when validating.
• Combine laboratory checks with real-user monitoring. Lighthouse cannot directly measure interaction-based INP during a page-load run.

08Draw the trust boundary

• Authenticate identity and authorize the specific resource on the server; never trust a client-supplied role or hidden button.
• Keep service secrets server-side and validate input at the API boundary.
• Render ordinary text through safe framework output; sanitize intentionally rendered HTML and validate user-supplied URLs.
• Define cookie/session and cross-site request protections for the chosen authentication model.
• Avoid shared caching of private responses, and decide how sensitive drafts and account caches are cleared.
• Collect the minimum diagnostic data; redact tokens, personal content, and unnecessary identifiers.

09Close with verification and unanswered risks

Test transformations and reducers, component keyboard behavior, API error and permission contracts, and the critical end-to-end journey. Add cases for racing requests, reconnection, duplicate writes, expired sessions, and back navigation. Use representative data sizes for performance checks.

Observe route errors, API latency and failures, Web Vitals, and completed user actions. Correlate failures with a release and request ID, while protecting private data. Name one alert that would reveal a broken journey and one fallback that keeps the application usable.