DEV Community

Cover image for 30 System Design Questions for Frontend & Fullstack Interviews
Yan Levin
Yan Levin

Posted on Edited on

30 System Design Questions for Frontend & Fullstack Interviews

System design rounds used to be for senior backend engineers. Now frontend and fullstack candidates get them too, and often at middle level. I run mock interviews with engineers, and the same questions come back from company to company.

Below are 30 of them in three blocks. Under each one I wrote what the interviewer listens for.

How to practice: answer each question out loud before you read the notes. Give yourself 5 minutes. If you can't name a trade-off or a failure case, mark the question and come back to it.

Part 1. Frontend system design

1. Design an infinite feed like Instagram or X.
The interviewer checks your pagination choice (cursor or offset) and the reason for it. They will ask how you keep the DOM small (virtualization), what happens to scroll position when new posts arrive at the top, and how images load.

2. A like button turns red before the server answers. What happens if the request fails?
This is optimistic UI: show the result first, send the request in the background, roll back on error. The follow-up is five fast clicks in a row. You need an answer about request ordering and sending the final state instead of every click.
I showed the mechanics in a short reel (in Russian): https://www.instagram.com/reel/DfkFKLHtJtA/

Optimistic UI: the UI renders the like before the API answers and rolls back on error

3. Design search with autocomplete.
Debounce, cancelling stale requests with AbortController, and the race where an old response arrives after a new one. Bonus points for caching per query and keyboard navigation with proper ARIA roles.

4. Build a chat UI with a "typing..." indicator.
WebSocket, SSE or polling, and why. Reconnection with backoff. Message ordering and deduplication by a client-generated id. A queue for messages sent while offline. How often the client should send "typing" events.

5. Make an image-heavy page load fast on mobile.
Responsive images with srcset, lazy loading, placeholders (LQIP or blurhash), a CDN that resizes on the fly, and fixed aspect ratios so the layout doesn't jump (CLS).

6. Where does each piece of state live in a large app?
The interviewer wants you to separate server state (a cache like TanStack Query or RTK Query) from UI state. Filters and pagination belong in the URL. A global store for everything is a red flag.

7. Design a 40-field form split into a multi-step wizard.
Validation with one schema shared with the backend, draft saving, re-render performance, mapping server errors to fields, and what the user sees after a page refresh.

8. Five teams work in one frontend repo. How do you split it?
Module boundaries, a public API per module, and import rules a linter can enforce. Feature-Sliced Design is one way to get there. If you suggest microfrontends, expect questions about their cost.
I wrote about FSD here: https://dev.to/m_midas/feature-sliced-design-the-best-frontend-architecture-4noj

9. A dashboard updates every few seconds. Design it.
Polling or push, re-rendering only the widgets that changed, pausing updates when the tab is hidden (Page Visibility API), and showing the user when data is stale.

10. Add offline support to a notes app.
Service worker, IndexedDB, a sync queue, and conflict resolution. Last-write-wins is fine if you can explain when it loses data. Show how the user sees sync status.

Part 2. API and fullstack

11. A user taps "Pay" three times. How do you charge the card once?
Idempotency keys. The client generates a key per payment, the server stores the key with the response and returns the same response for repeats. Stripe's API works this way.
Reel on this one (in Russian): https://www.instagram.com/ianlevin.dev/

Idempotency: three requests with the same key, one charge

12. Implement "Sign in with Google".
OAuth 2.0 authorization code flow with PKCE, the state parameter against CSRF, the refresh flow, and where tokens live: httpOnly cookie, memory or localStorage. Be ready to defend your choice against XSS.
Reel (in Russian): https://www.instagram.com/ianlevin.dev/

OAuth 2.0 authorization code flow with PKCE

13. REST, GraphQL or tRPC for a new product?
Caching, overfetching, type safety, team setup, public or internal API. The interviewer wants you to pick one for the given case and defend it.

14. Paginate an API over a table with 10 million rows.
Why large offsets get slow, how cursor pagination works, why the sort key must be stable, and what happens when rows are inserted while the user scrolls.

15. Add rate limiting to a public API.
Token bucket or fixed window, counters in Redis, limits per user or per IP. Then the frontend side: a 429 with Retry-After, and what the UI does with it.

16. Upload files up to 5 GB.
Presigned URLs so files go straight to storage, multipart upload, resuming after the network drops, progress reporting, and async processing (virus scan, thumbnails) after upload.

17. Sessions or JWT?
Revocation, token size, storage, exposure to XSS and CSRF, refresh token rotation. A strong answer says when each one fits.

18. Send a welcome email after signup without slowing the request.
A queue, background workers, retries with backoff, a dead-letter queue, and consumers that can process the same message twice without sending two emails.

19. Design a URL shortener.
ID generation (hash, counter, base62) and collisions. The read path is hot, so caching matters. 301 or 302, and how that choice affects analytics.

20. SSR, static generation or client rendering for an online store?
SEO, time to first byte, CDN caching, personalized blocks, hydration cost, and incremental regeneration for product pages.

Part 3. Architecture and scale

21. Your app gets 10x traffic tomorrow. What breaks first?
DB connections, N+1 queries, missing indexes, no cache, slow external calls in the request path. The interviewer checks that you measure before you scale.

22. Where do you put a cache and how do you invalidate it?
Browser, CDN, application, database. TTL or explicit invalidation. What happens when a popular key expires and a thousand requests hit the database at once (cache stampede).

23. Design notifications: in-app, email and push.
Fan-out, user preferences, delivery guarantees, deduplication, read and unread state across devices.

24. Two users book the same seat in the same second.
Pessimistic or optimistic locking, a unique constraint in the database, holding the seat with a TTL while the user pays, and releasing it on timeout.

25. Design the backend for a news feed.
Fan-out on write or on read, the celebrity problem (one user with 50 million followers), ranking, and storage.

26. Build collaborative editing like Google Docs.
OT and CRDT at a high level, presence, conflicts, offline edits. Few interviewers expect algorithm details. They check that you can state the problem.

27. How do you learn the product is broken before users tell you?
Logs, metrics, traces, frontend error tracking, Web Vitals from real users, alerts on SLOs.

28. Deploy without downtime.
Blue-green or canary, feature flags, backward-compatible DB migrations (expand, then contract). For frontend: chunk load errors when a user has the old version open during a deploy.

29. A multi-tenant SaaS. How do you isolate customer data?
tenant_id in a shared database, a schema per tenant, or a database per tenant. Row-level security. Noisy neighbours.

30. Monolith or microservices for a team of six?
Most interviewers hope to hear "monolith" with a plan: clear module boundaries now, and the signals that would justify splitting later.

How to answer any of them

Five steps to answer a system design question

  1. Spend the first 2 to 3 minutes on questions: who the users are, how many, which platforms, what matters most.
  2. Repeat the requirements back in your own words.
  3. Draw the high-level flow.
  4. Go deep on one or two parts.
  5. Name the trade-offs and failure cases before the interviewer asks.

In mock interviews I see candidates skip step 1 and start drawing. The interviewer counts clarifying questions as a signal. A system design round is a conversation with the interviewer, and the questions you ask are part of your answer.

Which question would you add? Leave it in the comments.


Preparing for interviews? I mentor frontend, backend and full-stack engineers: mock interviews, CV review, job search strategy. Book a free 15-minute call: https://calendly.com/y4nlvn/15-min-career-mentoring-intro

Not sure what is holding your job search back? Take a free career checkup in my Telegram bot (in Russian): https://t.me/ianlevin_checkup_bot?start=devto

I post practical notes on interviews and careers in my Telegram channel (in Russian): https://t.me/yan0tsx

Top comments (0)