Design the Frontend Data Flow and APIs for a Social Media News Feed

In a product-architecture design round, you are asked to design the frontend and the client-facing APIs for a social network's news feed. The interviewer shares a mock-up of the feed screen, and the discussion starts from it. Unlike a classic backend design interview, there is no architecture diagramming and very little backend discussion: the focus is the user experience, the data the client needs, and the contract between client and server. The mock-up itself is not reproduced here. For practice, assume a typical feed screen: a vertically scrolling list of posts, each showing the author's name and avatar, a timestamp, text, optional images or video, like and comment counts, and like, comment and share actions, with more posts loading as the user scrolls. The feed must work on several kinds of client, such as desktop web, mobile web and native mobile apps. ### Constraints and Clarifications - Ranking and feed generation on the backend are out of scope; assume a service that can return a user's feed in ranked order. - Pagination must be cursor-based. - The design must specify the API response object in detail, not just endpoint names. - UX edge cases across client types are in scope. ### Clarifying Questions - Is the feed ranked or chronological, and can the ranking change between two page requests? - Should new posts appear automatically while the user is reading, or behind a "new posts" prompt? - Which interactions must update the screen instantly, such as likes and comments, and how fresh must counts be? - Which clients and network conditions matter most: low-end phones, slow mobile networks, offline use? ### Part 1 — UX flow and client data needs Starting from the mock-up, walk through the user flows the feed screen supports: first load, scrolling for more, interacting with a post, refreshing, and coming back to the feed later. For each flow, identify what data the client needs and when it needs it. ```hint Work from the screen to the data For every element on the screen, ask what data it needs, when that data must arrive, and what the user sees while it is loading. ``` #### What This Part Should Cover - The main flows and every state the screen can be in, such as loading, empty, error and end of feed - The data each feed item needs to render, including media and viewer-specific state - Client-side state management and how interactions update the screen ### Part 2 — API design and response shape Design the APIs the client calls, including the exact shape of the feed response object. Pagination must use cursors; explain why. ```hint What does page two point to? Picture the feed changing between two page requests, and ask what a page number or offset would then refer to. ``` #### What This Part Should Cover - Endpoints for reading the feed and acting on posts, with their parameters - A concrete response object: items, author and media data, viewer state, and the paging cursor - Why cursors rather than offsets, what a cursor encodes, and what happens at the end of the feed - Versioning, and keeping the payload compact for mobile clients ### Part 3 — Edge cases across clients Discuss the UX edge cases the design must handle across web and native mobile clients. ```hint Different screens, networks and lifecycles Compare a desktop browser on fast Wi-Fi with a phone on a weak connection whose operating system may suspend the app at any moment. ``` #### What This Part Should Cover - Slow, unreliable or absent networks, and retries that do not duplicate actions - Deleted or edited posts, duplicates across pages, and stale counts - Differences in screen size, media handling and app lifecycle between clients - Accessibility and performance of very long lists ### What a Strong Answer Covers - Starts from the mock-up and the user's flows, and derives the API from what the client needs - A precise response schema with cursors, shared entities and viewer-specific fields - Optimistic updates with reconciliation, and idempotent actions - Client performance: list virtualization, image sizing, prefetching and caching - Consistent handling of edge cases across client types ### Follow-up Questions - How would you show that new posts are available without moving the user's position in the feed? - How would you support an offline mode in which users can read and like posts while disconnected? - Would you expose this feed as a REST endpoint or a GraphQL query, and why? - How would you measure whether the feed feels fast to users?