This repository is my long-term backend engineering second brain.
It is not a course notebook, not interview prep, and not project storage.
It is a structured system for:
- thinking in backend systems
- retaining engineering patterns
- documenting decisions and tradeoffs
- tracking real-world failure modes
- building execution playbooks
Engineering knowledge is not organized by topics.
It is organized by how systems are actually built and broken:
- Patterns (reusable solutions)
- Systems (full architectures)
- Decisions (why choices are made)
- Failures (how things break)
- Playbooks (how to execute under pressure)
engineering/
│
├── 00_core-principles/ → fundamental engineering laws
├── 01_patterns/ → reusable backend patterns
├── 02_systems/ → full system designs
├── 03_decisions/ → engineering tradeoffs & choices
├── 04_failure-modes/ → real-world system breakdowns
├── 05_playbooks/ → execution frameworks & checklists
Fundamental laws that apply across all systems.
- Consistency models (strong vs eventual)
- CAP theorem
- Latency vs throughput tradeoffs
- Backpressure
- Idempotency
These are not solutions.
They are constraints under which all systems operate.
Reusable solutions to recurring backend problems.
- Caching
- Queue-based processing
- Rate limiting
- Sharding
- Fan-out / fan-in
- CQRS
Each pattern should include:
- Problem
- Solution
- Variants
- When to use
- When NOT to use
Full system designs (end-to-end architectures).
- URL Shortener
- Chat system
- Feed system
- Rate limiter
- Notification system
Each system should include:
- Requirements (functional + non-functional)
- Architecture
- Data model
- API design
- Scaling strategy
- Bottlenecks
- Tradeoffs
Record of engineering judgment calls.
- Why Redis over in-memory cache?
- SQL vs NoSQL decision
- Queue vs direct processing
- Sync vs async architecture
Each entry must include:
- Context
- Options considered
- Decision
- Tradeoffs
- Outcome
Understand how systems break in reality.
- Cache stampede
- Thundering herd problem
- DB connection exhaustion
- Race conditions
- Partial failures in distributed systems
- Retry storms
Each failure mode should include:
- What it is
- Why it happens
- Impact
- Detection signals
- Mitigation strategies
Execution frameworks for engineering work.
- Designing a backend system in 45 minutes
- Debugging production issues
- API design checklist
- Scaling checklist
- System review checklist
These should feel like mental scripts used in real work situations.
This repo is updated continuously as I:
- extract patterns → store in /01_patterns
- design systems → store in /02_systems
- log tradeoffs → store in /03_decisions
- document breakdowns → store in /04_failure-modes
- convert into playbooks → /05_playbooks
If something is learned but not stored here:
it is considered temporary knowledge
This system should evolve into:
- a personal backend engineering reference system
- a reusable thinking framework
- a decision history of engineering growth
- a catalog of system behaviors (normal + failure states)
I should be able to:
- design systems faster
- recognize patterns instantly
- avoid known failure modes
- justify engineering decisions clearly
- operate like a production backend engineer under constraints