In this chapter, we will explore the low-level design of stack overflow like system in detail.

Let's start by clarifying the requirements:

Before starting the design, it is important to ask thoughtful questions to uncover hidden assumptions and better define the scope of the system.

Here is an example of how a discussion between the candidate and the interviewer might unfold:

After gathering the details, we can summarize the key system requirements.

Core entities are the fundamental building blocks of our system. We identify them by analyzing the functional requirements and highlighting the key nouns and responsibilities that naturally map to object-oriented abstractions such as classes, enums, or interfaces.

Let’s walk through the functional requirements and extract the relevant entities:

1. Users can post questions, answers, and comments.

This clearly suggests the need for a User entity to represent participants of the system, along with Question, Answer, and Comment entities. Each of these entities will hold content, metadata (like creation time), and relationships (such as author and parent post).

2. Comments can be added to both questions and answers.

This implies that Comment should be a standalone entity with a reference to its parent post (which could be a Question or an Answer). Since we’re only supporting flat comments, we don’t need to model nested replies.

3. Users can upvote or downvote questions and answers, and voting affects reputation.

We need a Vote entity to track who voted on what and in what direction (up or down). The User entity should maintain a Reputation field that is updated based on voting outcomes and accepted answers.

4. A question can have multiple tags and one accepted answer.

We need a Tag entity, and the Question entity should maintain a list of tags and a reference to the accepted Answer.

5. The system should support search and filtering.

To support searching by keyword and filtering by tag, Question should expose fields like title, body, and tags in a searchable format. While we may use indexing or search service integrations in real implementation, at the design level this implies the need for search-related APIs and utility methods.

These core entities define the key abstractions of the stack overflow system and will guide the structure of our low-level design and class diagrams.

This section outlines the classes that form the core of the Stack Overflow system, their responsibilities, the relationships between them, and the key design patterns employed.

The system is broken down into several types of classes, each with a distinct role.

Enums

Simple enumerations that define a fixed set of constants.

Data Classes

These classes primarily act as data containers with minimal logic.

User

Represents a platform user with a unique ID, name, and a thread-safe reputation score.

Tag

A simple class representing a topic tag (e.g., "java") that can be associated with questions.

Event

A data-transfer object used in the Observer pattern. It encapsulates the details of an action, including its EventType, the actor (user) who performed it, and the targetPost.

Core Classes

These classes contain the main business logic and structure of the application.

Content (Abstract)

The base class for all user-generated content.

It holds common attributes like an id, body, author, and creationTime.

StackOverflowService

Acts as the central Facade for the entire system.

It provides a simple, unified API for clients to perform all major actions (e.g., creating users, posting questions, voting, searching) and orchestrates the interactions between the other components.

The design leverages several standard design patterns to create a modular, flexible, and maintainable system.

Observer Pattern

This pattern is used to decouple actions from their consequences, such as updating reputation after a vote.

Strategy Pattern

This pattern is used to define a family of algorithms (search strategies), encapsulate each one, and make them interchangeable.

Facade Pattern

The StackOverflowService class acts as a Facade.

Before reading the full implementation, try building this yourself. Below are template stubs for the classes from the design. The enums, data classes, and the demo are already written for you. The job is to fill in the core logic where the TODO comments appear.

Your task: Implement every TODO using the design from the previous sections. When you are done, run the demo. A correct implementation produces the expected output.

Now we translate the design into working code. We build bottom-up: the enums and core entities first, then the abstract Content base and its Post hierarchy, then the observer and reputation pieces, the search strategies, and finally the service that ties everything together. This order matters because each layer depends on the ones below it. Pick your language below to see a full walkthrough.

A busy question-and-answer site serves many requests at once. Each request runs on its own thread, but they share the same in-memory Question, Answer, and User objects. When two threads touch the same post or reputation counter at the same time, the single-threaded reasoning behind the vote and accept logic breaks down.

The shared mutable state is small and specific: voteCount and the voters map on each Post, reputation on each User, and acceptedAnswer on each Question. The design already guards it: vote() and acceptAnswer() run under a lock, and each user's reputation is an atomic counter. The races below explain why those guards are needed.

Concern 1: Two Users Voting on the Same Post at Once (High Risk)

Two users upvote the same answer at the same instant. Both calls run vote() on the same Post, and both read voteCount, add to it, and write it back.

Setup

An answer has a voteCount of 10. User A and User B are both new voters and upvote at the same instant. Each call adds 1, so the correct final count is 12.

Without a lock on vote()

Result

Two upvotes happened, but voteCount ends at 11 instead of 12. One vote is lost, and the count no longer matches the two entries recorded in voters.

With a lock

A lock on the post makes the read, the update, the write, and the notification run as one unit. Thread A takes the lock and finishes the sequence; Thread B then takes the lock, reads the current count of 11, and writes 12. Both votes count, and voteCount stays consistent with voters.

The lock belongs on the Post, which owns its count and voter set. A thread-safe map for voters alone would not help, because the race is not in any single map operation. It is in the gap between reading the count and writing it back, and only the lock closes that gap.

Concern 2: Reputation Drifting Under Concurrent Votes (Medium Risk)

Every vote fires an event, and the ReputationManager updates the post author's reputation. When many users vote on the same answer at once, that author's reputation is updated from many threads at the same time.

Setup

Five users upvote the same answer at the same instant. Each fires UPVOTE_ANSWER, which adds 10 to the author's reputation, so it should rise by 50.

Without an atomic reputation field

If reputation were a plain integer updated as reputation = reputation + change, the five threads interleave their read-modify-write steps.

Result

The author earned 50 reputation, but the stored value rises by far less because the updates overwrite each other, leaving the score silently too low. That is a correctness bug, not a display glitch.

With an atomic counter

Storing reputation as an atomic counter makes each increment one indivisible operation. The five +10 updates apply one on top of another, so the author ends at 250. No lock is needed, because the atomic counter serializes the increments itself.

The post lock guards the compound vote operation; the atomic counter guards the single reputation increment it triggers. Each piece of shared state is protected where it is mutated.

Concern 3: Accepting an Answer While It Is Being Voted On (Medium Risk)

Accepting an answer is several steps: check that no answer is accepted yet, set acceptedAnswer, flip the answer's isAccepted flag, and fire an ACCEPT_ANSWER event that grants reputation. The problem appears when two of these sequences run on the same question at once.

Setup

The accept request for Answer X is submitted twice at the same instant, for example from a double-click or a retried request. Both calls run acceptAnswer() on the same Question.

Without a lock

The check-then-set on acceptedAnswer interleaves: both calls read it as empty and pass the check before either writes. Both then set it and fire ACCEPT_ANSWER, granting the accepted-answer reputation twice.

Result

The answer author receives the accepted-answer bonus twice for a single acceptance, leaving the reputation too high.

With a lock

A lock on the Question makes the check and the write one unit. The first accept wins and fires one event; the second takes the lock afterward, finds acceptedAnswer already set, and returns without firing again. A concurrent upvote on the answer is unaffected, because vote() locks the answer, not the question, so an accept and a vote can run in parallel.

Across all three concerns, the lock belongs at the level of the data being mutated. The post owns its vote count, so vote() locks the post. Each user owns its reputation, so the counter is atomic. The question owns its accepted-answer reference, so acceptAnswer() locks the question. Because each lock guards a different object, an accept on a question and an upvote on its answer run at the same time without blocking.

Observer notification runs inside these locks. The ReputationManager only does a fast atomic update, so holding the lock during notification is fine. An observer that did slow work, such as sending an email or writing to a database, should run off the locked path so it does not serialize every vote behind a slow listener.

Because the Observer and Strategy patterns each isolate one concern, new requirements attach to the existing seams. A new consequence of an action becomes an observer; a new way to query questions becomes a strategy. Each extension below adds classes or fields without changing Post, Question, or the existing observers and strategies.

Scenario: "Award badges when a user crosses milestones, such as a first accepted answer or ten upvotes on a single answer."

A badge is another consequence of activity, which is what the Observer pattern already handles. A new BadgeManager implements PostObserver and is added to posts alongside the ReputationManager. It reads the same events and grants a badge when a threshold is met. No existing observer changes, and vote() keeps firing the same events.

Registering it takes one line at setup: post.addObserver(badgeManager) next to the existing post.addObserver(reputationManager). Both observers receive every event and react independently, and the code that fires the events stays unchanged.

Scenario: "The keyword search scans every question body on each query, which gets slow as the question count grows. Speed it up with an index."

Search is already a SearchStrategy, so a faster version is just another implementation of filter(). An IndexedSearchStrategy builds an inverted index from each term to the questions that contain it, then answers a keyword query from the index instead of scanning every body. The rest of the system calls filter() exactly as before.

The index is built once and reused, so each keyword lookup is a single map access instead of a full scan. Since it implements the same SearchStrategy interface as the other strategies, swapping it in is a one-line change at the call site, and the service code stays the same.

Scenario: "Posts can be edited. Keep every previous version so users can see the edit history and revert if needed."

Content currently stores a single body. Versioning records each edit as a PostRevision snapshot instead of overwriting it. A Post keeps a list of revisions; an edit appends a new one, and the latest revision is the current body. This adds one class and a method, and voting, accepting, and reputation are untouched, since none of them read the history.

Reverting pushes an older revision's body as a new revision, so the full history stays intact instead of being deleted. An edit takes the same lock as voting, so an edit and a concurrent vote on the same post do not interfere.

Each extension plugs into an existing seam: a new observer for badges, a new strategy for indexed search, or a new field and method on Post for revisions. None of them require editing the classes already written, which is the benefit of keeping each consequence and each query behind its own interface.