Design HTTP Resource Loader
Design a system library API that handles HTTP requests for client applications like web browsers and mobile apps. The library should support various request types including large file downloads and be optimized for edge and mobile devices.
Asked at:
Meta
An HTTP Resource Loader is a client-side networking library that applications use to send and receive HTTP(S) requests. Think of what powers Safari/Chrome page loads or the Facebook iOS app fetching feeds and downloading large videos—this library abstracts connections, retries, caching, prioritization, and secure transport while providing a clean API. Interviewers ask this because it tests practical systems thinking under real device constraints: variable networks, limited memory/CPU, background execution rules, and the need to move large blobs reliably. Strong answers balance API ergonomics with a robust internal scheduler, correct HTTP semantics, resiliency, and observability—optimized for edge and mobile devices.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to issue HTTP(S) requests (GET/POST/etc.) with headers, timeouts, streaming bodies, progress, and cancellation.
Users should be able to download large files reliably with stream-to-disk, pause/resume, background execution, and integrity verification.
Users should be able to prioritize and throttle multiple concurrent requests, set per-request deadlines, and observe retries/errors.
Users should be able to leverage built-in HTTP caching and offline support (e.g., ETag/If-None-Match) with configurable cache policies.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
Large blobs over flaky networks are the common failure path on phones. Interviewers want to see if you avoid buffering entire files in memory, respect HTTP semantics, and guarantee integrity across app restarts. - Use HTTP Range requests with a persisted manifest (offsets, ETag/Last-Modified, expected Content-Length). If ETag changes, restart to avoid corrupt mixes of versions. - Stream to disk with fixed-size buffers and a temp file; fsync checkpoints periodically. Validate integrity via per-chunk checksums or final hash/signature before atomic rename. - Support pause/resume by persisting state; integrate OS background transfer APIs (e.g., iOS background sessions) so downloads continue when the app is suspended.
Contention management is central on edge devices. A thoughtful scheduler prevents a single large download from ruining overall UX and respects server and radio constraints. - Implement a global request scheduler with per-host pools and overall caps; use priorities, deadlines, and cancellation tokens so you can preempt background work for user-visible requests. - Leverage HTTP/2 stream prioritization/weights, coalesce connections by origin, and limit the number of parallel large transfers. Provide pluggable QoS policies per surface (feed, media, prefetch). - Enforce rate limits using a token bucket and respect server 429/Retry-After. Add exponential backoff with jitter to avoid thundering herds and excessive radio wakeups.
Mobile reliability is less about perfect networks and more about safe degradation. Interviewers want to hear a coherent story for timeouts, retries, network changes, and power-aware behavior. - Use sensible timeouts and idempotency-aware retries with exponential backoff + jitter; avoid retrying non-idempotent requests unless you have a dedupe token or idempotency key. - Detect connectivity changes and resume where possible; prefer HTTP/3/QUIC for faster handshakes and better loss recovery. Reuse TLS sessions and keep-alives to reduce handshake costs. - Integrate with OS background execution (work manager/background sessions), respect metered networks, and schedule heavy transfers opportunistically (Wi‑Fi, charging) when policies allow.
Correct caching saves battery and money, but incorrect caching breaks correctness and security. Show you understand core HTTP cache semantics and practical eviction policies. - Honor Cache-Control (max-age, no-store, private), ETag/If-None-Match, and Last-Modified/If-Modified-Since. Implement Vary handling for headers that change representation. - Use a disk-backed cache with size limits and LRU/LFU eviction; store large objects in chunked files to avoid fragmentation and enable partial reuse. - Support stale-while-revalidate and stale-if-error when allowed; provide app-level overrides (e.g., bypass cache) and ensure authenticated/private responses are not cached improperly.
Relevant Patterns
Relevant patterns that you should know for this question
The core challenge is moving big media (videos, app updates) over unreliable networks. You need range requests, chunking, integrity checks, and stream-to-disk to avoid memory blowups and corruption.
Large transfers are multi-minute background operations on mobile. You must handle app suspensions, retries, checkpoints, and idempotent progress across process restarts.
Phones have limited radio/CPU, and HTTP/2 multiplexing can still suffer head-of-line issues. A scheduler must prioritize UI-critical requests, enforce per-host limits, and respect rate limits.
Relevant Technologies
Relevant technologies that could be used to solve this question
Designing the client to target a stable API Gateway domain enables consistent auth, rate limiting, and caching hints (CDN, stale-while-revalidate). It simplifies connection reuse (TLS, HTTP/2/3) and gives the library clearer retry/backoff signals (429, Retry-After) across microservices.
Similar Problems to Practice
Related problems to practice for this question
Both require reliable transfer of large files with resume support, integrity verification, and efficient disk IO on clients. The same chunking, manifests, and background task handling patterns apply.
A crawler schedules huge numbers of HTTP requests with per-host politeness, retries, and backoff. The resource loader faces similar scheduling, concurrency, and caching concerns across hosts.
Protecting services and devices requires rate limiting and backoff across many clients. The same token-bucket concepts and handling of 429/Retry-After guide client-side throttling and fairness.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Buffering large downloads entirely in memory
This fails on real devices due to OOM and kills battery and UX. You must stream to disk, checkpoint progress, and validate integrity to be production-safe.
Naive retry logic without idempotency, backoff, or jitter
Aggressive retries can duplicate writes, amplify outages, and DDoS your own backend. You need idempotency keys, exponential backoff with jitter, and respect for server Retry-After.
Ignoring mobile constraints (background execution, metered networks, connection pooling)
Designs that assume always-on foreground execution or infinite sockets won’t work on iOS/Android. You need a scheduler that cooperates with OS policies, conserves radio, and reuses secure connections.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late September, 2025
Meta
Senior
Mid June, 2025
Meta
Senior
Late May, 2025
Meta
Staff
Your account is free and you can post anonymously if you choose.