Feed Ranking and Fan-Out Basics

In-process models for ranking, paging, and hot posts.

Expert15 min read

Read these first

Design a Social Feed

Why this matters

Scope — what "Ranking signals" covers inside Feed Ranking and Fan-Out Basics and what it does not
Scope — what "Paging" covers inside Feed Ranking and Fan-Out Basics and what it does not
Scope — what "Hot vs cold" covers inside Feed Ranking and Fan-Out Basics and what it does not
Scope — what "Trade-offs" covers inside Feed Ranking and Fan-Out Basics and what it does not
Platform problems test entity graphs and derived state (reputation, balance).

Dependency direction

Controller / FacadeHTTP or API entry

Serviceuse cases, orchestration

Domainentities, rules, invariants

Repositorypersistence port

Dependencies point inward — domain never imports infrastructure.

CampusOS context

CampusOS is the fictional smart-campus platform used across this track. Treat this module as a real product slice:

Context

Belongs to CampusOS — same naming and design vocabulary as parking, library, and booking modules
Scope is one JVM — persistence is in-memory or behind a repository interface
Goal is a class diagram + core Java that an interviewer can follow in 35–45 minutes
Extension paragraph at the end links to System Design when scale exceeds one process

Requirements snapshot

Functional requirements

Rank posts by score (time decay + engagement)
Page through feed with cursor
Separate hot cache for celebrity accounts
Hydrate post IDs to full objects on read

Non-functional requirements

Single JVM, in-process design for this LLD article
Core flows testable with in-memory repositories
Extension points for new rules without editing central god classes
Clear public API on facade/service layer
CampusOS extension links to System Design when scale demands distribution

Overview

This CampusOS module designs Feed Ranking and Fan-Out Basics as a production-ready in-process service. Read requirements point-by-point before drawing classes.

Ranking signals

Points to cover

Scope — what "Ranking signals" covers inside Feed Ranking and Fan-Out Basics and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Paging

Points to cover

Scope — what "Paging" covers inside Feed Ranking and Fan-Out Basics and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Hot vs cold

Points to cover

Scope — what "Hot vs cold" covers inside Feed Ranking and Fan-Out Basics and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Trade-offs

Points to cover

Scope — what "Trade-offs" covers inside Feed Ranking and Fan-Out Basics and what it does not
Classes — name 2–4 classes/interfaces responsible for this slice
Flow — step-by-step: trigger → validation → state change → side effect
Edge cases — invalid input, concurrent access, empty state, timeout
Pattern — Strategy, State, Observer, or Facade if it fits naturally
Test hook — one scenario an interviewer will ask you to walk through

Java

// CampusOS — SocialFeedDesign facade (keep thin)
public final class SocialFeedDesignService {
    private final SocialFeedDesignRepository repository;

    public SocialFeedDesignService(SocialFeedDesignRepository repository) {
        this.repository = repository;
    }

    /** Orchestrate: validate → domain rules → persist → return result */
    public Result handle(Request request) {
        request.validate();
        var domain = DomainModel.from(request);
        domain.applyRules();
        return repository.save(domain);
    }
}

Quick recall

Everything you need if you only revisit this box.

Ranking signals — review this slice before mock interviews.
Paging — review this slice before mock interviews.
Hot vs cold — review this slice before mock interviews.
Trade-offs — review this slice before mock interviews.

CampusOS extension

When this outgrows one JVM

Shard inventory or state by campus ID or geographic region
Push notifications, payments, and search to dedicated services (System Design track)
Use message queues for async side effects (email, analytics)
The class diagram you drew here becomes one box on the HLD architecture diagram

Test yourself

Answer these before moving on — recall is what makes it stick.