Reddit

Assume 500M monthly active users, 100M daily active users, 2M active communities, 10M new posts per day, 100M new comments per day, and 1B vote mutations per day. Each daily active user reads about 50 listing pages and 25 comment pages per day.

Assume an average post serving record is 2 KB, an average comment record is 1 KB, and each retained vote mutation or dedupe record averages 120 bytes before replication and indexing. Peak site traffic is 10 times average, while a single viral post or comment can experience much higher target-local vote contention.

• Listing reads: 100M daily active users times 50 listing pages is 5B listing page reads per day. 5B divided by 86,400 seconds is about 57,870 reads per second, rounded to 58,000. A 10x peak gives about 580,000 listing reads per second.
• Comment reads: 100M daily active users times 25 comment pages is 2.5B comment page reads per day. 2.5B divided by 86,400 seconds is about 28,935 reads per second, rounded to 29,000.
• Posts: 10M posts per day divided by 86,400 seconds is about 116 posts per second on average.
• Comments: 100M comments per day divided by 86,400 seconds is about 1,157 comments per second, rounded to 1,200. Peak comment writes at 10x are about 12,000 per second.
• Votes: 1B vote mutations per day divided by 86,400 seconds is about 11,574 votes per second, rounded to 11,600. A 10x peak is about 116,000 vote writes per second.
• Content storage: 10M posts times 2 KB is about 20 GB per day. 100M comments times 1 KB is about 100 GB per day. Together that is about 120 GB raw per day.
• Vote storage: 1B vote records times 120 bytes is about 120 GB raw per day. If the system keeps both latest vote state and immutable vote events, budget more.
• Annual storage: 240 GB raw per day for content plus votes is about 88 TB raw per year. With 3x replication, secondary indexes, materialized views, tombstones, and compaction headroom, plan for roughly 250 to 350 TB per year.
• Listing cache: if 2M active communities keep 500 listing entries per common sort and each cached entry plus metadata averages a few hundred bytes, raw listing snapshots can reach hundreds of GB. Redis overhead, home-feed slices, and replication make 1 to 2 TB a reasonable hot cache budget.

• communities.name is unique and supports direct community routing.
• posts.community_id, created_at, post_id supports new listings and backfills.
• posts.community_id, hot_score, post_id supports precomputed hot listing materialization or ranking repair.
• comments.post_id, path supports loading comment subtrees in deterministic tree order.
• comments.post_id, parent_comment_id, best_score supports fetching the next page of children for a collapsed branch.
• votes.user_id, target_type, target_id is the logical primary key for one active vote per target per user.
• votes.target_type, target_id is useful for offline repair but should not be the synchronous counter path for viral targets.

A community owns many posts. A post owns many comments, and each comment may point to one parent comment in the same post. Users can cast at most one active vote per post or comment. Moderation status is stored on content records so read paths can filter or collapse removed content without querying moderation history.

At scale, split the logical schema into access-pattern tables. Use CommunitiesByName for name lookup, PostsByCommunityAndTime for new listings, CommentsByPostAndPath for tree retrieval, VoteStateByUserTarget for idempotent vote state, VoteCounterShardsByTarget for hot counter aggregation, and ListingItemsByCommunitySortBucket for hot, top, and rising pages.

Cassandra, DynamoDB, Bigtable, or ScyllaDB fit the high-write, partitioned access patterns. Use an append-only event log for post, comment, vote, and moderation events so ranking stores, search indexes, and analytics can be rebuilt. Keep personalized home feeds and subreddit listings as derived stores, not as the source of truth.

A strong Reddit design explains that each sort has a different purpose. New is primarily created_at descending. Top is score over a time window, such as hour, day, week, month, year, or all time. Controversial rewards high activity with a near-even split between upvotes and downvotes. Hot combines score and time decay so a fresh post with fast early votes can outrank an older post with more total votes.

A classic hot formula uses the sign of upvotes minus downvotes, the log of absolute score, and an age term divided by a decay constant. The exact constants are product choices. The point is to balance freshness and popularity while making the score monotonic enough for stable pagination.

Comments often use best ranking based on the Wilson lower bound confidence interval. A comment with 8 upvotes and 0 downvotes should not automatically outrank a comment with 5,000 upvotes and 500 downvotes if the confidence calculation says the larger sample is more reliable. This prevents tiny samples from dominating early.

The naive design updates the post row on every vote. That fails because a viral post becomes a single hot row, causing lock contention, write amplification, and high tail latency. Instead, store the caller's latest vote state separately from aggregate counters.

On each vote, read or conditionally update the vote state for user and target, compute the delta from the previous value, and append the mutation to the event stream. Counter consumers aggregate deltas into many shards chosen by target id plus random or time bucket. Reads sum recent shards or read compacted totals, accepting a small freshness delay.

This design supports retries and vote changes. If a user changes from downvote to upvote, the score delta is plus two. If a user repeats the same upvote with the same request id, the service returns success without double counting. For a viral target, batching shard updates every few hundred milliseconds is more important than exact per-request counters.

A thread can have a few comments or hundreds of thousands. Storing comments only as an adjacency list is simple but expensive when rendering large subtrees. Storing only a nested set is painful for inserts. A practical design combines parent_comment_id with a materialized path such as fixed-width sortable segments per level.

The comment API should never return the entire tree for a large thread. Return top-level comments sorted by best, include a bounded number of children per branch, and include continuation cursors for more replies. Deep levels can be collapsed by default to protect clients and servers.

Edits and removals should not break tree shape. A removed comment can remain as a tombstone if it has children, while its body is hidden. Moderators and authors may see different status details, so the read path needs viewer-aware filtering without changing the stable path order.

Community feeds are easier because all users share the same ranked candidate set, modulo safety, localization, and blocked users. Ranking workers can maintain materialized pages per community, sort, and time window. The first page of hot and new receives the shortest TTL and the highest refresh priority.

The personalized home feed is harder because it mixes many subscribed communities. Fanout-on-write to every subscriber is too expensive for very large communities and unnecessary for inactive users. Fanout-on-read from subscribed community candidate pools is simpler but can be slow for users subscribed to thousands of communities.

A hybrid design works well: precompute home slices for active users and heavy sessions, use fanout-on-read for long-tail users, and cap per-community dominance so one active community does not flood the feed. The home feed store can be rebuilt from subscription and ranking events.

Listings are expensive to compute and cheap to serve, so cache them aggressively but with explicit freshness boundaries. Cache keys should include community, sort, cursor, viewer safety class, locale if relevant, and time bucket. Hot first pages might live for 5 to 15 seconds, while cold community pages can live for minutes.

Vote counts shown on cached pages can be approximate. The UI can show the user's own vote immediately and reconcile aggregate counts later. If a moderator removes a post, cache invalidation must be faster than normal TTL. Maintain a small removal or deny-list cache checked before returning cached listing items.

Stable pagination is critical. If the rank of every item shifts after each vote, users will see duplicates or missing posts. Cursor tokens should include rank boundary and tie-breaker ids, and the backend should tolerate slightly stale rank snapshots for a browsing session.

A Reddit-like system is attacked through spam posts, coordinated voting, ban evasion, link abuse, harassment, and compromised moderator accounts. Moderation must be part of content creation, voting, ranking, and visibility decisions.

Signals include account age, karma history, device and IP reputation, community-specific rules, duplicate text similarity, link reputation, velocity of votes, reports, and moderator actions. Low-trust content can be rate-limited, shadow queued, demoted, or hidden pending review.

Moderator actions need auditability. The system should record who removed or approved content, which rule was applied, and whether automation or a human made the decision. Ranking workers must consume these events so removed content leaves hot listings quickly.

Alternative one is synchronous exact counters on posts and comments. It is simple and accurate for small systems but collapses under viral vote contention.

Alternative two is query-time ranking from the primary posts table. It avoids feed-store complexity but makes every listing read expensive and unpredictable.

Alternative three is full fanout-on-write personalized feeds. It provides fast home-feed reads for active users but is extremely expensive for huge communities and inactive subscribers.

Alternative four is pure fanout-on-read home feed composition. It is simpler and cheaper for inactive users, but high-subscription users may experience high latency unless candidate pools are cached aggressively.

Do not use a Reddit-style public ranking forum when the product requires strict chronological delivery, private one-to-one communication, or authoritative workflow state. For chat, collaboration, customer support tickets, or regulated records, design systems around access control, ordering guarantees, and audit requirements rather than popularity ranking.