Forward deployed round
API Client Pagination & Retry Coding Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
Integrating with someone else’s API is where forward deployed work lives, and two bugs show up again and again: a pagination loop that stops one page too early and silently loses records, and a retry path that hammers a rate-limited endpoint without backoff or idempotency. Both look fine in a quick test and fail against a real, uncooperative service.
Interviewers use this because it is the daily reality of connecting systems you do not control. A cursor loop with a wrong termination condition drops the final page. A retry with no backoff turns a 429 into a storm, and a non-idempotent retry double-applies effects. Getting both right is what makes an integration trustworthy.
The scenario
You are given a client for a paginated third-party API, wired to an injected fake HTTP transport so everything is deterministic and offline. The pagination loop misses the last page of results, and the retry logic reacts to rate-limit and transient errors without proper backoff or idempotency.
The tests drive the fake transport through multi-page responses and injected 429/5xx failures. Your job is to make the client fetch every page exactly once and retry safely, so no record is lost and no effect is duplicated.
What you’ll practice
- Cursor/offset pagination and getting the termination condition right
- Retry with backoff for rate-limit (429) and transient failures
- Idempotent retries that do not double-apply
- Testing against an injected fake HTTP transport, not a live API
- Reasoning about a dependency you do not control
How to approach it
Two independent failure modes are in play — losing data, and misbehaving under failure — so treat them separately. For pagination, ask what tells the loop there is another page and what tells it to stop; the boundary is where records go missing. For retries, ask what a rate-limited or transient failure should trigger, and what makes a retried request safe to repeat.
The fake transport is your controlled adversary — it returns multiple pages and injects failures, so treat its scripted behaviour as the specification for a correct client.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Does this hit a real API?
No. An injected fake HTTP transport returns scripted multi-page responses and failures, so the tests are fast, deterministic, and offline. The client logic you build is exactly what a real integration needs.
Why does retry need idempotency?
Because a retry means the same request may be applied more than once. Without idempotency, retrying a write double-applies it — a duplicated charge or record — which is often worse than the original failure.