Overfetching and Underfetching

Overfetching and underfetching describe two sides of a mismatch between what an endpoint returns and what a client needs. Overfetching returns more data than required; underfetching returns too little, forcing additional calls. Both waste resources.

Why It Happens

Fixed, one-size-fits-all responses cannot match the varied needs of different clients. A mobile list view needs three fields; a desktop detail view needs thirty; the same endpoint serves both. Designers default to returning the whole resource (overfetching) or a minimal stub that omits commonly needed relations (underfetching). Without a way for clients to specify their needs, every consumer gets the same payload.

Why It Hurts

Overfetching wastes bandwidth and processing, slows responses, and is costly on metered mobile connections; it also leaks fields clients shouldn't depend on, increasing coupling. Underfetching forces clients into extra round trips to gather related data, recreating the chatty-API latency problem. Both push complexity onto clients and make the API harder to evolve, because changing the fixed payload affects everyone at once. The net effect is slower apps and frustrated integrators.

Warning Signs

• Responses contain large objects where clients use a few fields.
• Clients routinely make follow-up calls to fetch related data.
• Mobile and web clients are forced to share an ill-fitting payload.
• Bandwidth usage is high relative to data actually rendered.

Better Alternatives

Let clients shape responses. Sparse fieldsets (a fields parameter) let callers select which attributes to return, curing overfetching. Expansion or include parameters let callers pull related resources in one call, curing underfetching. GraphQL solves both by letting clients request exactly the graph they need. A backend-for-frontend can tailor responses per client type. Pagination and projections keep payloads lean.

How to Refactor Out of It

Measure payload size against fields actually used, and count follow-up calls per task. Add field-selection and resource-expansion parameters to the heaviest endpoints first. For client-specific aggregation, introduce a BFF that returns precisely shaped responses. Where query flexibility is paramount and clients are diverse, consider a GraphQL layer over existing services. Keep defaults sensible so simple callers aren't forced to specify fields. The goal is responses that fit each use case — no wasted bytes, no extra trips.