A feed only looks simple until you have to balance media loading, caching, ranking, infinite scroll, and the feeling of instant response at the same time. That makes it a strong case for showing how a familiar screen quickly turns into a frontend system with its own pipelines and constraints.
The practical value of the chapter is that it breaks the feed down into engineering choices: pagination, prefetching, caching, render budget, and mobile UX under unstable network conditions. It is useful whenever you need to understand where the interface actually pays for performance and convenience.
For case interviews and architecture reviews, the chapter works well because it shifts the discussion away from pretty UI and toward client-side data flow, backend contracts, refresh strategy, and the trade-offs between perceived performance and implementation complexity.
Practical value of this chapter
Design in practice
Turn guidance on client feed architecture and the UX/latency/cost balance into concrete decisions for composition, ownership, and client-runtime behavior.
Decision quality
Evaluate architecture through measurable outcomes: delivery speed, UI stability, observability, change cost, and operating risk.
Interview articulation
Structure answers as problem -> constraints -> architecture -> trade-offs -> migration path with explicit frontend reasoning.
Trade-off framing
Make trade-offs explicit around client feed architecture and the UX/latency/cost balance: team scale, technical debt, performance budget, and long-term maintainability.
Context
Frontend Architecture Overview
The case focuses on a product line with high UX pressure and strict performance requirements.
Design Instagram Feed in frontend-system design it is a balance between personalization, performance and cost-efficiency. The system must quickly serve relevant content while maintaining smooth scrolling on mobile devices.
Problem & Context
Functional requirements
- Endless feed with cursor-based pagination and fast loading of cards.
- Supports videos/images, likes, comments and saves without completely reloading the screen.
- Personalize the order of posts and combine new/relevant elements.
- Stable UX on a bad network: skeleton, retry and graceful degradation.
Non-functional requirements
- Time to first meaningful feed item < 2s on an average mobile device.
- Scroll should remain smooth (without noticeable jank/drop frames).
- Economical consumption of traffic and battery due to lazy loading and media optimization.
- Resistance to load surges during mass publications and peak hours.
Scale assumptions
DAU
50M+
A large share of traffic comes from mobile clients and short sessions.
Feed requests
200k-600k RPS
Peak load is 2-3 times higher than base load during regional prime-time.
Media payload
~200KB preview / 1-3MB full
Optimizing images and videos is critical to latency and CDN costs.
Client memory budget
< 120MB feed screen
List virtualization is a must for long scrolling sessions.
Related
Caching Strategies
Caching is a key tool for speeding up delivery and reducing the cost of feed infrastructure.
Architecture
Feed BFF
Aggregates ranking + content + social metadata, returns a compact DTO optimized for UI.
Ranking service
Forms a personalized order of posts, returns a candidate set with score and reason codes.
Media service + CDN
Generates multi-dimensional previews, manages cache-control, signed URLs and progressive delivery.
Interaction service
Likes/comments are processed asynchronously with the optimistic UI and reconciliation on the client.
Deep dives
Pagination and prefetch
Cursor-based pagination eliminates gaps/duplicates when changing the feed. The client prefetches the next batch in advance according to the scroll threshold.
Render performance
Virtualized list + memoized feed items + media placeholder strategy. Outside the viewport, cards do not hold heavy DOM/media resources.
Optimistic interactions
The like is updated instantly locally and then confirmed by the server. In case of conflict, a reconciliation policy with a clear UX is applied.
Cache hierarchy
In-memory screen cache + HTTP cache + CDN edge cache. The key goal is to minimize cold fetch when the user returns to the feed.
Trade-offs
Strong personalization improves retention, but complicates explainability and debugging of user complaints.
Aggressive prefetch improves smoothness, but can significantly increase traffic consumption on the mobile network.
Thin BFF reduces client complexity but adds a critical server layer with a high blast radius.
Optimistic updates speed up the UX, but require careful rollback handling for network errors.
References
Related chapters
- Why do we need frontend architecture? - General context of frontend architectural decisions and their impact on delivery speed.
- Caching Strategies - Approaches to multi-layer caching to speed up tape delivery and reduce load.
- Load Balancing Algorithms - How to scale the feed API with high peak RPS and uneven traffic.
- Observability & Monitoring Design - Metrics scroll latency, feed completeness and error budget for product UX.
- Event-Driven Architecture - Asynchronous processing of likes/comments and fan-out feed updates.