Design a Mobile Photo Sharing App

Understanding the Problem

Designing a mobile photo sharing application is a common mobile system design interview question. It tests your ability to create a mobile-first architecture that handles media content efficiently while providing a responsive and engaging user experience.

This problem requires consideration of mobile-specific challenges such as:

• Efficient image processing and storage
• Bandwidth optimization for mobile networks
• Responsive UI across different screen sizes
• Battery usage optimization
• Offline capabilities

Functional Requirements

Let's define what our mobile photo sharing app needs to do:

• Users can create accounts and profiles
• Users can upload and delete photos
• Users can add captions and tags to photos
• Users can like and comment on photos
• Users can follow other users
• Users can view a feed of photos from users they follow
• Users can search for photos by tags or users
• The app should provide push notifications for social interactions

Non-Functional Requirements

These requirements define how our system should behave:

• Performance

  The app should load images quickly with minimal lag, ideally under 2 seconds

• Reliability

  The app should be available 99.9% of the time

• Scalability

  The system should handle millions of users and photos

• Security

  User data and photos should be securely stored and transmitted

• Network Efficiency

  Optimize for mobile data usage with appropriate caching strategies

• Battery Efficiency

  Minimize battery drain during app usage

• Offline Support

  Basic functionality should work without an internet connection

The Setup

For our mobile photo sharing app, we need to define several key entities:

• User

  • userId: string (unique identifier)
  • username: string
  • email: string
  • profilePicture: string (URL)
  • bio: string
  • followers: User[]
  • following: User[]

• Photo

  • photoId: string (unique identifier)
  • userId: string (uploader)
  • imageUrl: string (URL to the stored image)
  • caption: string
  • tags: string[]
  • createdAt: timestamp
  • likes: number

• Comment

  • commentId: string (unique identifier)
  • photoId: string (reference to the photo)
  • userId: string (commenter)
  • text: string
  • createdAt: timestamp

• Like

  • likeId: string (unique identifier)
  • userId: string (liker)
  • photoId: string
  • createdAt: timestamp

• Follow

  • followerId: string
  • followedId: string
  • createdAt: timestamp

• Notification

  • notificationId: string
  • userId: string (recipient)
  • type: "like" | "comment" | …
  • entityId: string (photo/comment id)
  • createdAt: timestamp
  • read: boolean

Rough capacity planning for each core entity on launch-day (mobile only):

• Users — 10 M daily active users (DAU)
• Photos — 20 M new uploads per day (≈ 2 photos / DAU)
• Comments — 60 M comments per day (3 comments / photo)
• Likes — 400 M likes per day (~20 likes / photo)
• Follows — 150 M follow edges created per month (viral growth)
• Notifications — 600 M push notifications per day (likes, comments, follows)
• Feed API read/write ratio ≈ 100 : 1 — viewing far exceeds posting

The API

Here are the key API endpoints our mobile app will need:

{
  "username": "photouser",
  "email": "user@example.com",
  "password": "securepassword"
}

{
  "image": "base64encodedimage",
  "caption": "Beautiful sunset!",
  "tags": [
    "sunset",
    "nature",
    "photography"
  ]
}

High Level Design

Our mobile photo-sharing app uses a thin client / fat-service architecture. The diagram below shows the main runtime components.

1. 1
   Mobile App (Client)

   The native mobile application that users interact with directly.

2. 2
   API Gateway

   Routes requests from the mobile app to backend services.

3. 3
   Backend Services

   Each service owns a slice of domain logic:

   • User Service — profiles & social graph
   • Photo Service — uploads, storage, metadata
   • Feed Service — personalised timelines
4. 4
   Storage

   Database, object-storage and cache layers.

   • Database: stores user data, relationships, metadata
   • Object Storage: actual photo files
   • Cache: hot rows / images for quick retrieval

Mobile Client Architecture

For the mobile client, we'll use the MVVM (Model-View-ViewModel) architecture:

• Separation of concerns for better code organization
• Improved testability of business logic
• Reactive UI updates through data binding
• Better state management for complex screens

Potential Deep Dives

In a mobile system design interview, you may be asked to deep dive into specific components:

• 1) How can we optimize image loading and caching?

  • Progressive image loading
  • Multiple image resolutions for different screen sizes
  • Local caching with LRU (Least Recently Used) eviction policy
  • Prefetching images that are likely to be viewed next
  • Lazy loading images as the user scrolls

• 2) How can we implement offline functionality?

  • Implement a local database to store feed data
  • Queue uploads and actions when offline
  • Sync with server when connectivity is restored
  • Implement conflict-resolution strategies
  • Show appropriate UI indicators for offline state

• 3) How can we optimize battery usage?

  • Batch network requests
  • Optimize image processing operations
  • Use efficient background processing
  • Implement adaptive polling frequencies
  • Reduce wake locks and unnecessary background activities

What is Expected at Each Level?

The depth and breadth of your response should vary based on your experience level. Here's what interviewers typically expect: