Step 2. Back-of-the-Envelope Capacity Estimation

To design for scale, let's estimate the expected workload and data volumes:

Summary

• Scale: 500 million monthly users, 10 million daily users → hundreds of thousands online at once
• Read/write ratio: 95 % reads (browsing), 5 % writes (posts, votes)
• Posts per day: ~1 million new posts → heavy write throughput
• Comments per day: ~10 million new comments → very high read/write demand
• Votes per day: ~1 billion vote actions → frequent counter updates
• Read traffic: Billions of feed and comment views daily → aggressive caching required

Details

• User Base: ~500 million monthly active users (MAU), with around 10 million daily active users (DAU) at peak. This implies many concurrent users at any given time (possibly hundreds of thousands).
• Traffic Pattern: The system is read-heavy. Approximately 95% of operations are read requests (browsing posts and comments), and 5% are writes (creating content or votes). This is typical for social media platforms where far more users consume content than create it.
• Posts: We anticipate about 1 million new posts per day being created across all subreddits. This leads to high write throughput for creating posts.
• Comments: Approximately 10 million new comments are added daily, as each post can have multiple comments. Comments are even more frequent than posts, so the comment system must handle very high write volume and also heavy reads (as users load comment threads).
• Votes (Upvotes/Downvotes): On the order of 1 billion vote actions per day (since each active user might cast multiple votes). Voting is an extremely write-intensive operation (frequent small updates to counters). This requires a highly efficient mechanism due to the sheer volume of events.
• Content Delivery: Many billions of read requests per day when counting all post feed views, comment page loads, etc. We must use caching and efficient querying to handle this scale.
• Storage needs: If an average post or comment is a few hundred bytes, the total storage for text content (posts + comments) is in the tens to low hundreds of GBs, which is manageable but should be distributed across multiple storage locations. Media (images/videos) will be stored in a separate blob storage (e.g., cloud storage such as Amazon's S3).

These estimates guide the design decisions (for example, the heavy read ratio suggests aggressive caching and replication, while the high write counts for votes suggest specialized handling). The system should also be designed to scale beyond these numbers, as a Reddit-like platform could continue to grow.

Summary

• Data Model:

  • Posts: sharded NoSQL records (post_id, subreddit_id, author_id, title, content, score, comment_count, etc.) partitioned by hash or subreddit for efficient queries
  • Comments: adjacency-list items (comment_id, post_id, parent_id, author_id, content, score) sharded by post_id to localize each thread
  • Subreddits & Users: metadata and relationships (subscriptions, moderators) in relational tables with many-to-many user–subreddit mapping; user profiles (credentials, karma) in SQL

• Voting & Score Management: handling billions of vote actions

  • Vote storage: record per-user votes to prevent duplicates, log events for audit
  • Score updates: atomic counter increments in Redis (or DynamoDB counters), async persistence via Kafka to avoid blocking, race-free aggregation
  • Karma updates: author points incremented asynchronously

• Feed Generation & Ranking: creating personalized and trending timelines

  • On-the-fly merging: pull top N posts per followed subreddit from Redis sorted sets, merge by “hot” score formula (votes + decay)
  • Caching: short-lived per-user feed caches and subreddit hot lists; global trending computed periodically and heavily cached

• User Messaging: inbox-style direct messages

  • Schema: messages table (message_id, sender_id, receiver_id, content, sent_at, is_read) partitioned by receiver for fast inbox queries
  • Workflow: POST to store and trigger notification; GET to fetch sorted messages; mark read; optional archiving of old messages

• Notification System: alerting users to events

  • Event sources: services emit Kafka events (comments, mentions, DMs, mod actions)
  • Delivery: store per-user notifications with TTL in Redis (or DB), serve via GET /notifications; optional push or email integration; track unread counts

• Search Indexing & Retrieval: full-text search over posts/comments

  • Engine: Elasticsearch cluster with inverted indexes, sharded and replicated
  • Async indexing: Post/Comment services publish “New” or “Update” events to Kafka; indexer consumes and updates ES
  • Query handling: Search service builds queries, applies filters, caches popular searches with short TTL

• Workflow Examples: end-to-end data flows

  • Create post: API → write to NoSQL → update cache → emit Kafka events → indexer, feed updater, spam detector
  • Vote: client call → atomic Redis increment → log event → feed service updates sorted sets
  • Message & notify: store message → emit event → Notification Service writes alert → client fetches or receives push

Details

In this section, we detail how each major component will work internally and how data will be organized and managed. This includes data schemas, partitioning strategies, and the implementation of different features under the hood.

Data Model for Posts, Comments, Subreddits, and Users

• Posts: Each post will be represented as a data object containing the following fields:

Given the volume, posts will be stored in a sharded NoSQL database. Partitioning can be done by post_id hash or by subreddit_id. For example, we could incorporate the subreddit identifier into the partition key, allowing posts in the same subreddit to be spread across shards while also enabling them to be queried together. Using a wide-column store like Cassandra, we might have a primary key as (subreddit_id, post_id), which allows efficient retrieval of all posts in a subreddit (since they will be clustered by subreddit). Alternatively, a service like DynamoDB could store each post item with a primary key of post_id and a secondary index on subreddit_id for querying by subreddit. Data is denormalized as needed to avoid cross-shard joins (each post entry might also store the subreddit name or author username for convenience, or these can be fetched from the User/Subreddit service).

• Comments: Stores comments on posts, supporting arbitrary nesting (comment threads). We use an adjacency list model: each comment stores a pointer to its parent comment. All comments belong to a post. For scalability, comments can be sharded by post_id (ensuring all comments of a post reside on one shard, which makes retrieving a post’s entire comment tree localized). Like posts, comments are also indexed in Elasticsearch for text search.

The Comment Service can retrieve all comments for a given post_id efficiently by querying the comments table on the post_id partition. For nesting, we can either use recursive queries or fetch all comments for a post and then construct the tree in memory. Comments can also be sharded by post_id or by comment_id. A likely choice is to partition by post_id so that all comments for a post reside in the same partition or set of partitions (ensuring one post’s comment thread can be fetched with minimal scatter). Since one post could have thousands of comments, those partitions still need to handle high read volume. We can cache the top-level comments separately to reduce load.

• Subreddits: Subreddit data (community info) is much smaller in scale (tens of thousands to maybe millions of subreddits, versus hundreds of millions of posts). We can store subreddit metadata in a relational database. Each subreddit record contains subreddit_id, name (unique), description, creation_date, and lists of moderators or rules. The number of subreddits is not huge, so even a single SQL table could hold them. The Subreddit Service provides APIs to create a subreddit (which inserts a new row) and to query information about a subreddit. We also need to manage user subscriptions to subreddits: this is a many-to-many relationship between users and subreddits. This could be stored as a separate table (user_id, subreddit_id) pairs.
• User Data: Each user has a profile with username, hashed password (if using our own auth), email, join date, karma points, etc. This goes into the User Service’s relational database. It’s essential that this is consistent and secure. We’ll have unique constraints on username and email. The user’s subscriptions to subreddits, as mentioned, might be stored with the Subreddit Service, but could also be partially cached with the User Service for quick lookup.
• Data Size and Partitioning: By partitioning posts and comments across many nodes, we ensure no single machine handles all write traffic. Consistent hashing can be used to allocate new partitions as the data grows. We might have, say, 100 Cassandra nodes, each holding a portion of the data. Replication factor (e.g., 3) in Cassandra ensures that each piece of data is stored on 3 nodes for fault tolerance. For DynamoDB, throughput capacity is managed by AWS and can scale transparently, but we still design keys to avoid “hot partitions.” Using the subreddit ID as part of the key helps distribute popular subreddits across multiple partitions if needed.

Voting and Score Management

Voting is a critical feature that directly influences content ranking. However, handling billions of votes efficiently is challenging. Key design points for the Vote Service and data handling include:

• Storing Votes: We need to record each user’s vote on each item to prevent multiple voting and to allow un-voting. This can be a record in a database table or NoSQL store keyed by (user_id, post_id) storing the value (+1, -1, or 0 if no vote). However, storing every single vote in a centralized store might be too much load given 1B votes/day. A pragmatic approach is to maintain an eventually consistent log of votes and focus on keeping the vote counts up to date in real-time.
• Vote Counts: The primary thing we need immediately is to update the score (net votes) of the post or comment. We will use a high-throughput key-value store or in-memory counter for vote totals. For example, when a user upvotes a post, the Vote Service can increment that post’s score in Redis. Redis can handle millions of ops/sec and can increment a counter atomically. This updated score can be cached and also eventually persisted to the main post database (or a separate aggregation store). Alternatively, if using DynamoDB, we could use its atomic counters feature to update a numeric attribute. The key is to decouple the frequent small updates from the heavy data store.
• Asynchronous Processing: To avoid making the user wait on heavy updates, voting actions are handled asynchronously. When a vote is received, the Vote Service quickly logs the action (e.g., writes to a commit log or sends to Kafka) and returns success to the user. A background worker (or the same service in another thread) then updates the necessary counts. By queuing the vote events, we buffer them and process them in batches if needed (e.g., aggregate multiple votes to the same post within a short window). This improves throughput and user-perceived latency.
• Preventing Race Conditions: With multiple votes coming in, especially in a distributed system, there is a risk of race conditions updating a score. To handle this, the vote update could be done by a single consumer or through the use of atomic operations. If using Redis, the increment is atomic. If using a log + batch update, then the final aggregation can happen with locking or eventually correcting itself (since if two updates race, the order doesn’t matter for addition).
• Storing Karma: User karma (points accumulated from upvotes on their content) is another thing that needs to be updated when votes happen. This can be handled similarly by incrementing the author’s score count in a User Stats store asynchronously. It’s not as time-sensitive.
• Downvotes: A downvote might decrement the score. The logic is similar. We must ensure a user’s vote change (from upvote to downvote, etc.) adjusts counts correctly (possibly by reading the old vote value, which is why storing user vote history is useful). This read-modify-write can still be done in the Vote Service’s memory or a fast DB.
• Ranking implications: The Vote Service might notify the Post Service (via events) that a particular post’s score changed significantly. The Post Service can then recalculate that post’s ranking in its subreddit or globally. More on ranking below.

Feed Generation and Ranking

One of the core features is the personalized feed for each user. This feed should display a mix of content that the user is likely to be interested in – primarily posts from communities they follow (their subscriptions), possibly combined with “recommended” posts (e.g., popular posts from similar communities or globally trending content). The feed should also adapt to user preferences (if they often upvote certain topics, show more of that). Achieving this requires a combination of ranking algorithms and possibly machine learning.

Key aspects of feed design:

• Ranking Algorithm: Reddit traditionally uses a score that combines votes and time (a decay function) to rank posts (“hot” formula). We can adopt a similar approach: each post has a score that decays over time, allowing newer content to rise. For each community, we can maintain a list of “hot” posts. A user’s home feed could be built by pulling the top posts from each subreddit they follow and then merging them by score. We might also include a few high-ranking posts from outside their subscriptions as recommendations.
• Feed Assembly (Fan-out on read): Given a user U who follows subreddits [A, B, C], when U requests their feed, our Feed Service can do:
  1. Query a cache or service for the top N posts in A, top N in B, top N in C (where N might be, say, 10 from each to have a pool).
  2. Merge these posts and sort by the ranking formula to pick the overall top posts across them.
  3. Possibly inject other content (if A, B, and C have few updates or we want diversity).
  4. Return the merged list (with some pagination support if the user scrolls further).
  The advantage of this on-the-fly merging (“fan-out on read”) is that we don’t have to pre-store a feed for every user, which would be huge. We leverage the fact that each subreddit’s hot list is cached. Popular communities will have their hot posts cached or even precomputed. For less active communities, querying their latest posts is cheap. The merging is done quickly in memory. This approach works well if each user follows a limited number of communities, which is usually the case (e.g., if a user follows 50 subreddits, pulling 50 × 10 = 500 posts to consider is manageable).
• Feed Precomputation (Fan-out on write): Another approach some systems use is to push new posts to followers’ feeds as they happen (like how Twitter might push tweets to followers’ timeline stores). At Reddit scale, this is challenging because one community might have millions of subscribers (fan-out a single post to millions of feeds is heavy). Also, users can fetch on demand. So, likely we stick to generating on read with caching of intermediate results.
• Caching Feeds: We can cache the final assembled feed for a short period (e.g., 1 minute) for each user to avoid repeated heavy merging when they refresh frequently. However, feeds become stale quickly as new posts and votes come in. We might use short-lived caching or ETag to prevent resending unchanged feed items.
• Trending Posts: For the “Trending” or “Popular” tab (site-wide trending), we can maintain a global list of top posts in the last X hours. This can be recomputed periodically (e.g., every few minutes) by aggregating posts with the highest recent upvote rates. A background job can scan recent posts or consume vote events to update a sorted list of trending posts. This global trending list can be cached heavily and served to any user (especially new or logged-out users) efficiently.
• Feed Service Implementation: The Feed service will coordinate the above. It may use both online data (current cached posts from subs) and offline data (precomputed recommendation lists). Efficiency is key: we don’t want to query thousands of posts. That’s why caching top posts per subreddit is useful. We could maintain a Redis sorted set for each subreddit’s posts, keyed by a “hotness” score. As new posts come or votes change, update the sorted set accordingly. Then the feed query for a subreddit is just a sorted set range query (fast). If that’s too granular, at least maintain for large subreddits. For smaller ones, we can query the database for recent posts.
• Updating Feeds: When a user creates a new post, how do followers see it? If we are doing fan-out on read, then the next time any follower loads their feed, that new post will appear because it’s now among the top for that subreddit. If we wanted a real-time feed update (like pushing new posts to online users), we could integrate a push over WebSocket to insert the latest post into their feed view. But since real-time updates aren’t explicitly required, we can stick to pull-based refresh.

User Messaging Design

For user messaging (DMs), the system functions like a simple mail inbox. Real-time delivery (as in chat) is not required, which simplifies things: we do not need persistent WebSocket connections or instantaneous typing indicators. Instead, we focus on reliable storage and retrieval of messages and notifications when new messages arrive.

Messages Table: Stores private direct messages between users. This table is smaller and can be replicated fully or sharded by receiver_id.

Workflow for messaging

• Sending a Message: When user A sends a message to user B:

  1. The client (A’s browser/app) calls the Messaging Service API (e.g., POST /messages) with the recipient B and content.
  2. The Messaging Service authenticates A, checks whether B exists, and ensures that A is not blocked by B (for some abuse prevention).
  3. The service creates a new message record in the database. This could be inserted into a table partitioned by B (the recipient) so that B’s inbox has this message. If using Cassandra: partition key = B’s user_id, cluster by timestamp (so B’s messages are sorted by time). The message ID can be a UUID or time-based ID to ensure uniqueness. The message status is initially set to “unread.”
  4. The service could also simultaneously insert a copy or pointer in A’s “sent messages” if we want that feature (or we can derive the sent folder by querying messages where sender = A).
  5. After writing to storage, the service sends a notification: it will send an event to the Notification Service (or directly create a notification for B: “You have a new message from A”). If B is online, we might push a notification event. If not, it will be available when B checks.
  6. The service returns success to A’s client. A sees the message in their outbox as sent.

• Receiving a Message: When user B wants to read messages (say B opens their inbox):

  1. The client calls GET /messages (or a websocket could push, but let's assume it pulls).
  2. The Messaging Service fetches messages for B from the datastore. Since we partitioned by user, this is efficient – retrieve the list sorted by time. We might implement pagination if B has many messages (e.g., fetch last N).
  3. The service returns the list. The client displays them. The client might periodically poll for new messages or rely on notification prompts.
  4. When B reads a message, the client might call an API to mark it read. The service updates the message record (setting is_read=true or moving it from an unread set to read).
  5. The Notification for that message could be marked as read as well, so B’s notification count goes down.

• Data storage and consistency: Since losing messages is unacceptable, we will replicate this data. If using Cassandra, the replication factor ensures durability (multiple nodes have the data). If using SQL, we’d have a primary-replica setup, and the message write goes to the primary. We’ll also back up messages regularly. The data model is straightforward, and since writes are not super high (messaging is likely a fraction of overall site usage), consistency can be strong here (write and read your message immediately).

• Scale considerations: If even 10% of 100M users send one message a day, that’s 10 million messages/day, which is significant. However, each message is typically only a few hundred bytes of text. Over the course of a year, ~3.6 billion messages are sent, which is a significant amount. However, partitioning by user means that no single query touches billions; only those relevant to a single user are affected. We will need to ensure the partitioning is even – some users (such as mods or very active users) might receive thousands of messages, but that’s still acceptable. We might also consider auto-archiving old messages (e.g., those older than X years) to secondary storage, which would help keep the active dataset smaller.

In short, the Messaging component is like a mini email system: it stores messages reliably, allows retrieval by the user, and ties into notifications for new message alerts. It’s simpler than real-time chat and can be built on top of existing database tech with partitioning.

Notification System

The Notification system ensures users are kept aware of relevant events (without having to constantly check everything). Design considerations for notifications:

• Types of notifications: replies to your comment/post, mentions (@username in a post), new messages, someone followed you, moderator invites or actions, etc. Each type might have slightly different data (e.g., a reply notification needs to identify the comment and maybe include a snippet of text).

• Event Sources: Various services will generate events:

  • Comment Service generates “User X replied to your comment Y in post Z”.
  • Post/Comment Service for mentions “User X mentioned you in post Z”.
  • Messaging Service for “New message from X”.
  • Moderation service for “Your post was removed by mods,” or “You earned a badge,” etc.
  • We could also have periodic notifications, such as “Trending in a subreddit you follow,” which would come from a trending service or a cron job.

• Delivery mechanism: We can handle notifications via:

  • Push to device/browser: e.g., using Web Push API or mobile push notifications for instant alert. This requires capturing device tokens and integrating with APNs or FCM (mobile push services). It’s an extension beyond core web functionality, but likely desired for a modern service.
  • In-App Notification Center: The website/app will feature a notifications inbox (similar to the bell icon on Reddit). The client will fetch notifications from the server (e.g., GET /notifications) periodically or when the user opens the panel.
  • Email: Optionally, send email notifications for specific events (if the user has opted in, such as a summary email or an immediate notification for direct messages).

  For our design, we focus on storing and retrieving notifications in-app; however, it’s worth noting that push/email could be integrated by having the Notification Service call external email/SMS gateways.

• Storage: Notifications can be stored per user, ideally in a fast store like Redis for quick access. For durability, we could also log them to a database or at least replicate the Redis (Redis can have AOF persistence, or we can mirror writes to a backup DB). Each notification is small (a type, an id pointer, a short message).

• Workflow: Using an example: User A commented on User B’s post.

  1. Comment Service processes A’s comment on B’s post. It sees that the post’s author B should be notified of a new comment.
  2. It publishes an event CommentAdded {post_id, commenter=A, post_author=B, comment_id} to Kafka.
  3. The Notification Service consumes this event. It creates a notification in storage: key = B’s user_id, value = “User A commented on your post X” with a link to that comment. It sets it as unread.
  4. If B is currently online, the Notification service could send a real-time update. For example, if B has a WebSocket open, send a message over it to increment their notification count. If not, rely on the next fetch.
  5. When B opens the app, they call GET /notifications. The service fetches B’s notifications (say the last 20) from the sorted set (sorted by time) and returns them. The unread ones are marked or counted.
  6. B sees the notification, clicks it (which leads them to the comment). Optionally, the client or server marks that notification as read (so it can be excluded from the unread count or moved out of the “new” list).

• Scalability: Notifications can be frequent, but each user’s list is manageable. The write volume of notifications equals the number of events to notify. Potentially, with 100M DAU, if each user triggers even 0.1 notifications on average (like 10M notifications per day), that’s still acceptable, as it’s similar to the message volume. The key is that these writes are short, and we can batch them if needed.

• Clearing Old Notifications: We don’t want to store every notification forever, or the lists will become long. We can auto-expire notifications older than, say, 30 days. Using Redis with an expiration TTL on each notification entry, or periodically trimming the list per user, can achieve this.

• Handling read state: We could keep an unread_count for each user (increment on new notification, decrement on read). This can live in an in-memory store or be computed from the list. Usually easier to maintain a counter field in a small DB or cache.

• Design choice: We might implement Notification Service as part of or alongside the Messaging/Feed services, but conceptually it's distinct. It heavily relies on events from other parts of the system (so it’s a good use of the publish-subscribe pattern via a message queue).

Overall, notifications enhance user engagement by alerting users to relevant interactions. The system uses an event-driven approach to capture events and deliver notifications asynchronously. High availability is important (we don’t want to lose notifications), so the process should be reliable (using durable queues and redundant storage).

Search Indexing and Retrieval

Search is a critical feature given the huge volume of content. Users should be able to search for posts (and possibly comments) by keywords, with options to filter by community, date, or author. Implementing this at scale requires a specialized search engine.

• Search Engine (Elasticsearch/Solr): We will set up an Elasticsearch cluster to handle indexing and querying. Each post (and possibly each comment) will be indexed as a document. The index will include fields such as title, body, author, subreddit, and creation time, among others. We’ll use inverted indexes for keywords, which allow efficient full-text search over millions of documents by keywords. The search service supports advanced queries, including phrases, boolean conditions, filtering by subreddit or author, and sorting by relevance or date. Elasticsearch can handle this with proper mapping and queries.

• Index Updates: Whenever new content is created or updated (such as a post or comment), it must be added to the search index. This will be done asynchronously:

  • The Post Service, after writing a new post to the database, will publish an event (e.g. to Kafka: “NewPost {id:123, subreddit:X, ...}”). A Search Indexer service (a consumer) will pick up this event and then index the document in Elastic. The indexer will extract the text fields and call the Elasticsearch API to add a document. Similar for comments (though we might decide to index comments only for certain search types, or separately).
  • If a post is edited or deleted, corresponding events trigger update or deletion in the index. (Deleting is important so that we don't show removed content in results.)
  • There will be some lag (a few seconds) between a post creation and it being searchable – this is acceptable for eventual consistency in search.

• Index Size and Sharding: The search index can encompass billions of documents (including all posts and comments). We will need to shard the index across many nodes. Elasticsearch can automatically shard indices (e.g., up to 50 shards or more, each hosted on different servers). Queries are distributed to all shards, and the results are merged. To keep indices manageable, we might partition by time or by subreddit. For example, have an index per year, or per major category, to limit any single index’s size. Alternatively, maintain a single, large index with multiple shards. We’ll also keep replicas of each shard for fault tolerance (if one node fails, the replica serves).

• Query Processing: When a user searches (i.e., they input a keyword and optional filters), the request is sent to the Search Service. This service will:

  • Parse the query and construct an Elasticsearch query (including full-text search on the keywords and filters for subreddit, etc.).
  • Send the query to the Elastic cluster, which executes it across shards. Elastic will return a ranked list of matching documents (posts) along with their scores. We can post-process if needed (e.g., filter out any deleted content that might still be indexed, or apply permissions if some communities are private).
  • The service then formats the results (possibly fetching additional information, such as snippets or highlights, and the post metadata). It might call the Post service or cache to get the current vote count or comment count for display alongside each result.
  • Results are returned to the client, possibly paginated if many results.

• Caching search queries: Popular search queries (such as “cute cats” on Reddit) are often repeated. We could cache the results of common queries for a short time. However, since search results are updated with new content, the cache TTL may be set to a low value (minutes). Still, if thousands of users search the same trending term, caching can reduce the load on Elastic. We can use an LRU cache keyed by query+filters in the Search service for this.

• Search Throughput: Search queries can be expensive (scanning lots of index). The search cluster needs to be scaled according to query volume. If, say, 5% of users perform searches during peak times, that could result in thousands of queries per second. We’ll ensure the Elastic cluster has enough nodes and may implement query rate limiting to prevent abuse (e.g., someone sending 100 queries per second could degrade performance). Heavy search usage might also require horizontal scaling by adding more shards or splitting indices by topic.

In summary, the Search subsystem is built around an engine similar to ElasticSearch with asynchronous indexing.

Putting it Together: Workflow Examples

To illustrate end-to-end how data flows through the designed components, consider a couple of scenarios:

• User creates a post:

  1. User hits “submit” on a new post in subreddit X. The request goes to Post Service.
  2. Post Service validates (user auth, subreddit exists, user not banned in X, content length, etc.). It writes the post to the Posts DB (Cassandra). It sets the initial score=1 (the user's upvote).
  3. In parallel, it writes to a cache (maybe update subreddit X’s “new posts” list in Redis).
  4. It enqueues events: “NewPost” event to Kafka with post details.
     • A Search indexer gets this event and indexes the post for search.
     • A Feed updater gets it – it updates the sorted set for subreddit X hot posts (initial score) and possibly checks if this post is trending enough to notify some users. At least, it’s now in the pool for future feed fetches.
     • A Notification event might be generated if some users requested notifications for new posts in a subreddit (not common, but could be a feature like “alert me of new posts in my own community” for mods).
     • A Spam detection service gets the event and checks the content. If flagged, it may immediately mark the post as removed (update the DB status and possibly send it to the mod queue).
  5. The user gets a success response. Other users will see this post when they next load the subreddit or their home feed (if they subscribe to X and the post ranks).
  6. If a mod removes the post shortly after (via mod tools), a Mod action event could trigger search index removal and feed removal.

• User votes on a post:

  1. User clicks upvote. The client calls the Vote Service with the post ID and vote action.
  2. The service checks if this user has already voted. It may be retrieved from a Redis cache of users’ votes or a Vote DB. If no vote or a change in vote, it is accepted.
  3. It increments the post’s score (maybe in a counter service or DB). Possibly the vote count update is done in-memory and queued (to not lock the DB for each vote). But assume a simple approach: update the Post record’s score or a separate score table.
  4. It records the user’s vote (in a user->post vote table or cache) to prevent re-voting.
  5. In the background, it emits an event “Vote {post, newScore}”. The Feed service listening can then update that post’s ranking in the subreddit’s sorted set (maybe bump it up). If the post gains a lot of votes quickly, the Trending logic might catch it and include it in the global trending list.
  6. The user sees the vote reflected immediately (we optimistically updated the client, or the API returns a new score).
  7. If the vote triggers any threshold (maybe an upvote causes the post to hit the front page), nothing special in the system, except it appears in more feeds due to rank.

• User receives a message:

  1. Another user sends them a direct message, which is routed through the Messaging Service and stored.
  2. The Notification Service gets an event, stores a notification for a new message.
  3. If the user is online, perhaps a WebSocket server (if we have one for notifications) sends a “ding”. If not, an email may be sent after a few minutes if they don’t see it.
  4. When the user clicks their inbox, the Messages are fetched from storage and marked read.

Each of these flows involves multiple components but is designed in such a way that heavy lifting (like updating many indices or sending many notifications) is done asynchronously and does not block the user’s action.