The Engineering Handbook

Open-source engineering curricula under one CC BY-SA 4.0 license. HLD and DSA today; more to come.

HLD Handbook: 159 chapters + 22 trade-off pages · 181 pages · ~773,000 words · 719 Mermaid diagrams · 3,100+ citations DSA Handbook: 120 chapters across 15 parts · 37 pattern decision pages · 5 long-form editorials · ~470,000 words · 226 Mermaid diagrams · sibling Python / Java / C++ / Go solutions for 155 LeetCode problems · 46 interactive widget specs

Read free at handbook.academy — landing page links to both books · HLD at hld.handbook.academy · DSA at dsa.handbook.academy (public beta)

Start reading · HLD curriculum · DSA curriculum · Trade-offs · Contributing

• What this is
• Reading the handbooks online
• What's in this repo
• Why this exists
• Who this is for
• How these handbooks compare
• Start reading
• The full HLD curriculum — 12 parts + 22-page Trade-offs Library
• The full DSA curriculum — 15 parts + 37 pattern decision pages + editorials + 46 widgets
• Study plans
• Project statistics
• Quality standards
• Contributing
• Project structure
• Development setup
• Governance
• FAQ
• License
• Citation
• Acknowledgments
• Community

This repository hosts two sibling open-source engineering handbooks under content/, sharing the same CC BY-SA 4.0 license, the same contribution workflow, and the same CI quality bar:

• The HLD Handbook (content/hld/) — an opinionated, end-to-end textbook on high-level software design, distributed systems, and modern infrastructure. 159 teaching chapters across 12 parts plus a 22-page Trade-offs Library — 181 pages, ~773,000 words, 719 Mermaid diagrams, 3,100+ citations. Equivalent in scope to a ~2,400-page book — longer than Designing Data-Intensive Applications and Alex Xu's System Design Interview volumes 1+2 combined. Covers TCP/IP and the OS contract through to LLM serving, multi-agent orchestration, and post-quantum crypto.
• The DSA Handbook (content/dsa/) — a practice-first data-structures-and-algorithms curriculum aimed at coding interviews and competitive programming. 120 chapters across 15 parts plus 37 pattern decision pages, 5 long-form LC editorials, and 46 interactive widget specs. ~470,000 words, 226 Mermaid diagrams. Each chapter teaches a structure or pattern, then walks the canonical LeetCode problems, with sibling sol.py / sol.java / sol.cpp / sol.go files for 155 problems. Python is inlined in the chapter; the other three languages are linked.

More curricula are planned. This repo is structured as an umbrella so additional handbooks (e.g. operating systems, databases, ML systems) can land alongside HLD and DSA over time, sharing the same workflow and license.

Every concept in either handbook is taught inline as a full-length article: introduction, first-principles explanation, diagrams, worked examples, trade-offs, production gotchas, citations to primary sources. No stubs. No "coming soon." No external blog redirects. No bullet outlines that tell you to go somewhere else to actually learn.

Every .md file under content/ also renders natively on GitHub — all 945 Mermaid diagrams display in the GitHub UI, all footnotes work, all cross-references resolve. The websites add search, dark mode, per-chapter diagram zoom, social cards, OG images, the interactive DSA widgets, and fast client-side navigation.

Both handbooks are continuously updated. Every chapter's frontmatter declares date_created and date_updated, so you can see exactly how fresh each page is. We care about numbers being right today, not right in 2022.

Each book has its own subdomain. The umbrella landing page links to both:

Each subdomain serves one book at the root — URLs do not nest. HLD chapters live at hld.handbook.academy/curriculum/..., not handbook.academy/hld/.... Same for DSA.

This repository is the canonical content source for both books. PRs to either handbook are welcome.

• content/hld/ — 159 HLD chapters across 12 parts + 22 trade-off decision pages. The chapter template is intro → first principles → diagrams → worked example → trade-offs → production gotchas → references. See STYLE_GUIDE.md.
• content/dsa/ — 120 DSA chapters across 15 parts. The chapter template is practice-first: cheat-sheet table, deep dive on the structure or pattern, prompt cards for representative LeetCode problems, and <details> solution + common-mistakes blocks. Code samples live as sibling files (sol.py, sol.java, sol.cpp, sol.go) under each chapter's directory. See STYLE_GUIDE.md § DSA-specific deviations and content/dsa/part-1-linear-data-structures/00-arrays.md as the canonical example.
• content/dsa/editorials/ — long-form LeetCode editorials covering hard problems with multiple approaches.
• content/dsa/patterns/ — pattern decision references that compare interchangeable approaches (e.g. recursion vs iteration, BFS vs DFS, sliding window vs prefix sum).
• content/dsa/widgets/ — 46 YAML specs for the interactive widgets that render on the DSA website. On GitHub these are callouts that link to the spec; on the website the widget renders.
• content/dsa/_problem-registry.yml — canonical LC-NNN ID registry; the website source-of-truth for every LeetCode problem the curriculum touches.

The open-source curricula for system design and DSA have a shape, and that shape is frustrating:

• Link dumps — curated lists that point at dozens of scattered blog posts, LeetCode discuss threads, and talks. Great for discovery, useless as a learning path. You end up with 60 tabs open and no through-line.
• Teaser-and-redirect repos — READMEs with a few hundred words on each topic that nudge you toward a paid course hosted elsewhere. The GitHub repo is the marketing page; the actual teaching is behind a $150-$400+/year paywall.
• Monolithic READMEs frozen in time — a single 5,000-line README.md that was great in 2021 but hasn't kept up with the modern stack. No LLM serving, no CRDTs, no post-quantum crypto, no FinOps. And nobody wants to review a PR against a 5,000-line file.
• Surface-level outlines — bullet-point summaries that tell you what exists without explaining why you'd pick one approach over another. You learn the vocabulary without the judgment.
• Interview-only prep — focused on passing a specific 45-minute screen, not on actually operating systems at scale or actually understanding the algorithm.

These handbooks fix all of that:

• 100% inline content. Every chapter is a full teaching article written from scratch, living in this repo as plain Markdown. Nothing is a stub. Nothing redirects you elsewhere to learn.
• Progressive curricula. HLD has 159 teaching chapters across 12 parts plus a 22-page Trade-offs Library, sequenced from prerequisites (Part 0) to Staff+ topics. DSA has 120 chapters across 15 parts, from arrays to bitmask DP, with each part introducing a tighter pattern family. Each chapter declares its prerequisites, learning objectives, estimated reading time, and difficulty tier.
• Research-backed. Every HLD chapter ends with a Further Reading & References section citing primary sources — SIGMOD and OSDI papers, RFCs, IETF drafts, engineering postmortems, official docs, canonical books. 3,100+ citations across HLD. DSA chapters cite the original papers behind each algorithm where they exist (Floyd, Tarjan, Knuth-Morris-Pratt, Aho-Corasick).
• Opinionated. Every topic picks a recommended approach and explains why. Where reasonable people disagree, the trade-offs are made explicit — HLD has a dedicated 22-page Trade-offs Library; DSA has 37 pattern decision pages that compare interchangeable approaches (recursion vs iteration, BFS vs DFS, sliding window vs prefix sum, and so on).
• Modern (2025+). HLD covers LLM serving, RAG pipelines, AI agents, multi-agent orchestration, CRDTs, edge computing, FinOps, post-quantum cryptography, platform engineering, local-first software, differential privacy, MCP. DSA covers the modern competitive-programming toolkit: monotonic stacks/deques, Morris traversal, suffix arrays, Aho-Corasick, bitmask DP, randomised algorithms.
• Practice-first for DSA. Every DSA chapter ships with sibling code samples in Python, Java, C++, and Go for the canonical LeetCode problems it teaches. Python is inlined in the chapter; the other three languages are one click away. 155 LeetCode problems are covered in this format.
• Interactive on the website. The DSA book's 46 widget specs render as live, animated visualisations on dsa.handbook.academy (sliding windows that you can drag, monotonic stacks that animate the pop sequence, etc.). On GitHub the widget callouts link to the YAML spec.

These handbooks are written for:

• SDE1 engineers preparing for SDE2 interviews. Read DSA Parts 0-9 for coding-round fluency, then HLD Part 0 + Part 1 + Part 11, plus 8-10 targeted case studies from HLD Part 8, plus the top-5 most-cited trade-off pages.
• SDE2s preparing for Senior/Staff. The full HLD Parts 3-7 are the core "you need to know this to design anything meaningful" material. Parts 6 (Reliability) and 7 (Security) separate Senior candidates from Staff candidates. DSA Part 14 covers narration and trade-off articulation in the algorithmic round.
• Senior/Staff engineers refreshing or filling gaps. HLD Part 9 (AI/ML systems) and the Trade-offs Library are valuable even if you've been doing this for 15 years. Modern LLM serving and vector search weren't a thing when most of us learned backend.
• Self-taught engineers without a CS degree who want the vocabulary and the reasoning that bootcamps and YouTube don't teach. HLD Part 0 is explicit prerequisites: TCP/IP, the OS contract, database internals, API design. DSA Part 0 is the foundations — Big-O, recursion, bit manipulation — before pattern-matching becomes useful.
• Career switchers moving from adjacent roles (frontend → backend, backend → infra, SWE → MLE) who need to build system-level intuition fast.
• Competitive programmers and ICPC/Codeforces contestants who want a structured reference for the algorithmic toolkit (KMP, Aho-Corasick, suffix arrays, segment trees, Dijkstra, Bellman-Ford, DP variants).
• Teachers and course creators who want to build curriculum without writing thousands of pages from scratch. The CC BY-SA 4.0 license explicitly allows this.
• Anyone operating a production system at non-trivial scale who wants a reference shelf that covers the full stack — from packet-level networking to multi-tenant SaaS isolation models.

These handbooks are NOT for:

• Absolute beginners with no programming experience. HLD Part 0 assumes you can read code and have built at least one CRUD app. DSA Part 0 assumes you can write a for loop and a recursive function. If you're brand new, start with The Odin Project or CS50, then come back.
• People who want low-level language-specific tutorials. We don't teach Rust syntax or Go's goroutines — we teach concepts that apply across languages.

For the best reading experience, visit hld.handbook.academy for HLD or dsa.handbook.academy for DSA — free, no sign-up, full search, dark mode, per-chapter diagram zoom, and the live DSA widgets. The links below open the source on GitHub, where Mermaid diagrams also render natively.

Pick one:

I want a quick HLD taste. Read these three in order — they give you the vocabulary and the first real worked example:

1. Scalability: Growing a System Without Breaking It
2. Back-of-the-Envelope Estimation
3. Design a URL Shortener (TinyURL / bit.ly)

I want a quick DSA taste. Read these three to see the chapter shape and the sibling-code workflow:

1. Arrays: static, dynamic, multi-dimensional
2. Two pointers: opposite ends
3. Sliding window: variable size

I'm preparing for an SDE2 interview in the next 6 weeks. Follow the SDE1 → SDE2 study plan.

I'm a Senior engineer refreshing my distributed-systems foundations. Read HLD Part 3 — Distributed Systems Theory straight through.

I want to learn AI-systems design. Read HLD Part 9 — AI & ML System Design + the 8 AI case studies in Part 8 (chapters 30-37).

I want to grind interview algorithms. Open the DSA curriculum. Read Parts 0-2 in order, then jump into the pattern parts (3-9) as the problems you encounter call for them.

I want to read both books cover-to-cover. Start at HLD Part 0 for the systems track and DSA Part 0 for the algorithms track. At one 25-minute chapter per day, the whole repo is roughly a year of reading.

181 pages across 12 parts + a 22-page Trade-offs Library. Each part below is collapsed by default — click to expand the chapter list. Linking to a specific part from elsewhere in the README auto-expands it on GitHub.

120 chapters across 15 parts, plus 37 pattern decision pages, 5 long-form editorials, and 46 interactive widget specs. Each chapter is centered on a specific data structure or algorithmic pattern, taught with worked LeetCode problems. Sibling sol.py / sol.java / sol.cpp / sol.go files live under each problem directory; the Python solution is inlined in the chapter, the others are linked. Editorials, pattern decision diagrams, and widget YAML specs are siblings under content/dsa/.

Each part below is collapsed by default — click to expand the chapter list. Linking to a specific part from elsewhere in the README auto-expands it on GitHub.

Audience: anyone deciding "which pattern fits this problem?" mid-interview. Difficulty: Intermediate. Total reading time: ~10 hours total; each page is a 15-30 min decision aid.

Each page is a focused decision-comparison: a Mermaid decision tree, a "pick A vs pick B" table, archetype problems on each side, and references. Click to expand the full list.

Audience: anyone who's solved an "easy" problem and wants the senior-engineer-level analysis behind it. Difficulty: Intermediate. Total reading time: ~2 hours total.

Five canonical interview problems treated as full editorial-style essays: every approach (brute force → optimized → optimal), the proof of correctness, the edge cases, the production framing, and the follow-up variants.

Audience: contributors authoring or editing the website's interactive widgets. Format: YAML; rendered as interactive animations on dsa.handbook.academy.

Each widget is described as keyframe data plus narration in YAML. The website's renderer turns each spec into an interactive (play/pause/scrub/step) animation alongside the chapter prose. Click to expand the full list.

Widgets are catalogued in content/dsa/widgets/_widget-registry.yml; see content/dsa/widgets/README.md for authoring conventions.

You don't need one — pick any chapter and start reading. These are here if you prefer a pre-built route, typically because you're preparing for a specific interview window or filling a specific gap.

Goal: pass a 45-60 minute system-design screen at a mid-to-senior level. Roughly 8-10 hours of reading per week.

Goal: operate at Senior level, own cross-team architecture, pass loops at Senior+ bars.

Read everything in order. Use the end-of-chapter questions for active recall. Average one 25-minute chapter per day gets you through the whole thing in about 6 months, with buffer for harder chapters and re-reading.

If you already know the fundamentals and want to become fluent specifically in AI-systems design:

If you have a loop on Monday:

• Saturday morning: How to Approach a System Design Question + Back-of-the-Envelope Estimation + Requirements Scoping + Diagramming Skills
• Saturday afternoon: 3 case studies in your domain
• Sunday morning: 3 more case studies + Trade-off Articulation
• Sunday evening: Company-Specific Interview Flavors for your target

For comparison, the HLD book alone is longer than Designing Data-Intensive Applications (~600 pages) + Alex Xu's System Design Interview Vol. 1 (~300 pages) + Vol. 2 (~340 pages) combined. The DSA book is comparable in length to Cracking the Coding Interview (~700 pages) plus Elements of Programming Interviews (~480 pages).

Every chapter in this repository passes 7 automated CI checks on every PR. The validators run against both books and dispatch on a per-book schema:

1. markdownlint — Markdown style and structure conformance.
2. typos — source-code spell-check with a project-specific allowlist for technical terms.
3. Citation integrity — every [^1]-style footnote has a corresponding [^1]: source definition; every citation is a real URL; no orphan citations.
4. Frontmatter validation — HLD chapters declare title, difficulty, prerequisites, date_created, date_updated, reading_time_minutes, tags (canonical taxonomy), and technologies (curated allowlist). DSA chapters declare title, slug, part, chapter, difficulty, languages (subset of python/java/cpp/go), canonical_test, widgets, and ladder (referencing LC-NNN IDs in _problem-registry.yml). Editorials and pattern decision pages have their own thinner schemas. See scripts/check-frontmatter.mjs for the per-book branches.
5. Mermaid diagram validation — all 945 diagrams across both books must parse with @mermaid-js/mermaid-cli on CI so broken syntax doesn't ship.
6. Vale — prose-style linter for voice, passive voice, weasel words, and banned phrases. Custom rules in .vale.ini.
7. lychee — external link checker run weekly; flags rotted URLs so citations stay valid.

CI configuration lives in .github/workflows/content-ci.yml. Validator scripts are in scripts/.

Beyond automation, every chapter is reviewed for:

• Internal consistency (terminology matches Part 1 definitions)
• Difficulty calibration (a "Beginner" chapter doesn't assume Staff-level context)
• Diagram quality (Mermaid, not screenshots; captioned; accessibility-tagged)
• Citation quality (primary sources preferred over summarizing blog posts)

Contributions of all sizes are welcome, from a typo fix to a full chapter. Read CONTRIBUTING.md for the full workflow. A short summary:

1. Read the STYLE_GUIDE.md for voice, structure, diagram conventions, and citation format.

2. Open an issue first for anything bigger than 30 minutes of work — this ensures you don't duplicate in-flight work.

3. Fork, branch, edit. Use descriptive branch names like fix/raft-quorum-math or add/mcp-protocol-chapter.

4. Run validators locally (optional):

   npm install
   npm run check:all

   If you skip this, CI will run them on your PR anyway and tell you what to fix.

5. Submit a pull request using the PR template. Small fix? A one-sentence description is fine. Full chapter? Describe the pedagogical approach and list your primary sources.

6. Respond to review. A maintainer will review within 7 days (usually faster). For content chapters, expect at least one round of technical review.

• Correctness. If you're citing a number, cite the primary source. If you're claiming a property (like "Raft guarantees linearizability"), cite the paper.
• Clarity. Write for the difficulty tier declared in the chapter's frontmatter. Don't introduce Part-7 concepts in a Part-0 chapter.
• Opinion with evidence. If you think the chapter should recommend something different, make the case with citations, not vibes.
• Pedagogical structure. Intro → first principles → diagram → worked example → trade-offs → production gotchas → references. Deviate only when the topic genuinely demands it.

If you have operated one of the systems we cover in Part 8 (payment processing, real-time chat, feeds, video streaming, etc.) — your review is worth more than a month of solo research. Open an issue with your expertise area and which chapter you'd like to review.

• Security issues in validator scripts or CI: open a private security advisory.
• Code of conduct concerns: email hello@handbook.academy.
• Legal or licensing questions: email hello@handbook.academy.
• Direct contact: @invincible04.

engineering-handbook/
├── content/                           # Two open-source books (CC BY-SA 4.0)
│   ├── hld/                           # HLD Handbook — 181 pages
│   │   ├── part-0-prerequisites/          # 5 chapters
│   │   ├── part-1-core-fundamentals/      # 7 chapters
│   │   ├── part-2-building-blocks/        # 16 chapters
│   │   ├── part-3-distributed-systems-theory/  # 11 chapters
│   │   ├── part-4-data-systems/           # 10 chapters
│   │   ├── part-5-architecture-patterns/  # 11 chapters
│   │   ├── part-6-reliability-and-operations/  # 11 chapters
│   │   ├── part-7-security-at-scale/      # 10 chapters
│   │   ├── part-8-case-studies/           # 56 chapters
│   │   ├── part-9-ai-ml-system-design/    # 15 chapters
│   │   ├── part-10-emerging-patterns/     # 1 chapter
│   │   ├── part-11-interview-framework/   # 6 chapters
│   │   └── trade-offs/                    # 22 decision pages
│   └── dsa/                           # DSA Handbook — 120 chapters
│       ├── part-0-foundations/        # 7 chapters
│       ├── part-1-linear-data-structures/  # 8 chapters
│       ├── part-2-search-sort/        # 8 chapters
│       ├── part-3-pointers-window-prefix/  # 6 chapters
│       ├── part-4-stack-queue-patterns/  # 5 chapters
│       ├── part-5-linked-lists/       # 6 chapters
│       ├── part-6-trees-heaps/        # 11 chapters
│       ├── part-7-recursion-backtracking/  # 7 chapters
│       ├── part-8-graphs/             # 13 chapters
│       ├── part-9-dynamic-programming/  # 15 chapters
│       ├── part-10-greedy/            # 5 chapters
│       ├── part-11-bit-manipulation/  # 4 chapters
│       ├── part-12-strings-pattern-matching/  # 6 chapters
│       ├── part-13-design-the-data-structure/  # 7 chapters
│       ├── part-14-interview-framework/  # 12 chapters
│       ├── editorials/                # Per-LC long-form editorials
│       ├── patterns/                  # Pattern decision references
│       ├── widgets/                   # YAML specs for interactive widgets
│       ├── _problem-registry.yml      # Canonical LC-NNN registry
│       └── _widget-registry.yml       # Canonical w-NN/e-LCNNN registry
│
├── writing-guides/                    # Author handbooks (CC BY-SA 4.0)
│   ├── case-study-template.md         # Skeleton for Part 8 case studies
│   └── trade-off-template.md          # Skeleton for trade-off decision pages
│
├── scripts/                           # Content validators used by CI
│   ├── check-citations.mjs            # Footnote integrity
│   ├── check-frontmatter.mjs          # YAML frontmatter schema (per-book)
│   ├── check-mermaid.mjs              # Mermaid syntax validator
│   ├── content-stats.mjs              # Word / diagram / citation counts
│   ├── technologies.json              # Curated technology name taxonomy (HLD)
│   └── update-frontmatter-dates.mjs   # Bulk-touch date_updated on edited files
│
├── .github/
│   ├── workflows/
│   │   ├── content-ci.yml             # PR validation pipeline (both books)
│   │   └── stale.yml                  # Issue/PR hygiene
│   ├── ISSUE_TEMPLATE/                # Correction / Request / Writing templates
│   ├── PULL_REQUEST_TEMPLATE.md
│   ├── CODEOWNERS
│   ├── FUNDING.yml
│   ├── dependabot.yml
│   └── release.yml
│
├── STYLE_GUIDE.md                     # Voice, structure, diagram conventions
├── CONTRIBUTING.md                    # Full contribution workflow
├── CODE_OF_CONDUCT.md                 # Contributor Covenant v2.1
├── CONTRIBUTORS.md                    # All-contributors list
├── SECURITY.md                        # Security disclosure process
├── CITATION.cff                       # Citation metadata (Zenodo, academic tools)
├── LICENSE                            # CC BY-SA 4.0 (everything in this repo)
├── package.json                       # Dev dependencies for validators
├── lychee.toml                        # Link-check configuration
├── .vale.ini                          # Prose style rules
├── .markdownlint.json                 # Markdown style rules
└── .typos.toml                        # Spell-check allowlist

You don't need anything installed to contribute content — edit Markdown, push, let CI validate. But if you want to run the checks locally before pushing:

• Node.js 20+ (the .nvmrc file pins the exact version)
• npm (ships with Node)
• Optional: Vale for prose-style linting
• Optional: lychee for link checking

git clone https://github.com/handbook-academy/engineering-handbook.git
cd engineering-handbook
nvm use                    # pins Node version from .nvmrc
npm install                # installs markdownlint, @mermaid-js/mermaid-cli, etc.

# Run all 7 content checks (same as CI)
npm run check:all

# Individual checks
npm run lint               # markdownlint
npm run check:citations    # footnote integrity
npm run check:frontmatter  # YAML schema
npm run check:mermaid      # Mermaid diagram syntax
npm run check:typos        # spell-check
npm run check:links        # lychee link check (slow; runs weekly)

# Optional
npm run prose              # Vale prose-style linter (requires Vale installed)
npm run stats              # word / diagram / citation counts

Use Markdownlab (source) for editing chapters. It's a browser-based Markdown editor with live preview, Mermaid rendering, and the same callouts/footnotes/admonitions this handbook uses — no install, no setup.

Open any chapter directly in the editor by prefixing its GitHub URL with https://markdownlab.vercel.app/:

https://markdownlab.vercel.app/https://github.com/handbook-academy/engineering-handbook/blob/main/content/hld/part-1-core-fundamentals/00-scalability.md

That URL opens the chapter in Markdownlab pre-loaded and ready to edit. Paste your edits back into a fork → branch → PR.

The repo includes .editorconfig, .nvmrc, .markdownlint.json, .vale.ini, and .typos.toml so any editor that reads them picks up project settings automatically.

Benevolent maintainer model. The project is currently solo-maintained by @invincible04. Major architectural decisions (curriculum scope, licensing, CI strategy) are made by the maintainer after consultation with active contributors via Issues/Discussions.

Decision process:

• Typo / dead link / factual correction: any maintainer can merge.
• New chapter or major rewrite: requires an issue with pedagogical rationale and at least one maintainer approval.
• Curriculum scope change (new part, renamed part, reordering): requires a Discussion thread open for at least 7 days before merge.
• License change: requires all-contributors consent; CC BY-SA 4.0 for everything in this repository is a stable commitment.

Becoming a maintainer. Sustained, high-quality contributions over 3+ months can result in a maintainer invitation. This includes merge rights on your areas of expertise and a vote on curriculum-scope decisions.

See CODEOWNERS for the current maintainer routing.

Everything in this repository — the 343 chapters and decision pages across both books, writing guides, style guide, validator scripts, templates, and configuration — is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).

What CC BY-SA 4.0 means in practice:

You can:

• Read it, share it, print it, screenshot it — forever.
• Build courses, boot camps, YouTube channels, or books derived from it.
• Translate it into any language.
• Use it commercially.

You must:

• Attribute the original (link back to this repo).
• Release derivatives under the same CC BY-SA 4.0 license (share-alike).
• Not relicense the content as proprietary or impose additional restrictions.

Nobody can paywall the chapter text itself under CC BY-SA 4.0. You can build anything on top of it, as long as the text itself stays open. Read both handbooks free at handbook.academy — no sign-up, no paywall, ever.

If you reference this project in academic work, blog posts, books, or courses:

@misc{engineering-handbook,
  author       = {Soni, Aayush},
  title        = {The Engineering Handbook: Open-Source Engineering Curricula (HLD + DSA)},
  year         = {2026},
  publisher    = {GitHub},
  url          = {https://github.com/handbook-academy/engineering-handbook},
  note         = {HLD: 159 chapters + 22 trade-off pages, ~773K words. DSA: 120 chapters across 15 parts, ~470K words, 155 LeetCode problems with 4-language solutions. CC BY-SA 4.0.}
}

"The Engineering Handbook (HLD + DSA)" by Aayush Soni, https://github.com/handbook-academy/engineering-handbook, CC BY-SA 4.0.

The CITATION.cff file in this repository is a Citation File Format descriptor. GitHub's "Cite this repository" button, Zenodo, Zotero, and academic reference managers can parse it directly.

This project stands on the shoulders of many, and we cite primary sources liberally throughout. A few that shaped the handbook most:

Canonical books — HLD:

• Martin Kleppmann — Designing Data-Intensive Applications is the foundation underneath most of HLD Parts 3-4.
• Alex Xu — System Design Interview Volumes 1 and 2 defined the interview case-study format we build on in HLD Part 8.
• Chip Huyen — Designing Machine Learning Systems and AI Engineering shape HLD Part 9.
• Betsy Beyer et al. (Google) — Site Reliability Engineering and The SRE Workbook are behind HLD Part 6.
• Mark Richards & Neal Ford — Fundamentals of Software Architecture and Software Architecture: The Hard Parts for HLD Part 5.

Canonical books — DSA:

• Cormen, Leiserson, Rivest, Stein (CLRS) — Introduction to Algorithms is the bedrock for proofs, complexity arguments, and the algorithms in DSA Parts 2, 8, 9, and 12.
• Robert Sedgewick & Kevin Wayne — Algorithms, 4th Edition shapes the data-structure exposition in DSA Parts 1, 5, 6, and 8.
• Jon Bentley — Programming Pearls is the spirit behind the prompt cards.
• Steven & Felix Halim — Competitive Programming for the contest-driven techniques in DSA Parts 9, 11, and 12.
• Adnan Aziz, Tsung-Hsien Lee, Amit Prakash — Elements of Programming Interviews for the problem-shaping that influenced the DSA prompt cards.
• Gayle Laakmann McDowell — Cracking the Coding Interview for setting the bar on interview-style explanations.

Open-source references:

• Donne Martin — system-design-primer.
• NeetCode — neetcode.io and the NeetCode 150 problem list for the DSA practice ladder template.
• LeetCode community — for the canonical problem corpus and the editorial conventions we adapt.
• The Kubernetes, CNCF, and OpenTelemetry communities — for cloud-native and observability standards.
• The Apache projects (Kafka, Cassandra, Hadoop, Spark, Flink) — for foundational distributed-systems code and docs.

Papers, RFCs, and postmortems:

• SIGMOD / VLDB / OSDI / SOSP / NSDI papers — the bedrock of distributed systems.
• IETF / W3C / IANA — for networking and web standards.
• Every engineer who has written a public postmortem. Real outages taught us everything about graceful degradation, blast radius, and the limits of testing.

We teach the same concepts in our own words, with our own diagrams, and we cite the originals.

• GitHub Discussions — design questions, feedback, sharing what you're building.
• GitHub Issues — corrections, content requests, chapter proposals.
• Email — hello@handbook.academy for private or sensitive matters.
• Maintainer — @invincible04.

If you find this useful, star the repo. Stars help signal to new contributors that the project is worth their time.