Designing a Mobile News Feed App

A news feed is a continuously updating list of content items — status updates, photos, videos, links. Facebook, Instagram, and X all brand it differently, but the mechanics are the same: a scrollable list, per-post detail views, endless scrolling, and social actions (like, comment, share).

Before designing anything, pin down scope. The interview conversation converges on a specific system, and the constraints below drive every later decision.

Functional requirements#

1. Browse a feed of posts from others, ordered as the server returns them.
2. Like and share posts directly inline.
3. Compose posts with rich text, images, and video.
4. Open a detail view by tapping a post.
5. Infinite scroll — fetch more posts as the user reaches the bottom.
6. Offline mode — previously loaded content is readable without a connection.

Non-functional requirements#

Three screens#

The whole app reduces to three surfaces, and every architecture component below exists to serve one of them.

List the interactions first: the client requests the feed on open, sends new posts, fetches post details on tap, and notifies the backend of likes and shares. In all four, the client starts the exchange and the server responds. Nothing needs the server to push unprompted — real-time was cut from scope.

That request/response shape, plus the global scale and multiple future client types, points to HTTP with REST. It is universally understood, stateless (each request self-contained, which makes horizontal scaling trivial), and can lean on HTTP caching.

GraphQL would solve over/under-fetching by letting the client name exactly the fields it wants in one request. It is a reasonable alternative, but REST is the industry default — Meta's Graph API, Reddit's API, and X's API all use it — so this design stays with REST.

For encoding, the choice is JSON. It is human-readable, smaller than XML, and natively supported everywhere. Protocol Buffers would be smaller and faster on the wire, but this app is not performance-critical enough to justify the setup cost and the extra knowledge every developer would need.

All endpoints are versioned (/v1/) so breaking changes can ship in a new version without disturbing old clients. All carry an Authorization: Bearer <token> header and assume Accept: application/json.

1 · Fetch the feed#

GET /v1/feed?after=<cursor>&limit=30
  // empty body → 200 OK, FeedApiResponse

The response is deliberately lightweight. Each item is a PostPreview — not the full post. Instead of shipping every attachment, it carries an attachmentCount and a single attachmentPreviewImageUrl, plus interaction state like liked and likeCount. Just enough for a rich list, nothing more.

2 · Create a post#

POST /v1/posts
  // body: NewPostRequest → 201 Created (no body)

The client sends a NewPostRequest with a client-generated requestId, the content string, and a list of attachments. Two subtleties:

1. requestId ≠ postId. The client's requestId just identifies this attempt; the server mints the real postId and createdAt. The backend stays the source of truth (see §04).
2. Attachments are uploaded first. Media is uploaded to the server in a separate step, and the post request only references the resulting contentUrl. Splitting upload from post creation handles large files far more gracefully than one giant multipart request. [+] This also lets the client show upload progress and retry a failed image without re-posting.

3 · Fetch post detail#

GET /v1/posts/{postId}
  // empty body → 200 OK, PostDetailApiResponse

The postId lives in the path, per REST convention. The returned PostDetail carries everything PostPreview omitted: full content, shareCount, and the complete attachments array with full-resolution URLs.

4 · Record an interaction#

POST /v1/posts/{postId}/interactions
  // body: PostInteractionRequest → 201 Created

Body carries a client requestId (a throwaway UUID for deduplication) and a type enum — LIKED, REMOVED_LIKE, SHARED.

Clients never generate postId or createdAt. Centralizing this on the backend buys four things at scale:

Distributed systems solve the unique-ID problem with schemes like X's Snowflake: a 64-bit ID packing a timestamp, a machine ID, and a per-millisecond sequence number. [+] Because the timestamp sits in the high bits, Snowflake IDs sort chronologically and stay collision-free across many servers — you get ordering for free without a central counter.

Two external pieces sit outside the app. The Backend is the RESTful service that serves data and permanently stores posts and interactions — it holds most business logic (feed generation, post creation, interaction processing). A CDN distributes static content (profile images, media) from servers physically near each user, which speeds first paint, absorbs traffic spikes, and offloads the backend. At 500M users, the CDN is not optional.

Inside, the client splits into two layers. The UI layer displays posts, handles taps, and shapes data for the screen. The data layer is the backbone — it owns client-side business logic for how posts are created, modified, retrieved, and cached.

The data layer follows a repeatable pattern: one Repository per data type (the app's interface to that data and its business logic), backed by zero or more Data Sources.

For posts specifically: a Posts Repository exposes the feed and individual posts; a Posts Remote Data Source talks to the backend; a Posts Local Data Source manages on-device storage for offline. A separate User Repository holds the logged-in user's details and token. Each screen gets a State Holder (think ViewModel) that owns UI state and screen logic, and a shared Navigator moves between screens, passing values like a postId.

Tracing a single scenario makes the architecture concrete. When a user logs in for the first time, the local cache is empty, so the app must round-trip to the backend and populate local storage before the screen can render.

1. Login completes and the Feed State Holder subscribes to the Posts Repository's stream.
2. The repository checks the local source — it's empty, so it reaches out to the network.
3. The Remote Data Source calls the backend and receives the feed.
4. The repository writes the response into the Posts DB through the local source.
5. Writing the DB emits the new state into the posts stream.
6. That emission propagates up to the UI, and the screen renders the feed.

The key move: the UI never subscribes to the network. It subscribes to the local stream, and the network's only job is to fill that local store. This is the single-source-of-truth idea that §07 makes explicit.

Offline support is a core requirement, and it reshapes storage. Local storage serves two purposes: browsing cached posts when the network is bad or absent, and instant loads of already-seen content (no round trip).

Pick a relational database#

A relational database wins. [+] On Android that's typically Room over SQLite; on iOS, Core Data or SQLite directly. For most mobile apps, relational is the safe default unless a specific requirement pushes elsewhere.

Keep the cache lean — a hybrid eviction policy#

Storing every post forever wastes device resources. Combine three policies so the cache stays fresh and useful:

Sensible starting defaults, all tunable from the backend via analytics: 100–200 MB max cache, 15-day TTL, and a floor of 50 posts (2–3 screens).

When someone pulls to refresh while offline: the repository tries the network, fails, and that failure propagates to the state holder, which shows a connectivity message — while previously cached content stays on screen. The app never goes blank.

Waiting for a server round trip before a like registers feels broken. Optimistic writes update the UI immediately, as if the backend already confirmed, and reconcile afterward. When you tap like, the state holder does two things in parallel:

1. Update UI state now — the heart fills instantly. This is the optimistic part.
2. Tell the repository, which persists the interaction locally and fires the network request.

When the backend later confirms, the UI doesn't change again — it was already updated in step 1.

Use the local DB as an outbox queue#

Optimistic UI alone isn't enough. Every interaction is stored locally until the backend confirms it, so nothing is lost during offline stretches. The local DB acts as an ordered queue; when connectivity returns, the repository drains it in the background.

A new UserInteraction row captures each action with an AUTO INCREMENT id (preserving order), the postId/userId, an action (LIKED, UNLIKED, SHARED, BOOKMARKED), a status (PENDING, FAILED, CANCELED), an updatedAt for the last sync attempt, and a failureCount. Once an interaction syncs, the repository deletes its row and updates the corresponding Posts row. Conflicts between multiple interactions on one post resolve by last-write-wins. In the design, tables surface as DAO components — a Posts DAO and a User Interactions DAO, both over the one Posts DB.

When syncs fail — retry, then decide#

1. A failed request marks the interaction FAILED.
2. The system retries with exponential backoff — progressively longer delays.
3. Retries continue until a max attempt count.

What happens at the cap depends on how much the action matters. Trivial actions get set to CANCELED and the UI rolls back. Important ones (a failed post submission) warrant notifying the user to retry manually. If the backend state changed since the optimistic write, that's a conflict — discard the local change, merge, or ask the user, depending on the data.

Posts support rich formatting — headers, bold, italics, links, mentions. Content is stored as a String, but rendering it as plain text would disappoint. Two questions follow: what markup, and how to render it.

Don't invent a markup language#

A custom markup language is expensive to build and maintain. Facebook's own attempt (FBML) was deprecated in favor of standard HTML and JavaScript. X keeps a custom text library; Reddit uses a flavor of Markdown. For this app, rolling your own isn't worth it — pick a standard.

HTML wins for a modern, richly formatted feed. Two guardrails tame it: define HTML best practices so one feature maps to one consistent markup pattern (no five ways to bold text), and validate and sanitize every HTML string to block XSS. [+] Tools: OWASP Java HTML Sanitizer or jsoup on Android; HTMLKit or a purifier library on iOS.

Render with native views, not a WebView#

Because content is limited to formatted text with links and images — and because HTML best practices constrain the input — parse the HTML into native components. The extra parser work pays off in scroll smoothness and a polished, native feel.

A classic interview curveball: "What causes janky feed scrolling, and how would you fix it?" The answer is a checklist of rendering discipline.

Recycle views, load work off-thread#

View recycling is the biggest lever. Instead of creating a fresh view for every item scrolling in, reuse ones that scrolled out: pull a matching view from a recycling pool and rebind it with new data. Fewer allocations and layout passes free the main thread for smooth animation. [+] Use RecyclerView / LazyColumn on Android and UITableView / UICollectionView / SwiftUI List on iOS.

Asynchronous loading is built into the data model: images and attachments arrive as URL strings, so they load in the background while the row renders — the main thread never blocks on a decode.

Adapt media quality to the device#

A high-end phone scrolls smoothly where a low-end one stutters — CPU, memory, GPU, network, and battery all matter. So adapt image and video quality dynamically to current conditions. Define quality tiers and let the client request the right one:

This requires the backend to serve multiple pre-processed variants of each asset, or generate the requested quality on demand.

Stretch extensions worth mentioning if time allows: comments, push/live updates, on-device Full-Text Search, post editing after sync, scheduled posts, intelligent pre-fetching, and multi-language support.

Every link below was fetched and confirmed live on August 13, 2026. Two source references could not be verified and are flagged at the end.