1. Introduction & Why Social Media Feed is Hard

Designing a social media feed system — the kind that powers Twitter, Instagram, Facebook, and TikTok — is one of the most classic and challenging problems in distributed systems engineering. At its surface, the concept appears deceptively simple: users create posts, and their followers see those posts in a personalized timeline. Under the hood, however, the system must handle billions of events per day, deliver content with sub-second latency, rank hundreds of candidate posts per request, and gracefully handle celebrity users whose single post can generate millions of fan-out events.

The social media feed problem is a cornerstone of system design interviews at every major tech company, from FAANG startups to mid-size platforms scaling their first million users. It touches virtually every distributed systems concept: consistent hashing, eventual consistency, write-ahead logs, message queues, caching hierarchies, graph databases, machine learning inference pipelines, and real-time streaming. As a senior or staff engineer, you are expected to navigate the full spectrum of these trade-offs while making pragmatic architectural choices that match your scale constraints.

Why This Problem Is Uniquely Challenging

The core tension in a feed system is the conflict between three competing objectives that cannot all be simultaneously maximized:

• Low latency: Users expect their feed to load in under 200ms, even on mobile networks with high latency.
• Freshness: When a user's friend posts something important, it should appear in their feed within seconds, not minutes.
• Ranking quality: A chronological feed is trivial but results in poor engagement. A ranked feed requires expensive ML inference per request.

The "celebrity problem" is what truly separates feed systems from simpler content distribution systems. When a user with 100 million followers posts a tweet, a naive fan-out-on-write approach would attempt to write that post into 100 million timeline caches simultaneously. This single operation would generate more write load than most database clusters can handle in a day. The solution requires a hybrid approach that balances precomputation with on-demand assembly, and this hybrid is the heart of every major social media feed architecture.

The Real-World Scale

Consider the numbers that define the problem space at Twitter-scale: approximately 400 million daily active users, 500 million tweets posted per day, 1.2 billion timeline requests per day, and an average of 200 milliseconds to serve a timeline. Every design decision — from the choice of storage engine to the caching topology — must be evaluated against these concrete throughput and latency requirements.

Instagram faces a similar challenge but with a media-heavy twist: every post contains at least one image or video, which means the feed system must seamlessly integrate with a content delivery network and media processing pipeline that can handle petabytes of image uploads daily. TikTok adds another dimension with its algorithm-first approach, where the feed is entirely ranked by engagement prediction models, making the ML inference pipeline a critical path component rather than an enhancement.

What Makes a Great Feed System Design

A great social media feed system design demonstrates mastery of several engineering principles: choosing the right consistency model for each component, designing for graceful degradation under load, building observability into every layer, and understanding the economic trade-offs of every architectural decision. The best designs also acknowledge what they choose not to do — the scope boundaries that keep the system manageable as it scales from millions to billions of users.

This guide walks through every major component of a social media feed system, from the data model that stores follows and posts, through the fan-out engines that precompute timelines, to the ranking models that determine what users actually see. Each section includes production-grade C# code, Mermaid architecture diagrams, and real-world lessons learned from companies operating at massive scale.

2. Functional & Non-Functional Requirements

Functional Requirements

The functional requirements define what the system must do from the user's perspective. For a social media feed system, these requirements break down into several distinct capability areas that must work together seamlessly.

Non-Functional Requirements

The non-functional requirements define the quality attributes that the system must satisfy. These requirements often drive the architectural decisions more than the functional requirements, because they define the constraints within which all design choices must be made.

Scope Boundaries

A critical aspect of any system design is clearly defining what is out of scope. For this design, we explicitly exclude: direct messaging (a separate real-time system), live streaming (requires dedicated media infrastructure), advertising delivery (a complex auction and targeting system), and content recommendation for new users (a cold-start ML problem). These are all important subsystems that would each warrant their own deep-dive design document.

3. Capacity Estimation & Back-of-Envelope

Capacity estimation grounds the design in concrete numbers and prevents over-engineering. Every architectural choice should trace back to a specific throughput or storage requirement. We begin by establishing baseline traffic assumptions and then derive storage, bandwidth, and compute requirements from those baselines.

Assumptions

Throughput Calculations

Feed reads represent the dominant workload. With 300 million DAU making 10 feed requests per day, we need to serve 3 billion feed reads per day. That translates to approximately 35,000 feed reads per second at the average, with peak traffic reaching 3x that at roughly 100,000 reads per second during evening hours in major time zones. Each feed request returns approximately 50-100 posts, meaning we must assemble and rank up to 10 million post objects per second at peak.

Post creation generates approximately 500 million posts per day, or about 5,800 posts per second on average. Peak post creation occurs around lunchtime and evening hours, reaching approximately 15,000 posts per second. Each post creation triggers a fan-out operation that must be processed within seconds, so the fan-out pipeline must handle bursts of 15,000 posts per second multiplied by the average fan-out count.

Storage Calculations

Post metadata (excluding media) requires approximately 800 bytes per post. With 500 million posts per day, that is 400 GB per day or approximately 146 TB per year of post data alone. The follow graph, assuming an average of 200 follows per user across 600 million users, stores 120 billion follow edges at approximately 32 bytes per edge, totaling about 3.8 TB. Timeline caches, storing the precomputed timeline of 50 post IDs per user for 300 million active users, require approximately 480 GB. With replication factor of 3 for durability, total cache storage reaches 1.44 TB.

C#
public class CapacityEstimator
{
    public static FeedCapacity Estimate(PlatformConfig config)
    {
        var dailyFeedReads = config.DailyActiveUsers * config.FeedReadsPerUserPerDay;
        var avgFeedReadsPerSecond = dailyFeedReads / 86400.0;
        var peakFeedReadsPerSecond = avgFeedReadsPerSecond * config.PeakMultiplier;

        var dailyPosts = config.DailyActiveUsers * config.AvgPostsPerUserPerDay;
        var avgPostsPerSecond = dailyPosts / 86400.0;
        var peakPostsPerSecond = avgPostsPerSecond * config.PeakMultiplier;

        var postsPerFeed = 50;
        var candidatePoolMultiplier = 10.0;
        var candidatesPerFeedRequest = postsPerFeed * candidatePoolMultiplier;

        var postsToRankPerSecond = peakFeedReadsPerSecond * candidatesPerFeedRequest;

        var postMetadataBytes = 800;
        var storagePerDayBytes = dailyPosts * postMetadataBytes;
        var storagePerYearBytes = storagePerDayBytes * 365;

        return new FeedCapacity
        {
            AvgFeedReadsPerSecond = (long)avgFeedReadsPerSecond,
            PeakFeedReadsPerSecond = (long)peakFeedReadsPerSecond,
            AvgPostsPerSecond = (long)avgPostsPerSecond,
            PeakPostsPerSecond = (long)peakPostsPerSecond,
            PostsToRankPerSecond = (long)postsToRankPerSecond,
            DailyStorageBytes = storagePerDayBytes,
            YearlyStorageBytes = storagePerYearBytes,
            StoragePerYearTB = storagePerYearBytes / (1024.0 * 1024.0 * 1024.0 * 1024.0)
        };
    }
}

Bandwidth Calculations

Inbound bandwidth for post creation is relatively modest: 15,000 posts per second at 800 bytes each equals approximately 12 MB/s. However, media uploads dominate: if 40% of posts include an average 2 MB image, that is 6,000 image uploads per second at 2 MB each, totaling 12 GB/s of inbound media bandwidth. Outbound bandwidth for feed serving is more significant: 100,000 feed requests per second, each returning approximately 40 KB of metadata plus 10 media URLs (each resolving to a 200 KB thumbnail via CDN), totals approximately 24 GB/s of CDN-served content at peak.

Cost Implications

At 146 TB/year of raw post storage with 3x replication, we need approximately 438 TB/year of database storage. Using cloud storage at roughly $0.023/GB/month for standard storage, that is approximately $121,000/month or $1.45 million/year just for post data storage. Adding timeline caches, social graph storage, and search indexes pushes total storage costs to approximately $3-5 million per year. Compute costs for the ranking pipeline, fan-out workers, and API servers typically run 3-5x storage costs, putting total infrastructure spend in the $15-25 million per year range. These numbers align with what companies like Twitter and Pinterest have publicly disclosed about their infrastructure budgets.

4. Data Model & Storage Schema

The data model is the foundation of the entire system. Every query pattern, every cache key, and every index must be designed to support the specific access patterns of a social media feed. The two dominant data models in this space are the relational model (used by early Twitter) and the graph-native model (used by Facebook). Most modern systems use a hybrid, combining relational stores for transactional data with specialized stores for different query patterns.

Core Entities

C#
public class User
{
    public long UserId { get; set; }
    public string Username { get; set; }
    public string DisplayName { get; set; }
    public string Email { get; set; }
    public string ProfileImageUrl { get; set; }
    public string Bio { get; set; }
    public int FollowerCount { get; set; }
    public int FollowingCount { get; set; }
    public int PostCount { get; set; }
    public bool IsVerified { get; set; }
    public bool IsPrivate { get; set; }
    public UserTier Tier { get; set; }
    public DateTime CreatedAt { get; set; }
    public DateTime LastActiveAt { get; set; }
}

public enum UserTier
{
    Normal = 0,
    Power = 1,
    Celebrity = 2
}

public class Post
{
    public long PostId { get; set; }
    public long AuthorId { get; set; }
    public string Content { get; set; }
    public PostType Type { get; set; }
    public long? ReplyToPostId { get; set; }
    public long? RepostOfPostId { get; set; }
    public List<MediaAttachment> Media { get; set; }
    public List<string> Hashtags { get; set; }
    public List<long> MentionedUserIds { get; set; }
    public int LikeCount { get; set; }
    public int RetweetCount { get; set; }
    public int ReplyCount { get; set; }
    public int ViewCount { get; set; }
    public DateTime CreatedAt { get; set; }
    public ContentVisibility Visibility { get; set; }
    public double? RankingScore { get; set; }
}

public enum PostType
{
    Original = 0,
    Reply = 1,
    Repost = 2,
    QuoteRepost = 3
}

public enum ContentVisibility
{
    Public = 0,
    FollowersOnly = 1,
    MentionedOnly = 2,
    Private = 3
}

public class MediaAttachment
{
    public long MediaId { get; set; }
    public MediaType Type { get; set; }
    public string OriginalUrl { get; set; }
    public string ThumbnailUrl { get; set; }
    public string MediumUrl { get; set; }
    public int Width { get; set; }
    public int Height { get; set; }
    public int DurationMs { get; set; }
}

public enum MediaType
{
    Image = 0,
    Video = 1,
    Gif = 2
}

Social Graph Model

C#
public class FollowRelationship
{
    public long FollowerId { get; set; }
    public long FolloweeId { get; set; }
    public DateTime FollowedAt { get; set; }
    public FollowStatus Status { get; set; }
    public bool Muted { get; set; }
    public bool NotificationsEnabled { get; set; }
}

public enum FollowStatus
{
    Active = 0,
    Blocked = 1,
    Muted = 2
}

public class TimelineEntry
{
    public long UserId { get; set; }
    public long PostId { get; set; }
    public long AuthorId { get; set; }
    public DateTime PublishedAt { get; set; }
    public double RankingScore { get; set; }
    public TimelineSource Source { get; set; }
}

public enum TimelineSource
{
    Follow = 0,
    Recommended = 1,
    Trending = 2,
    Promoted = 3
}

Storage Choices