End-to-End Interview Flow Cheat Sheet #

Status: Archive candidate. Keep as historical reference; prefer system-design-core-index.md and the core notes for day-to-day use.

This overlaps with the reduced core stack and newer interview-structure notes.

Use this as the delivery framework in an interview.

Under the hood, you can still think in archetypes, write shapes, and mechanisms. But present the design in a clean linear order.

The delivery order #

1. functional requirements
2. NFRs
3. core entities
4. APIs
5. high-level design
6. deep dives
7. tradeoffs and evolution

This is the most interview-friendly order.

The hidden internal reasoning #

Behind the scenes, derive each section like this:

• functional requirements -> path extraction
• NFRs -> path-specific consistency, latency, availability, durability, freshness
• entities -> primary state objects
• APIs -> path -> endpoint mapping
• HLD -> write shape -> base mechanism -> concrete realization
• deep dives -> failure defaults + scale hotspots by archetype

So the external story is linear, but the internal model is still rigorous.

Step 1: Functional Requirements #

Start with user-visible capabilities.

Good phrasing:

• users can create posts
• users can follow creators
• users can view a home feed
• users can search hashtags

What you are really doing:

• extracting critical paths
• separating writes from reads
• spotting hidden system paths

What to say out loud:

I’ll start by listing the core user-facing paths and the supporting system paths that affect correctness.

Do not over-list. Usually 4-8 core paths is enough.

Step 2: NFRs #

Specify NFRs per important path, not globally.

Use:

• consistency
• latency
• availability
• durability
• freshness

Examples:

• create post
  • strong source truth
  • interactive latency
  • committed post must not be lost
• home feed
  • eventual consistency acceptable
  • high availability
  • bounded freshness lag
• hold seat
  • strong consistency
  • fail closed over double allocation
  • durable hold

What to say out loud:

Different paths have different correctness needs, so I’ll separate commit paths from projection reads.

Step 3: Core Entities #

List the primary state objects first.

Typical types:

• current-value entity
• relation
• append child object
• workflow state
• resource/inventory state
• projection view

Examples:

• Post
• FollowRelation
• Comment
• FeedView

Or:

• SeatInventory
• SeatHold
• Booking

Good rule:

• source truth first
• derived views second

What to say out loud:

I want to separate canonical truth from derived views, because that drives both correctness and failure handling.

Step 4: APIs #

Now make the paths concrete.

Derive APIs from:

• path
• entity
• write shape

Examples:

• POST /posts
• PUT /follows/:user_id
• DELETE /follows/:user_id
• GET /feed/home
• GET /search?tag=...

Mention only the important semantics:

• idempotency for dangerous creates/commits
• pagination for lists
• version checks for guarded overwrites/transitions
• projection freshness where relevant

What to say out loud:

I’m not aiming for perfect REST here; I just want endpoint shapes that make the critical paths concrete.

Step 5: High-Level Design #

This is where the system becomes architecture.

Start from:

• source of truth store
• async pipeline / workers if needed
• projection stores
• caches
• external integrations

Structure:

1. request hits API/service layer
2. source truth is updated
3. event/outbox/queue drives secondary updates
4. projections and caches serve read-heavy paths

Good HLD sentence:

Writes go to the canonical store first, then an async pipeline updates search, feed, counters, and other derived views.

How to think internally #

Use:

• write shape
• base mechanism
• concrete realization

Example:

• follow user
  • write shape: guarded state transition
  • mechanism: guarded add/remove
  • realization: relation table with unique edge key + async counter/feed updates

Step 6: Deep Dives #

Only deep dive into the parts where the design is actually hard.

Usually one or two of:

• correctness / consistency
• failure handling
• scale hotspots
• sharding / partitioning
• ranking / search freshness
• claim/lease logic
• inventory protection

Failure deep dive #

Use the simpler structure:

• what if commit happened but caller didn’t know?
• what if two actors did it at once?
• what if source changed but side effects didn’t?
• what if someone acts on old state?
• what truth do I trust to repair?

Scale deep dive #

Use:

• what gets hot?
• why does it get hot?
• first mitigation?

What to say out loud:

The interesting parts here are protecting correctness on the commit path and avoiding hotspots on the read-heavy surfaces.

Step 7: Tradeoffs and Evolution #

Close by showing judgment.

Examples:

• start with exact counts, move to async derived counters later
• start with one region, add multi-region read replicas later
• start with simpler feed generation, move to hybrid fanout for celebrity skew
• start with strong source truth plus eventual projections

What to say out loud:

I’d start with the simpler exact design on the core truth path, then add projection and scaling optimizations as the hotspot becomes real.

One-page speaking template #

Use this verbally:

1. Requirements #

The main paths are A, B, C, and D.

2. NFRs #

The commit paths need strong correctness and durability, while search/feed/trending can be eventually consistent with bounded lag.

3. Entities #

The core entities are X, Y, and Z. X and Y are source truth; Z is a derived projection.

4. APIs #

I’d expose these as POST /..., PATCH /..., GET /..., and dedicated projection endpoints like GET /feed or GET /search.

5. HLD #

Writes land in the canonical store first, then an async pipeline updates counters, search, feed, or ranking views.

6. Deep dive #

The hardest part is correctness on the hold/purchase path and hotspot management for celebrity fanout.

7. Tradeoffs #

I’m intentionally keeping source truth exact and letting projections lag a bit to keep the design practical.

Fast mapping table #

Example compressed flow #

Example: Instagram #

Requirements:

• create post
• like/comment
• view home feed
• search hashtags

NFRs:

• create/like/comment are durable source writes
• feed and hashtag search are eventually consistent

Entities:

• Post
• PostLikeRelation
• Comment
• FeedView
• HashtagSearchView

APIs:

• POST /posts
• PUT /posts/:id/like
• POST /posts/:id/comments
• GET /feed/home
• GET /search/hashtags?...

HLD:

• source writes in primary store
• async fanout and indexing pipeline
• feed/search served from projections

Deep dives:

• celebrity fanout hotspot
• duplicate like retry and counter lag

Tradeoff:

• exact source truth, eventual projections

What not to do #

• do not jump straight to Kafka/Redis/Elastic before naming the paths
• do not state one global consistency model for the whole system
• do not skip APIs if the interviewer prefers product-style delivery
• do not over-index on archetype jargon in the spoken answer
• do not deep dive before establishing the main system shape

Interview one-liner #

I use a simple delivery order: requirements, NFRs, entities, APIs, HLD, and deep dives. Internally I map each path to a state shape, write mechanism, and projection strategy so the design stays rigorous even though the presentation stays user-friendly.