Q306: System Design Capstone Learning Platform End to End

What Interviewers Want To Evaluate

Interviewers want to know whether you can put the full system design toolkit together.

They are checking product clarification, scope control, data modeling, state ownership, API contracts, rendering, search, practice tools, progress, accessibility, performance, security, observability, deployment, and rollout.

Short Interview Answer

For a learning platform, I would start by clarifying users, learning workflows, content types, progress rules, practice needs, and device constraints. Then I would design public content routes, topic and batch navigation, question pages, search, local or synced progress, JS/TS practice consoles, PDF exports, and revision packs. The architecture would use static rendering for stable content, client islands for interactive practice and progress, server routes for safe execution and generated artifacts, strong accessibility, observable user journeys, and incremental rollout by content batch.

Detailed Interview Answer

A learning platform is not just a content site.

It includes:

reading
navigation
search
practice
revision
progress tracking
content operations
export
analytics
accessibility

A senior design keeps the student workflow central.

Clarify Users

Possible users:

new learner
returning learner
interview candidate
content author
admin reviewer
mentor

Each user has different needs.

For an interview answer, pick the P0 user.

Example:

P0: interview candidate preparing across structured frontend topics.

Scope

P0 scope:

home roadmap
volume pages
topic cards
question reader
batch revision pages
last-minute cheat sheet
JS and TS practice consoles
local progress
search

P1 scope:

cloud sync
mock interview mode
PDF generation queue
recommendations
authoring CMS
AI feedback

This keeps the design focused.

Data Model

Core entities:

Question
Volume
Topic
Batch
RevisionPack
CheatCard
PracticeSnippet
ProgressRecord
SearchIndexEntry

Content can start as MDX files.

Progress can start in local storage and later sync to a server.

State Ownership

State categories:

content metadata -> build/server
reader position -> local client
completion record -> local or synced server state
search query -> URL state
practice code -> local draft state
console output -> local transient state
filters -> URL or local state

This prevents a giant global store.

Rendering Strategy

Rendering choices:

public handbook pages -> static generation
topic and volume pages -> static generation
search page -> static shell plus client/server results
practice consoles -> client island
PDF route -> server route or generated artifact
future account dashboard -> authenticated dynamic route

The goal is fast reading and contained interactivity.

API Contracts

Potential APIs:

GET /api/search?q=&topic=
POST /api/practice/run
POST /api/progress
GET /api/progress
POST /api/pdf

Contracts should include validation, errors, rate limits, and idempotency where needed.

UX States

Important states:

content not found
search empty
practice execution error
progress save failed
offline reading
PDF generation pending
slow network
mobile navigation overflow

A learning product must avoid losing the learner's place.

Quality Concerns

Cover:

keyboard navigation
reader typography
mobile layout
code block readability
copy buttons
accessible status labels
performance budgets
MDX build validation
route generation tests

Quality is part of the design, not decoration.

Observability

Track:

chapter opened
chapter completed
practice run success
search result selected
batch page opened
cheat sheet used
PDF generated
errors by release
Core Web Vitals

Avoid logging private code snippets by default.

Interview Framing

Say:

I would optimize first for reading flow and practice loop: find a topic, read a chapter, run examples, mark progress, revise by batch, and return later.

Then add:

I would keep content mostly static, isolate interactive tools as client islands, and design progress so it can evolve from local-only to synced later.

Common Mistakes

• Designing an authoring CMS before the learner workflow.
• Making every page dynamic.
• Putting all state in one store.
• Ignoring mobile reading.
• Forgetting search and revision flows.
• Logging private practice input.
• Missing content validation in CI.

Final Mental Model

A learning platform succeeds when it protects momentum.

The system should help users:

know where to start
understand what to read next
practice immediately
track progress honestly
revise quickly
return without friction