DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.
DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.DowngradedOur downstream service providers are currently experiencing outages, and our engineering team is actively working on a resolution. Some services—including the Solver, Partner, and Tools—are temporarily degraded with higher latency and lower bandwidth. Rest assured, Intervipedia, Solutions, and the Question Bank features are not impacted and remain fully operational.
The Question
FE Design

Real-time Infinite Timeline Design

Design the frontend architecture for a high-performance, real-time social media timeline similar to Twitter. Focus on how you would handle thousands of items in an infinite scroll without degrading browser performance, your strategy for integrating real-time updates without disrupting the user's reading flow, and how you would implement optimistic UI for high-frequency interactions like likes and retweets. Address data fetching, state management, and the rendering lifecycle in detail.
React
TanStack Query
SSE
IndexedDB
Tailwind CSS
Virtualization
Questions & Insights

Clarifying Questions

Q: What constitutes "real-time" in this context?
Assumption: We will use a "New Tweets" notification toast rather than auto-injecting into the feed to prevent content jumping (Layout Shift), which is the industry standard for UX.
Q: What is the scale of the timeline and media types supported?
Assumption: Support for infinite scrolling with thousands of items. MVP will focus on text and static images; video playback is secondary.
Q: How should the system handle intermittent connectivity?
Assumption: The system should allow viewing already-cached tweets offline, but posting requires a connection.
Q: What are the primary user interactions beyond viewing?
Assumption: MVP includes Posting a tweet, Liking (with optimistic updates), and Retweeting.

Crash Strategy

The Rendering Bottleneck: A timeline with thousands of DOM nodes will degrade performance. We must implement Windowing/Virtualization to keep the DOM constant regardless of list size.
The Real-time Strategy: To balance battery life and server load, we will use Server-Sent Events (SSE) or WebSockets for a "New Tweet Signal," which populates a "Pending Queue" rather than the active display list.
Data Consistency: Use a Normalized Store or a robust caching layer (like TanStack Query) to ensure that if a tweet is "Liked" in the main feed, it reflects that state in a detail view or profile view.

Elite Bonus Points

Optimistic UI Engine: Implementing a robust rollback mechanism for likes/retweets to make the app feel instantaneous.
Priority Loading: Using Priority Hints (fetchpriority) and Image Decoding (async) to ensure the most relevant content (above the fold) renders first.
Adaptive Bitrate Image Loading: Serving WebP/AVIF based on the user's connection speed (Network Information API).
Design Breakdown

Requirements

Functional Requirements:
Infinite scrolling timeline.
Real-time "New Tweets available" notification.
Ability to compose and post a tweet.
Interaction (Like/Retweet) with immediate feedback.
Non-Functional Requirements:
Performance: Initial load < 2s; Scroll performance at 60fps.
Scalability: Handle 10,000+ tweets in the local cache without memory leaks.
Accessibility: Full keyboard navigation and ARIA live regions for new tweet alerts.
Responsiveness: Seamless layout transition from Mobile to Desktop.

Design Summary

Concise Summary: A virtualized list-based SPA that utilizes a signal-based real-time update pattern and optimistic UI state management.
Major Components:
App Shell: The persistent navigation and layout container.
Feed Virtualizer: Manages the windowing logic to render only visible tweets.
Live Update Controller: Listens to SSE/WebSockets and manages the "New Tweets" toast state.
Optimistic State Manager: Handles immediate UI updates for interactions and syncs with the API.
CUJ Walkthrough:
Viewing Feed: App Shell loads -> Main Feed fetches data -> Virtualizer renders items in viewport -> User scrolls -> Virtualizer recycles nodes.
Real-time Update: SSE receives signal -> Live Update Controller increments "New Tweets" count -> User clicks "See New Tweets" -> Pending Queue prepends to Main Feed.
Simplicity Audit: We avoid complex WebWorkers or micro-frontends for the MVP. We use standard browser APIs and a single source of truth for state to minimize synchronization bugs.
Architecture Decision Rationale:
Virtualization is mandatory for any infinite scroll list to prevent "DOM Bloat."
SSE is chosen over WebSockets because the communication is primarily unidirectional (Server to Client) for updates, which is more resource-efficient.

System Diagram

Architecture Deep Dive

Presentation Layer

Component Hierarchy: The AppShell provides the global layout (Sidebar/Navigation). The FeedPage is the primary route, containing the Composer and the Virtualizer. TweetItem is a complex leaf component that utilizes memoization to prevent re-renders when the list shifts.
Interaction Layer: All interactions like "Like" trigger an immediate state change in the FeedStore. LiveToast uses ARIA-live to notify screen readers of new content.
Rendering Layer: We use Virtualization (e.g., react-window or virtuoso logic). Only ~10-15 tweet nodes exist in the DOM at any time. Images are lazy-loaded using loading="lazy".
UI Frameworks / Tools: React for UI, Tailwind CSS for styling (atomic CSS minimizes bundle size), and Headless UI for accessible components.

Application Layer

Data Fetching Layer: TanStack Query handles the server state. It provides built-in caching, deduplication of requests, and background refetching.
State Management Layer:
FeedStore: Contains the current list of tweets.
UpdateQueue: A separate array holding tweets received via SSE. When the user clicks "See New Tweets," these move to the FeedStore.
Routing & Navigation: Client-side routing with React Router. Protected routes ensure the feed is only accessible to authenticated users.

Domain Layer

Business Rules: Tweet character limits (280 chars), link parsing logic, and timestamp formatting (e.g., "2m ago") are encapsulated here.
Entities / Models: Tweet entity maps the raw API JSON to a structured object, ensuring the UI doesn't break if the backend changes key names (Data Transformation).

Infrastructure Layer

API / Network:
REST: For standard CRUD (Post Tweet, Get Timeline).
SSE (Server-Sent Events): Lightweight channel for "New Tweet" pings.
Storage: IndexedDB (via TanStack Query's persist plugin) stores the last 50 tweets for instant "Offline-First" viewing upon app restart.
Wrap Up

Wrap-up

This architecture prioritizes Perceived Performance and Memory Management. By separating the "Live Feed" from the "Visible Feed," we avoid the most common UX pitfall: content jumping while a user is reading. The use of Virtualization ensures the app remains snappy even after hours of scrolling. For a production-ready scale, we would look into Workerized Fetching to move data processing off the main thread.