How the interviewer opens it
“Design a photo sharing social app like Instagram. Users can post photos, follow other users, browse a home feed, and like and comment on posts.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Product behavior
- Users and social graph
- Traffic and read:write mix
- Peaks and skew
- Photo sizes
- Feed semantics
- Latency
- Consistency versus availability
- Durability and retention
- Deployment and exclusions
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Publish a photo with a caption and view an author's posts
- Follow and unfollow users
- Read a home feed of posts from followed users
- Like, unlike, and comment on posts
Usually out of scope
- Video, stories, live streaming, and multi-photo posts
- Search, recommendations, and ads
- Building authentication or a content moderation system
- Cross-region write availability
What interviewers probe
- Publishing a photo without exposing a broken post
- Uploading bytes, generating variants, committing metadata, and making a post eligible for feeds cross different systems. Partial success is normal, and retries must not create duplicate posts or publish missing images.
- Feed fan-out under celebrity skew
- An approach that is cheap for an author with 200 followers becomes a burst of 50 million writes for a celebrity. Pure read-time assembly has the opposite problem for users following many authors.
- Pagination and follow changes in an asynchronous feed
- Feed entries arrive late, new posts appear between requests, and users change whom they follow. A fast materialized feed is not automatically a correct or stable view of those relationships.
- Correct interactions without a celebrity hot row
- A like has unique per-user state, while its displayed count is a heavily shared aggregate. Retried comments must remain distinct from intentional repeated comments, and celebrity traffic can overload a single post partition.
Common mistakes
- Spending most of the interview on account creation while barely defining feed generation or photo publication.
- Sending original photos through application servers or serving originals for every feed slot.
- Choosing fan-out-on-write for every author without calculating celebrity write amplification.
- Treating prepared feed caches as authoritative storage and having no rebuild path.
- Using offset pagination or ignoring follow/unfollow behavior in already-materialized feeds.
- Making displayed counts strongly consistent by updating one shared post row on every interaction.
The bar by level
- Senior (L5/E5)
- Uses the workload to justify feed materialization and a high-fan-out exception. Handles upload retries, safe publication, durable event delivery, cache rebuilding, follow changes, and idempotent interactions. Separates authoritative state from derived feeds and counts, and gives concrete failure behavior.
- Staff (L6+/E6+)
- Defines the consistency contract before promising guarantees. Quantifies bandwidth and fan-out costs, chooses push/pull boundaries from workload rather than folklore, and addresses backlog recovery without overwhelming storage. Explains hybrid-feed pagination limits, migration between feed strategies, hot interaction partitions, and how privacy or regional failure would change ownership and delivery.