Requirements

Functional Requirements:

• User is able to post images/videos
• User is able to follow each other
• User is able to view their home feed
• User is able to like other posts
• User is able view their and others user profile.

Non-Functional Requirements:

• Low latency <150ms feed latency
• High availability: 99.9% uptime
• Massive read scalability
• Eventual consistency for feed
• Global media delivery
• Strong consistency for follows and likes

Capacity Estimation

• 1B users
• 200M DAU
• 50M posts/day
  • ~600 posts/sec
  • Peak traffic: 5x - 3k posts/sec
• 10B feed reads/day
  • ~120K /sec
  • peak traffic: 5x ~600K/sec
• Media heavy traffic - CDN dominant
• Storage
  • Raw:
    • Avg size ~10MB
    • Per day: 50MB x 10MB = 500TB
    • Per year: ~19PB
  • On Avg each media size ~2Mb after resizing and compressing
  • Per day: 50M x 2MB = 100TB perday
  • Per year: ~ 3.7PB
• CDN cache footprint:
  • Only hot content is stored and remains in CDN which is approx ~10% of daily posts
  • so 5M media stays in CDN
  • 5M x 2MB average size = ~10TB cache footprint

API Design

Post Service

POST /posts

• create post record
• create media records and generates pre signed media urls of object storage
• emits PostCreated event
• returns pre signed urls

POST /posts/{id}/like

• Likes a post

Media service

POST /media/uploads/complete

• rezises and compresses media
• Generates thumbnail
• Saves to object storage

Feed Service

GET /feed?cursor=x

• Returns feed ~20items per requests
• Paginated using cursor which tells last item seen

user service

POST /users -> create users

GET /users/{id}/profile -> returns user profile

POST /users/{id}/follow -> creates social graph between two users

High-Level Design

API Gateway

Acts as the entry point for all client requests.

Responsibilities:

• Authentication (if required)
• Rate limiting - Applied using token bucket per IP to prevent fraudulent or bot views
• Request routing

Load Balancer

Distributes traffic across multiple instances of all services to improve scalability and availability.

Post service

• Creates post record
• Generates pre signed media urls for object storage
• Creates associated media records
• Emits PostCreated Event to kafka for async processing for feed.
• Also handles post likes, it emits PostLiked event

Media Service

• Receives request after post is created
• recieves the pre signed url to upload the medias
• Resizes and compresses images and videos
• Uploads to the pre signed urls
• Implements retries wiht exponential backoff for uploads
• Updates media status in PostMedia table

Feed Service

Responsibilites

• Returns feed from redis
• Fetches precomputed feed from redis
• Fetches users celeb follow list
• Fetches celeb feed from redis: recent N posts
• Merges and deduplicates both feeds and passes onto rank service for ranking post
• for the ranked feed, fetches post metadat
• Returns back the ranked paginated feed
• Pagination
  • Cursor based
  • Cursor timestamp + postid
  • Avoid duplicats and ordering issues

Rank Service

• Ranks the list of posts it recives
• Score is based on recencym engagement, likes etc
• Score = w1 * recency + w2 * engagement + w3 * like velocity

Kakfa

• Recieves PostCreated event
• Uses PostId + UserId as partition key

Fanout service

• Consumes PostCreated event
• Updates user feed in redis
• Implements hybrid fanout strategy:
  • Fanout-on-read -> normal user
    • Adds the post of a user to all their followers feed when post is created
  • Fanout-on-write -> celeb user
    • Adds the post to a celeb store in redis
      • celeb_post:userId -> sorted set
    • On reads all user's followed celeb recent posts is fetched from here.

Like aggregator service:

• Consumes PostLiked event
• Updates
  • Like table in Cassandra
  • Also updates redis like counter(post metadata) -> fast reads

User service:

• Creates users
• Handles follows
• Gets user profile

Redis

• Cahcing layer not source of truth
• Feed
  • Stores user feed and celeb fee
  • User feed - fanout-on-read, precomputed by fanout service
  • Celeb feed - fanout-on-write, all celeb posts lives here.
• Post Metadata
  • used to store post metadata for quick and fast response
  • We do lazy laoding on redis cache -> that is when a very first request comes in from a post, fetch metadata from DB then store in redis so subsequent rquest will be fetched from redis
  • TTL is short lived ~1hr

CDN

• Caching layer, storing media files and posts thumbnails
• All request for media goes to CDN first, as mentioned not all videos info is stored in CDN, only hot vidoes are stored in CDN.
• If CDN cache miss -> fetch from object storage
• Uses multi region setup so media is fetched from nearest cdn egde -> fast reads

PostreSQL + Casandra

• Primary persistent storage
• PostrSQL -> user,follow
• NoSQL -> Post, Like, PostMedia

Database Design

We use a hybrid SQL (PostgreSQL) + NoSQL (Cassandra) architecture.

• SQL is used for strongly consistent relational data like Users, Follow, where relationships and transactions matter.
• NoSQL (Cassandra) is used for high-scale data like Posts, PostMedia Likes, due to its horizontal scalability and high write throughput.

Data Model:

User

id (PK, partition key)

username

profilepc

POST

id (PK, partition key)

userid

mediaIds[]

caption

createdAt

user -> post: 1:many relationship

PostMedia

id (PK)

url

postId (partition key)

Status -> pending, uploaded, failed

POST -> PostMedia : 1:many relatiopnship

Follow

followerId (paritionKey)

followeeId

Like

id

userId

postId

value (1,-1) liked, disliked

User <-> follow: many:many relationship

Detailed Component Design

Now we will deep dive in these topics:

hot content Problem

-> Viral posts - millions of likes/reads

This is solved by our CDN + Like aggregator serivce + Redis

CDN -

• Caches the post media
• On read of viral posts -> cdn returns back the media -> fast reads

Redis

• Caches post metadata
• on post read /feed read -> fetch metadata from redis -> fast read

Likes

• Like aggregator service is async processing
• Is designed to handle the hot content problme
• When millions of likes are coming in for a post, kakfa consumes those event
• Consumers of those services process those events.

GLOBAL CDN + Multi-region setup:

• users routed to nearest region
• media uploaded to regional bucket
• async replication across regions
• Flow:
  • User → Nearest CDN → Regional Storage → Global Replication

FAILURE HANDLING (CRITICAL 9+ SECTION)

Kafka failures

• retry with exponential backoff
• DLQ for poison messages
• replay from offsets

Fanout service crash

• partial feed writes allowed
• Kafka replay reconstructs state

Redis failure

• rebuild from:
  • Kafka logs OR DB scan
• cache is disposable

CDN failure (REGIONAL)

fallback:

CDN → origin region → cross-region fetch