Compare the same user journey
Fictional example using decimal kilobytes: the original journey makes 100 calls with 100 kB responses; a candidate makes 20 calls with 50 kB responses. Traffic falls from 10000 to 1000 kB, a 90% reduction. This does not establish the same reduction in latency. Only response bodies are counted, excluding requests and headers.
| Fictional measure | Original | Candidate |
|---|---|---|
| Calls | 100 | 20 |
| Bytes per response | 100 kB | 50 kB |
| Total traffic | 10000 kB | 1000 kB |
| Journey duration | Measure it | Measure it |
Reduce before adding concurrency
- Request only needed fields and follow the documented pagination contract. Batches need partial-result handling and limits; a larger page is not always faster.
- Reuse connections and responses when context and freshness permit. Bound concurrency and measure server work and queueing as well.
- Set an overall deadline and maximum attempts. Space transient-failure retries with a random component; check whether several layers already retry.
Avoid executing a completed action twice
A client timeout does not demonstrate server-side cancellation. Before repeating a creation or payment, inspect its state and the provider’s idempotency mechanism. Compare journey duration, errors and data correctness under representative load.
Primary references
- IETF RFC 9110 — HTTP Semantics [EN]
- AWS Builders’ Library — Timeouts, retries and backoff with jitter [EN]
Inspect work behind one API response
A single GraphQL query can trigger many downstream calls. Client-visible latency may hide the cost of resolvers, lists and traversed relationships.
- Trace an operation from client to downstream services.
- Compare field cost and actually useful volume.
- Bound lists and repeated queries before caching.
Primary reference: OWASP — GraphQL Cheat Sheet. Related method: read the practical guide.
Retry-After: waiting, budgets and retry decisions
Reducing API calls includes controlling repetition
An API optimisation should count attempts reaching the dependency rather than only requests initiated by the screen.
- Trace SDK and proxy retries under one logical identifier.
- Avoid shortening server instructions merely to fit a budget.
- Verify an uncertain write’s state before creating a new intention.
Explore Retry-After and the retry model →
References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS