Design a feed people can browse, react to, and publish into without losing their place. Follow a complete frontend design from requirements to failure recovery.
The key idea
Keep the feed's order separate from its records, make pending actions visible, and protect the reader's place whenever data changes.
Design a Facebook-style web feed for signed-in users. People should be able to read text and image posts, react to them, and publish a post. Explain the browser architecture and the contracts it needs from the server. This is a design exercise, not a request to build Facebook's backend.
| Clarify | Working assumption | Why it matters |
|---|
| Main journey | Browse posts, react, and compose a text or image post | Establishes the read and write paths to design first. |
| Feed order | Server-selected order that remains stable within a browsing session | The client renders the order; it does not invent ranking rules. |
| Devices | Responsive web, including small screens and slow connections | Media size and scrolling behavior must fit the device. |
| Freshness | New posts are offered through a user-controlled update notice | Updates should not move the post someone is reading. |
| Deferred scope | Comments, sharing, ads, video, and ranking implementation | Mention extension points without spending the interview on them. |
These are choices for this walkthrough, not universal product requirements. Ask whether the interviewer wants a ranked or chronological feed, public post pages, offline publishing, or a different primary interaction before committing to them. All API paths below are illustrative contracts, not live FineFrontend endpoints.
Use an interactive client-side feed with route transitions that preserve its session state. A client-rendered feed is a reasonable baseline for this exercise; server-rendering the first page can also reduce startup waiting when the platform supports it. Compare measured startup cost with hydration and cache complexity. Public post pages can use their own rendering strategy for discoverability.
Browser
Feed route ── Feed list ── Post card ── Reaction button
│ │
Composer Post detail route
│ │
└──── Actions + selectors ────┐
│
Entity cache + feed page state
│
Request / mutation adapters
│ HTTPS
Authenticated feed API
│ │
Feed / post data Upload service
│
Media storage / CDNFeedList, PostCard, AuthorSummary, Media, ReactionButton, and Composer render state and expose accessible controls. They should not each maintain a separate copy of a post.
Actions own pagination, pending reactions, publishing, and refresh decisions. Selectors combine confirmed records with the current local intent.
A shared adapter validates responses, scopes requests to the session, and handles cancellation, response ordering, and retry policy.
The server chooses feed order, checks permissions, persists writes, and returns authoritative records. Media processing and delivery have a separate lifecycle.
Load the first page's data alongside the code needed to display it, rather than waiting for a large component bundle to execute. Defer nonessential composer tools and optional media viewers. Meta's engineering write-up is a useful production example of controlling startup dependencies; it is not a requirement to adopt its internal stack.
Separate what exists from where it appears. A post can appear in the feed and on a detail route, while one author can appear in many posts. Store shared records by ID, and let each feed retain its ordered IDs and pagination state. Update one author record when their display name changes. Keep temporary interaction state alongside, rather than embedding it into every fetched record.
type User = {
id: string;
displayName: string;
avatarUrl: string | null;
};
type Media = {
id: string;
url: string;
alt: string;
width: number;
height: number;
};
type Post = {
id: string;
authorId: string;
text: string;
mediaIds: string[];
createdAt: string;
revision: number;
likeCount: number;
viewerHasLiked: boolean;
};
type FeedPage = {
orderedIds: string[];
nextCursor: string | null;
};
type FeedSession = {
snapshotId: string;
pages: FeedPage[];
pendingNewIds: string[];
lastCheckedAt: number | null;
anchor: { postId: string; offsetPx: number } | null;
};
type ClientState = {
users: Record<string, User>;
media: Record<string, Media>;
posts: Record<string, Post>;
feed: FeedSession;
desiredLikes: Record<string, boolean>;
draft: { text: string; attachmentIds: string[] };
};| State | Owner / lifetime | Example |
|---|---|---|
| Confirmed entities | Server owns truth; client caches by account | Post content, author name, confirmed reaction count. |
| Feed position | Browsing session and route history entry | Loaded pages, snapshot, visible post ID and pixel offset. |
| Local intent | Feature state until resolved or cancelled | Desired reaction, upload progress, composer text. |
| Shareable navigation | URL | Selected feed mode or a post permalink. |
A delayed page response can contain an older post than a recent reaction response. In this proposed contract, a server-issued revision increases whenever a post changes. Merge only newer confirmed revisions, then apply the pending local overlay. The version semantics must be agreed with the backend; a client timestamp cannot establish server ordering.
Choose REST for a small, concrete interview contract. GraphQL is also reasonable when several clients need different projections, but the transport choice does not remove pagination or consistency decisions. Identity comes from the authenticated session; a request body cannot select another user's identity. Bound page sizes and validate every returned entity before merging it.
| Interface | Request | Result / guarantee |
|---|---|---|
| Read the feed | GET /api/feed?limit=20&cursor=… | Ordered IDs, related entities, snapshotId, and nextCursor; null cursor means exhausted. |
| Read a post | GET /api/posts/{id} | Current post and related records, or a useful unavailable response. |
| Set a reaction | PUT /api/posts/{id}/like with { liked: true | false } | Confirmed liked state, count, and post revision. Repeating the same desired state does not toggle it. |
| Prepare an upload | POST /api/uploads with content type and byte size | A short-lived upload target and attachment ID; processing status is checked separately. |
| Publish | POST /api/posts with text, ready attachment IDs, and Idempotency-Key | Canonical post. Reusing the same key and payload returns the same operation result. |
{
"snapshotId": "s17",
"orderedIds": ["p81"],
"nextCursor": "opaque-next-page-token",
"posts": [
{
"id": "p81",
"authorId": "u4",
"text": "Our community garden is open this weekend.",
"mediaIds": [],
"createdAt": "2026-10-03T08:00:00Z",
"revision": 3,
"likeCount": 12,
"viewerHasLiked": false
}
],
"users": [
{ "id": "u4", "displayName": "Mira", "avatarUrl": null }
],
"media": []
}Define errors as part of the contract: expired authentication, validation failure, forbidden action, missing post, expired feed snapshot, and temporary service failure should produce different recovery options. For publishing, retain the same operation key after a lost response; generating a new key on Retry can create a second post. The server must scope keys to an account and operation, reject mismatched payload reuse, and document how long results are retained.
For a changing ordered list, prefer an opaque cursor over a numeric offset. If new items arrive before the next offset, the next slice can repeat or skip records. A cursor describes a boundary in a defined ordering. For this walkthrough's ranked feed, the server also fixes that ordering under a snapshot; a cursor alone cannot make arbitrary re-ranking stable.
Observe a sentinel near the list's end with IntersectionObserver. A positive root margin can start loading before the reader reaches it. Offer a Load more button using the same action.
Start only when another page exists and that cursor is not already loading. Capture the current account and feed generation, and cancel superseded reads when the feed changes.
Reject responses from an obsolete generation. Merge entities by revision, append previously unseen IDs in server order, and advance to the returned cursor.
Keep earlier content on a failed request and show Retry at the boundary. Stop automatic loading at a null cursor; do not infer completion only from a short page.
When the server can no longer serve a snapshot, keep the readable content and offer a restart from a fresh snapshot. Do not mix pages from different rankings. Deduplicating IDs prevents repeated cards, but cannot recover posts skipped by a broken ordering contract. Detect a repeated cursor to prevent an endless request loop.
A reaction should respond immediately, even on a slow connection. Keep the last confirmed record and a separate desired liked state. The displayed count is the confirmed count plus the change between those two states. Do not repeatedly increment a copied count on every click, or a double click can drift away from reality.
function visibleLike(post: Post, desired: boolean | undefined) {
const liked = desired ?? post.viewerHasLiked;
const delta = Number(liked) - Number(post.viewerHasLiked);
return {
liked,
count: Math.max(0, post.likeCount + delta),
};
}Update the desired state and render it immediately. Keep only one write in flight for a given post; later clicks update the intent instead of firing competing requests.
Merge the confirmed post by revision. If the user's latest intent still differs from the confirmation, send that latest desired state next.
For a definite rejection, remove the failed overlay and explain it. For an ambiguous timeout, refetch the post before deciding what is confirmed. Preserve a newer intent rather than applying an older rollback.
Setting a boolean state with PUT is idempotent when implemented as specified. That does not make contradictory writes order-independent: set true and set false still need sequencing. Aborting a fetch does not guarantee the server cancelled a write. Serialize per post and use the authoritative response to reconcile the result.
Keep controlled text and attachment selections local. Validate length and file limits for helpful feedback, and repeat those validations on the server. Keep the draft when submission fails.
Request an upload target, send the binary, then wait until the attachment is ready. Show progress, cancellation, and per-file retry. The server verifies ownership and content before allowing publication.
Generate an operation key when the user submits. Show a clearly marked pending card if desired, and disable duplicate submission while that operation is unresolved.
Replace its temporary ID with the canonical post ID rather than appending both. Clear only the submitted draft version; a new draft typed while publishing must survive.
Keep object URLs for local image previews only as long as needed, and revoke them after removal or teardown. Large binaries belong in media storage, while post creation stays a small JSON request. Failed or abandoned uploads need server-side cleanup. A first version can require connectivity to publish rather than quietly promising durable offline delivery.
Keep the initial feed projection compact, start its request early, and split optional editors and viewers. Avoid serial requests for each author when the page response can include them.
Include intrinsic dimensions so images do not move surrounding posts. Use responsive sources and appropriate formats; lazy-load offscreen images, but prioritize media likely to be the initial LCP element.
Subscribe a card to its own post and author records. A reaction to one post should not recreate every card or invalidate all loaded feed pages.
Measure the cost of a long mounted list before adding virtualization. Variable-height text and images require measurement, overscan, and scroll-anchor correction; focused articles must not disappear.
Virtualization mounts a window of nearby cards instead of all loaded cards. It trades DOM work for measurement and navigation complexity, and can affect find-in-page and assistive technology reading. Start with regular semantic articles for a modest feed; add windowing when realistic device testing shows it is needed. Retain enough neighboring content for stable scrolling and handle image or expanded-text height changes.
Infinite loading and windowing can remove content a screen reader is reading. Retain the focused article, provide predictable article navigation, and update busy and position metadata consistently if implementing the feed pattern. Use semantic articles and explicit loading when that is the more reliable accessible design.
| Boundary | Required protection |
|---|---|
| User-authored text | Render as text. Rich text needs a constrained representation and context-aware sanitization; never interpolate arbitrary HTML. |
| Links and media | Validate URL schemes and allowed media origins. Reject executable URLs and verify uploads independently of client checks. |
| Reads and writes | Derive identity from the session and authorize every resource. Cookie-authenticated mutations need a CSRF strategy; CORS alone is not authorization. |
| Abuse | Enforce server-side rate, content-length, and upload limits. A disabled publish button cannot prevent scripted requests. |
| Persistence and telemetry | Scope stored drafts and caches by account, set a retention policy, and avoid logging post bodies, credentials, or private media URLs. |
Content Security Policy is useful defense in depth, but cannot replace safe rendering or authorization. After logout, clear sensitive client state and cancel account-bound work. A restored browser snapshot or an old response must not silently reintroduce another session's content.
| Test scenario | Expected behavior |
|---|---|
| No posts / initial load fails | Distinguish a usable empty feed from a failed request; offer a clear next action or Retry. |
| Two boundary triggers / repeated cursor | Only one page request runs for the same boundary; a non-advancing cursor cannot create an endless loop. |
| Slow older-page response after refresh | Ignore the previous generation; new feed order and confirmed post revisions remain intact. |
| Rapid like / unlike with delayed replies | Latest intent wins, counts stay consistent, and an older failure cannot roll back a newer action. |
| Publish response is lost | Retry uses the original operation key and produces one canonical post, with the draft retained while uncertain. |
| New content while reading / images load late | The reader's anchor remains stable until they explicitly accept the update. |
| Offline, expired session, or deleted post | Retain readable content where permitted, show the correct recovery action, and avoid retrying a forbidden write forever. |
| Keyboard, screen reader, and long session | Focus remains reachable, status is understandable, and DOM plus cache memory stay within the agreed budget. |
Measure first useful post, page-load latency, duplicate-page incidents, mutation success and recovery, and scroll-restoration errors. Segment by device and connection. For user experience, collect field LCP, INP, and CLS; good Core Web Vitals targets are LCP at most 2.5 seconds, INP at most 200 milliseconds, and CLS at most 0.1 at the 75th percentile. Add operation IDs and error categories for debugging without capturing private content.
| Time | What to establish |
|---|---|
| 0–5 minutes | Requirements: user journey, content types, ordering, freshness, and explicit exclusions. |
| 5–10 minutes | Architecture: route behavior, rendering choice, component boundaries, and service ownership. |
| 10–15 minutes | Data: entity relationships, local intent, account scope, and scroll position. |
| 15–20 minutes | Interfaces: one page response, cursor semantics, reaction writes, and publish guarantees. |
| 20–27 minutes | Optimizations: trace a race or failure, then discuss media, long lists, accessibility, and privacy. |
| 27–30 minutes | Summarize trade-offs, validation, and the next feature that would change your design. |
For example: the reader likes a post, the UI projects that intent over confirmed data, a serialized request reaches an authorized endpoint, the reply updates the record, and a newer intent is reconciled next. Then explain what changes if the response is lost. A concrete sequence makes the design easier to evaluate than a list of libraries.
It moves the reading anchor. Stage updates behind a notice unless the product explicitly prioritizes a live timeline over stable reading.
Windowing can help large DOMs, but introduces variable-height, focus, and restoration work. Adopt it after measuring a representative workload.
Authentication and validation errors require a different action. Ambiguous writes need reconciliation or a stable operation key, not unbounded retries.
Original explanations and examples by FineFrontend, informed by the guide and primary references below.
Question reference and Medium / 30-minute interview metadata. This walkthrough uses an original worked design and examples.
Production context for startup dependencies, data loading, and route transitions.
Avoiding redundant and deeply nested state.
Offset and cursor trade-offs; ordering and cursor contracts.
Sentinels and loading boundaries.
Response checking and request cancellation.
Desired-state writes and idempotent semantics.
Private caches and no-store semantics.
Intrinsic dimensions, responsive sources, and image loading.
The mechanics and trade-offs of rendering a limited window.
Article focus, keyboard interaction, and feed semantics.
Safe text rendering, URL contexts, and sanitization.
Resource permissions and server-side enforcement.
Protecting cookie-authenticated mutations.
Field performance metrics and their good thresholds.
Consider server-rendered permalinks, sharing metadata, and indexing policy while keeping private feed caches isolated.