Designing Instagram: A Deep Dive into Photo Sharing at Scale

Why Study Instagram?

Instagram handles 2 billion monthly active users, 500 million daily active users, and over 95 million photos/videos uploaded daily. Understanding how it's built reveals how to design massive-scale social platforms.

Requirements Analysis

Functional Requirements

1. User Management: Register, login, profile management
2. Photo Upload: Upload photos with filters and captions
3. Feed: See photos from followed users (ordered by recency or algorithmic)
4. Social Graph: Follow/unfollow users
5. Engagement: Like, comment, share
6. Search: Find users and hashtags

Non-Functional Requirements

High-Level Architecture

Photo Upload Flow

Step-by-Step

Key Design Decisions

Feed Design

The Fan-Out Problem

When you post a photo, it needs to appear in your followers' feeds. If you have 1 million followers, that's 1 million entries to write.

Push vs Pull Model

How Instagram Actually Does It

Instagram uses a hybrid approach:

1. Celebrity accounts (>10K followers): Don't fan out writes. Pull on read.
2. Regular accounts: Fan out writes to followers' feeds.
3. Cached feeds: Most users get served from cache, not computed fresh.

The feed retrieval checks the cache first. On a miss, it pulls posts from celebrity accounts and merges them with cached posts from regular follows. The combined posts are sorted by timestamp in descending order and paginated to the requested limit.

Database Schema

User Table

CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    username VARCHAR(30) UNIQUE NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    profile_photo_url VARCHAR(500),
    bio TEXT,
    follower_count INT DEFAULT 0,
    following_count INT DEFAULT 0,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_username ON users(username);
CREATE INDEX idx_follower_count ON users(follower_count);

Post Table

CREATE TABLE posts (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL REFERENCES users(id),
    image_url VARCHAR(500) NOT NULL,
    caption TEXT,
    like_count INT DEFAULT 0,
    comment_count INT DEFAULT 0,
    created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_user_id ON posts(user_id);
CREATE INDEX idx_created_at ON posts(created_at DESC);
CREATE INDEX idx_user_created ON posts(user_id, created_at DESC);

Follow Table

CREATE TABLE follows (
    follower_id BIGINT NOT NULL REFERENCES users(id),
    following_id BIGINT NOT NULL REFERENCES users(id),
    created_at TIMESTAMP DEFAULT NOW(),
    PRIMARY KEY (follower_id, following_id)
);

CREATE INDEX idx_following ON follows(following_id);

Storage Architecture

Photo Storage at Scale

Storage Estimates

Caching Strategy

Cache Hierarchy

Cache Keys

Cache keys use consistent naming conventions for different data types. Feed cache stores post IDs for a user's personalized feed, profile cache stores user objects, post cache stores individual posts, and timeline cache stores celebrity post IDs for pull-based retrieval.

Search Architecture

Search Features

Scaling Challenges & Solutions

Key Takeaways

1. Minimize writes at upload: Use presigned URLs for direct S3 upload
2. Balance push vs pull: Hybrid model handles both small and large accounts
3. Cache aggressively: Feed, profile, and post caches dramatically reduce DB load
4. Async everything: Image processing, notifications, analytics - use queues
5. Tier storage: Not all data needs to be hot; move old content to cold storage

Follow-Up Questions to Consider

1. How would you handle video uploads (much larger files)?
2. How would you implement the Explore page (algorithmic discovery)?
3. How would you prevent spam and fake accounts?
4. How would you design direct messaging?
5. How would you handle real-time notifications?