How to Study This Academy¶
Pick a route on Learning paths (Senior Backend, Staff Distributed Systems, Platform, Data/Streaming, Interview Sprint, Production Debugging). Do not skip the four canonical modules named there.
Prerequisite check
This academy assumes you already ship production code, know core data structures & algorithms, and are comfortable with OOP/API design/HTTP/SQL. It teaches distributed systems, scale, and failure reasoning on top of that — it does not teach the fundamentals themselves. See Who This Is For before you start if you're unsure this is the right level.
The Three-Level Model¶
Every concept has three levels of understanding. Switch between them based on context:
| Level | When to use | Focus |
|---|---|---|
| Level 1 — Intuition | Explaining to a non-expert | Simple language, analogies, diagrams |
| Level 2 — Engineering | Technical design discussion | Algorithms, architecture, bottlenecks |
| Level 3 — Production | Staff+ discussions | Scale limits, failures, cost, debugging |
Interview Tip
Start with Level 1 in interviews. Depth-first on what the interviewer probes. Most candidates jump to Level 2 without establishing the mental model — interviewers find this hard to follow.
Interview Modes¶
The full Learn / Interview / Hint / Solution / Staff tab switcher is not wired on concept pages — see Project Status. Study like this instead:
- Learn — the page as written is the default (three-level model: intuition → engineering → production).
- Hint — exercises use
???hint blocks; try before revealing. - Solution — design / LLD exercises have a worked solution after you attempt it.
- Staff — some pages have Staff Q&A or seniority tabs (especially behavioural stories); not every concept page.
How to Use the Simulations¶
- Read the concept explanation first
- Run the simulation with default parameters
- Experiment by changing parameters, injecting failures
- Predict what will happen before clicking "Inject Failure"
- Explain the observed behaviour in your own words
Common Mistake
Do not click through simulations without reading first. The simulation is for verification of your mental model, not a substitute for understanding.
How to Use the Labs¶
Docker Compose (and one Terraform) environments live in Labs. Same cycle as a simulation, on a real process:
predict → run → compare → explain.
- Predict the outcome before each command in the lab README
- Run it
- Compare the actual log/metric to the prediction
- Explain the gap, then re-read the paired concept page if you were surprised
Do not rewrite the exercise after the fact to match the output — the surprise is the learning.
System Design Practice Protocol¶
For each system design exercise:
- Cover the solution page — work through it yourself first
- Start with clarifying questions (functional requirements)
- State non-functional requirements explicitly (latency, QPS, durability)
- Do capacity estimation (back-of-envelope)
- Sketch API + data model before architecture
- Start with the simplest possible architecture
- Identify bottlenecks before adding components
- Add components only when you can justify them
- Discuss failure modes for every major component
- Close with trade-offs and alternatives
DSA Practice Protocol¶
- Read the problem statement only
- Think for 5–10 minutes (no code)
- Identify the pattern from clues
- Code the brute force first
- Optimize to target complexity
- Handle edge cases explicitly
- Analyse complexity (time + space)
Pattern Recognition Clues¶
| Clue | Pattern |
|---|---|
| "contiguous subarray / window" | Sliding Window |
| "sorted array, find pair/triplet" | Two Pointers |
| "find in sorted / minimum value that satisfies" | Binary Search |
| "shortest path in unweighted graph" | BFS |
| "all paths / connected components" | DFS |
| "shortest path in weighted graph" | Dijkstra |
| "top K elements" | Heap |
| "dependencies / ordering" | Topological Sort |
| "all combinations / subsets" | Backtracking |
| "minimum possible maximum" | Binary Search on Answer |
| "overlapping subproblems" | Dynamic Programming |
| "same component / merge groups / undirected cycle" | Union-Find |
| "locally optimal / interval scheduling / greedy choice" | Greedy |
| "substring search / pattern in text" | KMP (or Rabin-Karp) |
| "prefix / autocomplete" | Trie |
| "how often in a stream" / p99 / set similarity | Count-Min / t-digest / MinHash |
| "range sum/min with updates" | Fenwick or segment tree |
| "ordered map, Redis ZSET" | Skip list |
Full clue table: DSA Patterns and Pattern Recognition.
Behavioural Practice Protocol¶
- For each theme, draft 3 real stories from your experience
- Apply STAR + Reflection: Situation → Task → Action → Result → What I Learned
- Calibrate to seniority level (see differentiation guide)
- Record yourself and listen back — clarity is a skill
- Have 6 load-bearing stories that can be adapted to different questions (see Behavioural)
Progress Tracking¶
Every page has a Mark this page complete button — check Your Progress for your overall completion, streak, and points across the curriculum.
Use this self-assessment after each module:
- [ ] Can I explain this concept clearly in 2 minutes?
- [ ] Can I design a system that uses this concept?
- [ ] Can I identify when this concept applies?
- [ ] Can I describe when it fails / its limitations?
- [ ] Can I debug a production issue involving this?
- [ ] Can I explain the trade-offs vs alternatives?
If any box is unchecked → review that dimension before moving on.
Common Failure Modes in Interviews¶
What NOT to do
- Jumping to architecture before requirements → interviewer doesn't know what you're optimizing for
- Naming technologies without justification → "I'll use Kafka" without explaining why
- One-size-fits-all designs → every problem solved with the same stack
- Ignoring failure modes → stopping after the happy path
- No capacity estimation → can't identify where bottlenecks will appear
- Memorized designs → can't adapt when the interviewer changes a constraint