API Design Tradeoffs for a Frontend Client

The plain-language idea

This lesson assumes you already know what REST and GraphQL are mechanically — that's a separate lesson elsewhere in this platform. Here, the question is different: in a system design interview, you're rarely asked to pick a protocol from scratch. You're asked to reason about the shape of an API a frontend team has to live with, and three tradeoffs come up constantly:

• Overfetching vs. underfetching. A fixed-shape endpoint either returns more than a given screen needs (overfetching — wasted bytes, wasted parse time) or less (underfetching — a second request needed for related data). Every API design decision, whether it's a new REST endpoint or a GraphQL query, is implicitly a decision about where on this spectrum a given screen lands.
• Pagination shape as an API decision. How a list endpoint returns "the next page" (an offset, a cursor, a page token) isn't just a client-side detail — it's a contract the API commits to, and it constrains what the client can do later (jump-to-page-N is only possible if the API supports it). A later lesson in this track goes deep on offset-vs-cursor tradeoffs specifically; here, the point is simpler: pagination shape is something you design into the API, not something you retrofit after the fact.
• Versioning and backward compatibility. An API a frontend depends on will change over time — new fields, renamed fields, removed endpoints. A design that doesn't account for this forces every client update to ship in lockstep with every API change, which doesn't scale past a single team shipping a single app.

See it in a real thing: a mobile app and a web app sharing one API

Say a company's API serves both a data-heavy web dashboard and a bandwidth-constrained mobile app. A single fixed-shape REST endpoint returning every field a user object has satisfies the dashboard but overfetches badly on mobile, where every unused kilobyte costs real load time on a slow connection. Naming this out loud — "these two clients have genuinely different fetching needs, so the API design has to account for both, not just the one I'm picturing" — is a stronger interview answer than assuming one shape fits every consumer.

On versioning: if that same API adds a required field to an order object, every client parsing the old shape without it will either crash or silently misbehave, unless the API commits to backward compatibility (new fields are additive and optional, not breaking) or ships an explicit version bump (/v2/orders) that old clients can keep using until they migrate on their own schedule.

What people usually miss

Watch out

• Overfetching and underfetching aren't opposite mistakes to avoid — they're a spectrum every fixed-shape API design sits somewhere on. The interview-worthy move is naming where a specific design lands on that spectrum for a specific screen, not treating either extreme as simply "wrong."
• Pagination shape has real downstream consequences that are easy to miss upfront. Committing to offset-based pagination early forecloses jump-to-page-N being awkward or unstable later — this is a decision worth making deliberately, not by default.
• "We'll version it later" is a common but weak answer. Backward compatibility is far easier to design in from the start (additive, optional new fields) than to retrofit once multiple client versions are already depending on the old shape in production.
• Different clients of the same API can have genuinely different needs. A design that only considers the client currently being discussed, and ignores that the same API might serve other consumers, misses a real constraint interviewers sometimes deliberately plant in the prompt.

Why this matters in interviews

"How would you design the API for this feature, and what tradeoffs would you make?" tests whether a candidate can reason about overfetching, pagination shape, and versioning as deliberate design decisions with real downstream consequences, not just recite "REST vs. GraphQL" as if naming a protocol were the whole answer.