Problem and Scope
Design a system like Instagram that allows users to upload photos, follow other users, and see a newsfeed of photos from people they follow.
Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.
Requirements to Clarify
A strong answer should establish scope before choosing components.
Functional requirements:
- Users should be able to upload photos from mobile devices
- Users should be able to follow and unfollow other users
- Users should be able to view a newsfeed of photos from users they follow
- Users should be able to view individual profiles with all photos from a specific user
- Photos should be accessible quickly with minimal loading time
Non-functional requirements:
- The system should scale to support at least 10 million users
- The system should handle a large volume of photo uploads (assume each user uploads 2 photos per month on average)
- The newsfeed should load quickly, even for users who follow many accounts
- Photos should be stored reliably and remain accessible even if some servers fail
- The system should support a read-heavy workload (many more views than uploads)
Scale and Capacity
Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:
- 10 million active users per month
- Each user uploads approximately 2 photos per month
- Each photo is approximately 5MB in size
- Read to write ratio of approximately 100:1 (many more views than uploads)
- New uploads generate around 100TB of data per month
Architecture Discussion
Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:
- Database design for user data, photo metadata, and follow relationships
- Storage solution for the actual photo files
- Service architecture for handling uploads, follows, and newsfeed generation
- Caching strategy for frequently accessed data
- CDN for efficient photo delivery
- Load balancing and scaling approach
- Efficiently storing and serving large volumes of photos
- Generating newsfeeds in real-time for millions of users
- Handling the read-heavy workload without overloading databases
- Ensuring high availability and durability for photo storage
- Optimizing for mobile clients with potentially slow or intermittent connections
Follow-up Questions
Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:
- How would your feed generation system handle users who follow thousands of accounts?
- Focus: Assess the candidate's answer to "How would your feed generation system handle users who follow thousands of accounts" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- What trade-offs did you consider when choosing your photo storage solution?
- Focus: Assess the candidate's answer to "What trade-offs did you consider when choosing your photo storage solution" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your system ensure photos remain available even if some servers fail?
- Focus: Assess the candidate's answer to "How would your system ensure photos remain available even if some servers fail" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- Can you explain how the caching strategy you've chosen addresses the read-heavy workload?
- Focus: Assess the candidate's answer to "Can you explain how the caching strategy you've chosen addresses the read-heavy workload" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
- How would your design scale if the user base grew to 100 million users?
- Focus: Assess the candidate's answer to "How would your design scale if the user base grew to 100 million users" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
Evaluation Rubric
MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.
- Requirements and scope (15%): Clarifies and prioritizes the required behavior for Users should be able to upload photos from mobile devices; Users should be able to follow and unfollow other users; Users should be able to view a newsfeed of photos from users they follow. Establishes the constraints that materially affect Design Instagram (Feed & Photo Upload), including The system should scale to support at least 10 million users; The system should handle a large volume of photo uploads (assume each user uploads 2 photos per month on average). Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
- Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Database design for user data, photo metadata, and follow relationships; Storage solution for the actual photo files; Service architecture for handling uploads, follows, and newsfeed generation; Caching strategy for frequently accessed data. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
- Data and scaling (25%): Uses workload assumptions such as 10 million active users per month; Each user uploads approximately 2 photos per month to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Database design for user data, photo metadata, and follow relationships; Storage solution for the actual photo files; Caching strategy for frequently accessed data. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
- Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Ensuring high availability and durability for photo storage; Photos should be stored reliably and remain accessible even if some servers fail. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
- Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Handling the read-heavy workload without overloading databases; Ensuring high availability and durability for photo storage; Optimizing for mobile clients with potentially slow or intermittent connections. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.