05 — Backend Performance: API Response (Bounded, Compressed, Paginated, Idle)

The response side of the wire is where four more items live [1]. The model that joins them: what leaves the server costs both sides — bytes on the network, memory and CPU on the client when it parses. Every item below is one move against a different way of sending more than the caller needs.

Two moves on the bytes themselves

• Enforce reasonable payload size limits — the first move, and it doesn't get enough love because it sounds obvious. Set an upper bound on response size at the API boundary — a max page size (50, 100, not unbounded), a max include depth (?include=author,comments not ?include=everything), a max expansion (fields=* denied). The failure mode is the unbounded endpoint: a GET /things with no limit that returns 47,000 rows because that's how many the caller is allowed to see. The backend pays for the serialization, the network pays for the bytes, the client pays for the parse. Bounded responses are an explicit API contract: <50ms for any response, or document why it can't be.
• Enable compression for responses — the architectural companion to the backend tier's GZIP/Brotli item on the frontend side. Most JSON and XML compress beautifully (ratios of 4–10× on typical API bodies), and the cost is one middleware. Brotli over gzip where the client supports it; gzip fallback otherwise. Two recurring failures: the server has it but the client isn't sending Accept-Encoding (negotiation fails silently), and compression is on for tiny responses where the overhead exceeds the gain (skip under ~1 KB). Verify with Content-Encoding: br in the response headers and the transfer-size-vs-decoded-size in the Network panel.

Two moves on the shape of work

• Implement efficient pagination for large datasets — directly mirrors the database section's pagination item, but at the API boundary. Cursor-based pagination (?cursor=…) is the right default for ordered collections — the same cost on page 2,000 as on page 2, no degradation as the user advances. Offset pagination (?page=N&size=M) is the wrong default for long collections because OFFSET 100000 still scans 100,000 rows in the database before returning the page; it survives only for shallow, addressable page sets (an admin UI with ?page=5). Most public APIs reach for offset because it's simpler; most public APIs also have a "this gets slow at the deep end" incident eventually.
• Minimise unnecessary processing or expensive computation on the server — the largest single lever in the section and the most domain-specific. Every computation you do on the request path runs once per request; ones you don't have to do are free. The recurring offenders: encrypting or signing a token on every request instead of validating it (validation can be stateless), computing an aggregate on read instead of storing it, fetching the user's profile from a service on every hit instead of caching it after auth. Audit move: walk the request handler and ask, for each step, "does this need to run on every request, or can it be precomputed, cached, or moved off the request path entirely?" The work that doesn't run is the fastest the server can do.

The one throughline

The four items together say: a response that's bounded × compressed × paginated × non-computing is small on the way out and light on arrival. Each is a default win — no architectural change, just a contract change (limit and cursor), a middleware (compression), and a discipline (don't compute on read). The four are independent; pulling any one of them improves the endpoint, and pulling all four is the difference between an API that scales and one that doesn't.

The audit rhythm, identical to the rest of the backend tier: pick the slow endpoint, take one item off the list at a time, and measure. The one that moves the metric is the one that was missing.

References

• [1] roadmap.sh, "Backend Performance Best Practices — Optimize API Response," roadmap.sh, 2024. [Online]. Available: https://roadmap.sh/backend-performance-best-practices
• [2] Stripe, "Pagination," Stripe API Docs, 2024. [Online]. Available: https://docs.stripe.com/api/pagination
• [3] MDN, "Accept-Encoding," Mozilla, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding