AlgoInsight

Free lesson · Mobile System Design Interviews

Social Feed App - Problem & Discovery

Medium5 min readmobilemobile-system-designinterview-prep

Think Before You Speak: 30 Seconds Inside an Engineer's Brain

Imagine an interviewer says: "Design the mobile client for a social media feed, like Instagram's home feed."

Here's what's racing through an experienced engineer's mind in the first 30 seconds:

  1. What am I actually building? A screen where users scroll through posts, not the entire backend system.
  2. What's hard about this? Loading a million posts smoothly without crashing the app. Managing images. Working offline. Handling when you like a post really fast.
  3. What questions should I ask? The interviewer is testing whether I think before I code.
  4. What does success look like? A smooth, responsive feed that users can scroll through for hours without frustration.

The key insight: Don't assume you understand the problem. Ask questions first.

What Is a Social Feed App?

Let's start with the basics. A social feed is the scrolling list of posts you see when you open Instagram, Twitter, or Facebook. Each post might have:

The feed keeps going: When you scroll down, new posts load automatically. It's like an endless list (developers call this "infinite scroll"). Users should never hit a "dead end" where there's nothing left to scroll to—or at least not until they've seen hundreds of posts.

The mobile context: We're building this for phones (iOS and Android), not a web app. This means we care about battery, data usage, memory, and smooth animations on devices with varying processing power.

The Problem Statement

Your task: Design the mobile client architecture for a social media feed application. Users should be able to:

The scope: We're focusing on the mobile client (the app itself), not the backend server or the algorithm that decides which posts appear first. We'll talk to the backend through APIs, but we're not designing that system.

Step 1 in Action: Mock Interview

Let's watch a candidate think through this problem with an interviewer. Notice how the candidate asks clarifying questions—this is the most important skill in system design interviews.

Candidate: "Thanks for the problem. Before I dive in, I want to make sure I understand what we're building. Let me ask a few clarifying questions."

Interviewer: "Great, go ahead."

Candidate: "First, what types of content can users post? Just text and images, or video too?"

Interviewer: "Good question. Start with text and images for simplicity. Videos are a variation we can discuss later if you want."

Candidate: "Perfect. Next—what interactions do users expect? Can they like, comment, and share posts?"

Interviewer: "Yes, all three. In fact, likes and comments are the most important—users see like counts and comment counts prominently."

Candidate: "Got it. Now, about the feed itself: should it be chronological—newest posts first—or do we rank posts algorithmically, like showing posts with more engagement higher?"

Interviewer: "Excellent question. Let's keep it chronological to start. Ranking is a complexity we can add later."

Candidate: "Understood. One more important question: does the app need to work when there's no internet? Offline support?"

Interviewer: "Yes, the user should be able to see previously loaded posts even without internet. They can't fetch new posts, but they can read what's already loaded."

Candidate: "Smart. So the app should cache posts locally. Last few questions: what's the scale? Are we talking thousands of users, millions, or billions?"

Interviewer: "Let's assume the app has 100 million monthly active users, but focus on what a single user experiences, not the server-side scale."

Candidate: "And we're building for both iOS and Android?"

Interviewer: "Yes, the architecture should work for both platforms."

Candidate: "Great! One final thing: are we handling creating posts in this case study, or just viewing?"

Interviewer: "Viewing is the priority. Mention creating posts in your architecture, but we'll focus more on the feed viewing experience."

Functional Requirements

Based on the conversation above, here's what our app must do:

Non-Functional Requirements

These are the invisible requirements—they're about how well the app works, not what it does:

Out of Scope

What we're not designing in this case study:

🔗 Building on Previous: Remember the 5-step framework from Module 2? We're starting at Step 1 (Problem & Discovery). You should write down the functional and non-functional requirements, then move to Step 2 (API Design). The toolbox from Module 3 will help us decide which caching strategies to use—we'll revisit that later.

UI Sketch Description

Here's what the key screens look like (imagine taking a screenshot of these):

Feed Screen:

Post Detail Screen:

Create Post Screen:

What's Next?

You've discovered the problem. Next, we'll design the API that the mobile app will call to fetch posts and submit interactions. This is Step 2 of the framework: API Design.

Back to Mobile System Design Interviews