Free lesson · Mobile System Design Interviews

Social Feed App - Summary & Variations

Medium9 min readmobilemobile-system-designinterview-prep

Step 5: Wrapping It All Up

You've completed your first case study! Let's take a step back and see everything you've designed.

What We Built: A Quick Recap

Over the past five sections, we designed a complete mobile social feed app. Here's the 30-second summary:

The Goal: A mobile app (iOS and Android) where users can scroll through an infinite feed of posts, like them, comment, create new posts, and use the app even when offline.

The Architecture: We used MVVM + Repository pattern. ViewModels handle UI logic. The Repository is the gatekeeper that decides whether to fetch from the local database (instant, cached) or the network (fresh, but slower). All data flows through the Repository, making the app testable and flexible.

The Feed Loading: We load posts in pages (20 at a time) using cursor-based pagination. We cache aggressively (memory → disk → network) and use "stale-while-revalidate" to show cached posts immediately while fetching fresh data in the background. The UI detects when the user scrolls near the bottom and prefetches the next page.

Offline & Interactions: When the user taps "like," the app updates the UI immediately (optimistically), then syncs to the server. If the network is down, pending actions are queued in a local database. When the network returns, the sync manager pushes all queued actions to the server. If the server rejects an action, the UI reverts.

Images: We cache images in memory (for current scroll) and on disk (survives app restart). We load thumbnails first, then full resolution.

Key Decisions & Trade-offs

Here are the major decisions we made and why:

What We'd Improve With More Time

In a real system, we'd add:

1. Push Notifications

Real social apps notify users when someone likes their post or comments. We'd add Firebase Cloud Messaging (FCM for Android) or APNS (Apple Push Notification service for iOS) to wake up the app with new posts when the user isn't looking.

2. Advanced Image Compression

Photos on phones are often 5-10 MB. We could compress images before upload (reduce to 1-2 MB) without losing visual quality, saving bandwidth and storage.

3. Video Support

Videos are different from images: larger files, need streaming instead of one-shot downloads, require different caching strategies. This adds significant complexity.

4. Analytics & Telemetry

Track what users do: How long do they spend in the app? Which posts get engagement? This data helps the backend optimize the feed algorithm. Privacy-sensitive but valuable.

5. Real-Time Updates

Using WebSockets, the app could update like counts in real-time as other users like a post. Currently, the user only sees updated counts on next refresh. Real-time would feel more alive but adds backend complexity.

6. Feed Algorithm / Ranking

We assumed chronological feed (newest first). Real apps rank posts algorithmically (show engaging posts higher). This requires ML models and different API design.

7. User Search & Discovery

Currently, the app only shows the feed. Full apps let users search for posts or people, discover new content. More API endpoints, more caching strategy decisions.

8. Comments Threading

Replies to comments (nested comments) require a different data structure. We simplified to flat comment lists.

Practice Variations: "What If?" Scenarios

System design is about trade-offs. Different requirements = different designs. Let's practice by changing the requirements:

Variation 1: "The interviewer asks: Support video posts in the feed."

What changes?

API Design:

• Post model now has videoUrl in addition to imageUrls
• Response includes videoDuration and videoThumbnailUrl

Caching:

• Videos are huge (50-500 MB). We can't cache full videos locally like images.
• Instead, cache only the first 5 seconds (or thumbnail).
• Stream the rest from CDN on-demand.
• Limit to one video in memory at a time (vs. many images).

Architecture:

• New VideoLoader component, similar to ImageLoader but with streaming logic
• Post rendering checks if content is video or image

UI:

• Show video player component instead of image
• Add play button overlay
• Handle video buffering and playback errors

Network:

• Detect available bandwidth. On 3G, stream lower resolution. On WiFi, stream HD.
• Use HTTP range requests to resume partially downloaded videos.

Variation 2: "The interviewer asks: Support algorithmic ranking instead of chronological."

What changes?

API Design:

• Endpoint signature stays the same: GET /feed?cursor=...
• But server now returns posts ranked by engagement/personalization, not by time
• Server might return different posts for different users

Caching:

• Can't cache aggressively (different users see different feeds)
• Shorter cache duration (5 min instead of 30 min)
• Clear cache more often when user takes actions (like, comment)

Architecture:

• Add RankingModel to understand what "good" ranking means locally
• User preferences: "Show more tech posts" → adjust caching/ranking locally
• More memory required (ranking requires scoring each post)

UI:

• Show "For You" instead of "Latest"
• Add "Sort" button to switch between algorithms

Offline:

• Offline mode shows chronological posts (all we have), not ranked
• When online, ranking takes over

Variation 3: "The interviewer asks: The app must work in very low-bandwidth countries (2G networks, high latency)."

What changes?

Image Handling:

• Compress images more aggressively (quality 40 instead of 80)
• Load only thumbnails by default; tap to load full resolution
• Disable auto-play of image galleries

Data Transfer:

• Reduce post metadata; send only essentials (text, image URL, author name)
• Don't send like count and comment count every time; update separately
• Use binary format (Protocol Buffers) instead of JSON (more compact)

Caching:

• Cache everything locally; assume user has limited data plan
• "Data saver" mode: only fetch when on WiFi
• Ask permission before downloading any image

Architecture:

• Add DataSaverMode setting
• Different API endpoints for low-bandwidth: GET /feed/lite returns minimal data
• Implement "media-on-demand" pattern: show text without images by default

UI:

• Add "Enable low-bandwidth mode" toggle in settings
• Show data usage estimate: "This post will use ~2 MB"
• Warn before auto-loading images

Variation 4: "The interviewer asks: How do you handle content moderation at the client level?"

What changes?

Client-Side Filtering:

• Detect potentially harmful content: nudity, violence, profanity
• Use local ML model (on-device) to flag inappropriate posts
• Don't send the image to server; process locally (privacy)

Data Model:

• Add ContentWarning field to Post: "This content may be inappropriate"
• Server flags problematic posts; client obeys the flag

UI:

• Show blurred image with warning: "This post contains graphic content"
• User must tap to confirm they want to see it
• Option to report to moderators

Caching:

• Cache the content warning with the post
• Don't cache flagged images in thumbnail size (privacy concern)

API:

• GET /feed includes contentWarning field
• User can set preference: "Show all", "Hide mature", "Hide violence"

Key Patterns You'll See Again

This case study taught you patterns that appear in almost every system design:

1. Pagination

Every API that returns lists of data uses pagination. Feeds, search results, comment threads—they all use some form of pagination (cursor-based or offset-based).

2. Caching Layers

Memory → Disk → Network is everywhere: social feeds, search results, maps, music streaming. The specifics change, but the pattern is universal.

3. Offline-First Design

Mobile apps must handle offline. Desktop apps connected to the internet still benefit from offline-first thinking (works even if network is slow).

4. Optimistic Updates

Users hate waiting. Anything interactive (like, heart, favorite) should update instantly. This pattern spreads beyond just likes to any user action.

5. Repository Pattern

Abstracting data sources (local vs. remote) is a fundamental design pattern. You'll use it everywhere: database, API, cache, file system.

6. MVVM & Separation of Concerns

UI logic separate from data logic. Test each independently. This applies to all platforms: mobile, web, desktop.

7. Progressive Enhancement

Start simple (chronological feed), then add complexity (ranking, recommendations, real-time). Build incrementally.

Congratulations!

You've completed your first mobile system design case study! You've learned:

✓ How to clarify requirements through questions ✓ How to design simple, clear APIs ✓ How to architect a mobile app with clear separation of concerns ✓ How to make feeds fast through intelligent caching ✓ How to make apps work offline with optimistic updates ✓ How to handle edge cases and errors

You now understand the fundamentals that every successful mobile app uses. From Instagram to Twitter to TikTok, they all use pagination, caching, and offline-first thinking. You've demystified the magic.

What's Next?

You've completed Case Study 1. In future case studies, you'll design:

• Case Study 2: A real-time chat app (WebSockets, message ordering, typing indicators)
• Case Study 3: A location-based service like Uber (maps, location tracking, real-time matching)
• Case Study 4: A music streaming app (large media files, background playback, offline mode)
• Case Study 5: A news aggregation app (personalization, ranking, filtering)

Each case study will reuse patterns from this one (caching, offline, pagination) but introduce new challenges specific to that domain.

Interview Pro Tips

If you're using this case study to prepare for a system design interview:

Before the Interview

1. Read this case study two or three times, not just once
2. Code the examples in Kotlin or Swift. Don't just read; write.
3. Practice explaining each section to a friend. If you can't explain it simply, you don't understand it.
4. Draw the architecture diagram from memory (not looking at these notes)

During the Interview

1. Ask clarifying questions first (just like the mock interview in Section 1)
2. Start simple (chronological feed, basic caching)
3. Then add complexity (push notifications, video, ranking)
4. Be ready to pivot if the interviewer says "now make it support X" (like we did in Variations)
5. Talk through your thinking out loud. The interviewer wants to hear your reasoning, not just your final answer.

Red Flags to Avoid

• ❌ Designing for millions of users before even designing for one user
• ❌ Choosing complex tech without explaining why (GraphQL when REST works fine)
• ❌ Forgetting offline support entirely
• ❌ Assuming the API is fast and never fails
• ❌ Designing a perfect solution instead of a working solution

Green Flags (What Interviewers Love)

• ✓ Asking clarifying questions
• ✓ Starting simple and adding complexity
• ✓ Acknowledging trade-offs ("This caching strategy is fast but uses more memory")
• ✓ Thinking about real-world constraints (offline, slow networks, limited battery)
• ✓ Mentioning testability ("This repository can be mocked for unit tests")
• ✓ Handling errors ("If the post was deleted on the server, here's how we handle it")

Further Reading

If you want to dig deeper:

• MVVM Architecture: Search for "Android MVVM Architecture Guide"
• Repository Pattern: Look up "Repository Pattern in Android"
• Coroutines (Kotlin): "Kotlin Coroutines for Beginners"
• Async/Await (Swift): "Swift Concurrency" in Apple docs
• REST API Design: "RESTful Web Services Best Practices"
• Mobile Caching: "Effective Caching Strategies for Mobile Apps"

Final Thoughts

Mobile system design isn't about memorizing the "right" answer. It's about thinking systematically about trade-offs and constraints.

Every design decision you make:

• Speeds up one thing, slows down another
• Improves user experience in one way, makes code more complex in another
• Works for 100 users but breaks at 1 million

The best engineers aren't those who know the "perfect" architecture. They're those who understand the trade-offs and can explain their choices clearly.

You've now learned how to do that. You've got this!

Ready for More?

Great job completing this case study! You understand:

• How to design a mobile feed app
• The caching strategies that make apps fast
• Offline-first thinking
• Optimistic updates

In the next case study, you'll apply these lessons to a real-time chat app, where new challenges (message ordering, read receipts, typing indicators) require different solutions.

You're building toward mastery. Keep going!

Back to Mobile System Design Interviews