Systems Design for Frontend Engineers

When I first interviewed for Senior roles, I dreaded systems design rounds. As a frontend engineer, I'd been told systems design was 'backend stuff' — load balancers, message queues, sharding strategies. After two years of leading architecture at Evoke, I've learned that's nonsense. Frontend engineers do systems design every day. We just need a map.

The 4 layers every frontend should know

Almost every web product fits this mental model. Get comfortable here and 80% of systems design questions become approachable:

  CLIENT                  ← React, Next.js, mobile
     ↓
  EDGE / CDN              ← caching, image opt, redirects
     ↓
  API GATEWAY / BFF       ← auth, rate limit, request shaping
     ↓
  SERVICES                ← business logic
     ↓
  DATA                    ← Postgres, Redis, search, blob

When someone asks 'design Instagram's feed,' you walk down this list. What does the client need? What can be cached at the edge? What does the API expose? Where does data live? Each layer is a conversation.

Where frontend decisions become systems decisions

• Pagination strategy → offset vs cursor → infinite scroll UX vs DB performance.
• Search input → debounce on client vs throttle at API → user experience vs server load.
• Optimistic UI → roll back on error → consistency vs perceived speed.
• Caching layer → React Query staleTime → fresh data vs API hits.
• Image loading → responsive srcset + lazy load → LCP vs bandwidth cost.

Caching, the most underrated frontend skill

Caching is where junior frontends and senior frontends drift apart. The senior knows there are at least four caches between their useEffect and the database:

• React Query / SWR in memory (per tab)
• HTTP cache in the browser (per origin)
• CDN edge cache (per POP)
• Server-side cache (Redis, in-process)

Pick the wrong layer and you either hammer your origin or serve stale data. A real example from my recent work: we were retrying failed list endpoints on every component mount. Moving that to a 30-second React Query staleTime + cache-control: public, max-age=10 at the CDN dropped backend traffic by 70%.

Trade-offs are the entire game

Junior answer to a design question: 'Use a message queue!' Senior answer: 'A queue gives us decoupling and durability, but adds latency, infra cost, and a place where messages can pile up. For this volume (500 events/min, near-real-time), is a queue worth it over a direct call with retries?' Frame everything as a trade-off — interviewers love it because it's how real engineers think.

Every system design choice costs something. The question is never 'is X good?' — it's 'what does X buy us, and what does it cost?'

A worked example: 'Design Twitter's timeline'

Let me run a 5-minute version. Even if you only know frontend, you can carry your weight here.

• Client: React Native + web (Next.js). Infinite scroll, cursor pagination, optimistic likes.
• Edge: CDN caches public profile pages, NOT the timeline (per-user). Image CDN with srcset.
• API: GET /timeline?cursor= returns a paginated list. Likes via POST /tweet/:id/like — optimistic update on client, rollback on 4xx/5xx.
• Services: Timeline service reads from a precomputed per-user feed cache (Redis), falls back to fanout-on-read for cold users.
• Data: Postgres for tweets + users; Redis for feed cache; S3/blob for media; Elasticsearch for search.
• Trade-offs: Precomputed feeds are fast to read but expensive on celebrity writes. Fanout-on-read is the opposite. Twitter does both — hybrid strategy.

Books and resources that actually helped

• Designing Data-Intensive Applications — Martin Kleppmann. Heavy but worth it.
• System Design Interview, Vol 1 & 2 — Alex Xu. Visual, approachable.
• The High Scalability blog and ByteByteGo newsletter for case studies.
• Reading the architecture sections of GitHub Engineering, Cloudflare, and Shopify blogs.

Closing thought

You don't need to know how a Kafka consumer group rebalances. You need to know what a queue gives you, what it costs, and when to reach for one. Systems design for frontends is about being a credible voice in the architecture conversation — and being the engineer who thinks beyond the component tree.