Design patterns and architecture · Fetch, cache, write

Data retrieval-style app

Illustrative system design for a fetch, cache, write app like Data retrieval: 4 topics to read, from requirements to deep dives.

Illustrative design, not Data retrieval’s actual implementation. Arrowbox is not affiliated with Data retrieval’s owner. Disclaimer

Start with When to fetch Sign in to start readingUpdated 2 Oct 2026

Core

  • When to fetch: waterfalls and how to flatten themBeginner · 31 min read · Sign in to read

    If every component fetches its own data after it renders, requests run one after another; starting them all at navigation, or even on hover, runs them in parallel.

  • A client cache: keys, freshness and stale-while-revalidateIntermediate · 31 min read · Sign in to read

    Keep server data in memory under a key, show what you have straight away, and refetch in the background when it goes stale. Normalise entities when the same record appears on many screens.

  • Racing requests: dedupe, cancellation and out-of-order repliesIntermediate · 38 min read · Sign in to read

    Responses come back in any order. Make the latest request win, share one in-flight request between everyone who asks for the same thing, cancel what nobody needs, and retry only what is safe to retry.

  • Writing data: mutations, optimistic updates and rollbackIntermediate · 36 min read · Sign in to read

    Show a change before the server confirms it only when it is likely to succeed and cheap to undo. Snapshot, apply, send, then reconcile or roll back, and send an idempotency key so retries can't apply twice.