# Battle-Tested Patterns: 46 code-level patterns with real sources

> Battle-Tested Patterns is a documentation site that catalogs 46 code-level programming techniques from React, Linux, Go, and Chromium, pairing each with a pinned source link, runnable exercises, and a verification pipeline.

**Totoro-jam/battle-tested-patterns** — Battle-tested programming patterns from production codebases — React, Linux, Go, Chromium, and more. Precise source links, multi-language examples, runnable exercises.

- Repository: https://github.com/Totoro-jam/battle-tested-patterns
- Website: https://patterns.totorojam.com
- Stars: 341 · Forks: 42
- Language: TypeScript
- License: MIT
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/totoro-jam-battle-tested-patterns

## Every pattern pins a commit hash and a line range

The catalog's distinguishing move is that each entry links to the exact production code that already uses the technique, frozen at a specific commit. A Bitmask entry points at a range in React's `ReactFiberFlags.js` and at lines 25 to 33 of Linux's `stat.h`. Double Buffering cites React's `ReactFiber.js` and SDL's `SDL_render.c`. Cooperative Scheduling cites React's `Scheduler.js` and lines 4143 to 4200 of the Go runtime's `proc.go`. Every URL carries a full commit identifier rather than a branch name, so the linked lines stay put even if the upstream project refactors. The accompanying descriptions are equally concrete: Bitmask packs N flags into one integer so any combination can be checked in O(1); Double Buffering swaps two copies atomically with zero allocation; Cooperative Scheduling yields control between work chunks to stay responsive. The point is verifiability: a reader can jump from a one-line explanation to the real implementation and judge for themselves whether it matches their problem.

## Forty-six patterns sorted into five fixed categories

The catalog is organized into five groups with a fixed headcount. Data Structures holds eleven entries, from Bitmask and Min Heap to B+ Tree, Tagged Union, and Merkle Tree. Concurrency holds nine, covering Semaphore, Actor Model, Work Stealing, MVCC, Backpressure, Event Loop, and Logical Clock. Systems holds twelve, including Circuit Breaker, Rate Limiter, Retry Backoff, Write-Ahead Log, Consistent Hashing, LSM Tree, and Checkpointing. Memory holds eight, such as Object Pool, Flyweight, Arena Allocator, Free List, Copy-on-Write, Reference Counting, Tombstone, and Interning. Behavioral holds six, among them State Machine, Observer, Iterator, Diff / Patch, Vtable, and Visitor. Each pattern carries a one-line summary of what it does, such as packing flags into one integer or swapping two copies atomically. The summaries stay mechanical rather than philosophical: MVCC is described as snapshot isolation, the Event Loop as I/O multiplexing, the Write-Ahead Log as durability, and the LSM Tree as a write-optimized store. A Bloom Filter answers set membership, a Trie handles prefix search, and a Skip List maintains a probabilistic order.

## The catalog's stated gap against books and algorithm repos

The project names the gap it is trying to fill by contrasting three existing resources. Design-patterns books are described as too abstract and too OOP-centric. Algorithm repositories are described as disconnected from real engineering. System design guides are described as operating at the architecture level rather than the code level. Battle-Tested Patterns positions itself at the code level instead, sourcing techniques from React, Linux, Go, and Chromium and attaching verifiable source links to each. That framing explains the emphasis on concrete mechanisms, such as a bitmask or a logical clock, rather than on named object-oriented forms. It also explains why the examples lean on systems code and runtime internals as much as on application frameworks.

## Exercises run under Rust, Go, Python, and TypeScript

Runnable exercises sit alongside the explanations, and the project keeps them honest by running each language's test runner. The scripts dispatch straight into the language toolchains:

```bash
cd exercises/rust && cargo test
cd exercises/go && go test ./...
```

A separate script drives the Python exercises, another runs the TypeScript exercise package, and a top-level `test` script chains the documentation tests and the exercise tests together. The dispatch logic lives in a `scripts/` directory, with `test-exercises.ts` fanning out to the language runners. Directory names in the tree confirm the split between the Rust, Go, Python, and TypeScript exercise sets. The exercise directories are versioned inside the same repository as the docs, so an example and the technique it teaches move together. The language keywords advertised in the package metadata line up with these runners: typescript, rust, go, and python all appear, alongside patterns for data structures, algorithms, systems programming, and concurrency.

## Docs and exercises share one pnpm workspace

The site and the exercises are separate packages inside a single pnpm workspace. The top-level scripts proxy into the docs package by filter rather than by directory:

```bash
pnpm --filter docs dev
pnpm --filter docs build
```

The repository layout backs this up. A `docs/` directory holds the site, an `exercises/` directory holds the practice code, and `pnpm-workspace.yaml` ties them together. Supporting files include `scripts/` for the check tooling, `plugins/` and a `.claude-plugin/` directory for editor integration, and a `CNAME` file that anchors the custom domain `patterns.totorojam.com`. Alongside the English documentation there is a Chinese translation served from a `/zh/` path and a parallel `README.zh-CN.md`, so the site is explicitly bilingual rather than English only.

## A check pipeline guards structure, zh parity, and code

Because the catalog is large and translated, the project leans on a scripted review gate. The aggregate `check` script chains several stages together:

```bash
pnpm lint && pnpm typecheck && pnpm test && pnpm verify-code && pnpm verify-mermaid && pnpm check:content
```

Individual check scripts cover more specific failure modes. There is a structure check, a Chinese parity check that keeps the two language versions aligned, an exercises check, and a relations check for cross-links between patterns. Separate generators produce a skill catalog and can run in check-only mode to catch drift. The presence of `verify-code` and `verify-mermaid` suggests that embedded snippets and diagrams are validated rather than trusted, which fits a project whose whole premise is that its code samples can be traced. Versioning is handled by release automation configured in `release-please-config.json`.

## Proven in React, Linux, Go, Redis, and Chromium

The catalog credits a long list of production codebases as the places its techniques appear in use: React, Linux, Go, Redis, PostgreSQL, Kafka, Chromium, Tokio, Erlang/OTP, LevelDB, RocksDB, etcd, Nginx, Akka, LLVM, Vue, Godot, PyTorch, CPython, and ZFS. That spread is what lets the same pattern show up across very different domains, such as a data structure reused in a renderer, a database engine, and a compiler. Alongside the source links, each pattern page carries an interactive visualization with time-travel playback, letting a reader step through how the mechanism evolves rather than only reading about it. The pattern pages and their source links are the core of the experience; the exercises and the bilingual site are the surrounding structure. Nothing in the catalog is presented as a new invention, since the framing throughout is that these mechanisms already run in production and are worth studying where they live.

## Conclusion

Battle-Tested Patterns suits engineers who want a technique traced to the exact production line that implements it, and who learn better from a runnable exercise than from prose. It is a weaker fit for anyone seeking a classic object-oriented design-patterns textbook, because the catalog deliberately skips that abstraction. Before adopting it, skim the source links for the patterns you care about to confirm the technique matches your stack, and note that the project is MIT licensed and versioned through release automation rather than a published paper.

## FAQ

### What is Battle-Tested Patterns?

A documentation site and exercise repository cataloging 46 code-level programming patterns drawn from production codebases such as React, Linux, Go, and Chromium.

### How does Battle-Tested Patterns verify its source links?

Each pattern points to a specific commit and line range in the original codebase, such as React's ReactFiber.js or Linux's stat.h, so the technique can be traced to real code that still exists at that revision.

### Which languages do the Battle-Tested Patterns exercises cover?

Rust, Go, Python, and TypeScript. Scripts run cargo test in exercises/rust, go test in exercises/go, a Python runner, and the exercises package test.

### How is the Battle-Tested Patterns catalog kept consistent?

A check pipeline runs lint, typecheck, tests, verify-code, verify-mermaid, and content checks, with separate scripts for structure, Chinese parity, exercises, and cross-link relations.

## Sources

- [License: MIT](https://github.com/Totoro-jam/battle-tested-patterns/blob/main/LICENSE)
- [Project website](https://patterns.totorojam.com)
- [README](https://github.com/Totoro-jam/battle-tested-patterns/blob/main/README.md)
- [Releases](https://github.com/Totoro-jam/battle-tested-patterns/releases)
- [Totoro-jam/battle-tested-patterns on GitHub](https://github.com/Totoro-jam/battle-tested-patterns)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/totoro-jam-battle-tested-patterns