Skip to main content

Build Your Own X: Architecture

The architecture phase is about data, contracts, and distributed coordination. The Build Your Own X projects in this phase let you implement the mechanisms behind the abstractions you use every day: indexes, query plans, replication, consensus, inverted indexes, and browser layout engines.

Each project is a self-contained tutorial with research links, the curated BYO-X external tutorial list preserved, milestones with code sketches, evidence requirements, common pitfalls, and module integration notes.

The improvement target for this phase is operational realism. A finished architecture project should not only run; it should name its workload, failure mode, consistency or durability boundary, measurement method, and the tradeoff it chose.

Use source guides responsibly

Do not paste external database, distributed-systems, or architecture tutorials into your portfolio. Use them as references, then write your own implementation, your own tests, and your own ADRs.


Projects in this phase

ProjectPrimary module fitDifficultyLanguages typically used
Database (Key-Value)Sem 6 M2 — storage & indexingMediumGo, Rust, C++
Database (Relational)Sem 6 M1–M4 — SQL, transactionsHardC, Go, Rust
Search EngineSem 6 M2 / Sem 7 M2MediumPython, Go
Web Server (HTTP from scratch)Sem 7 M4 — API designMediumC, Go, Node.js, Python
Web Browser EngineSem 7 M1–M2HardRust, Python
Kafka-like Distributed LogSem 6 M3 — replicationHardJava, Go, Rust
Consensus / RaftSem 6 M5 — distributed fundamentalsHardGo, Rust, Java
BlockchainSem 6 M3 + M5 — replication + distributedMediumPython, Go, JavaScript

Additional local book-backed projects:

ProjectPrimary module fitDifficultyLanguages typically used
Redis ServerSem 6 M2 + Sem 7 M4 - in-memory data serverMedium-HardC, C++, Go

Cross-phase projects:


Architecture module → project map

Semester 06: Databases and Distributed Systems

ModuleRecommended BYO projectsWhy it fits
Module 1 — Relational databases & SQLDatabase (Relational)Implementing a SQL parser + planner + executor demystifies the query layer
Module 2 — Storage engines & indexingDatabase (KV), Redis Server, Search EngineDisk-first storage, in-memory server behavior, and inverted indexes cover three different index/storage shapes
Module 3 — Replication & partitioningKafka-like, BlockchainPartitioned, replicated, ordered log for Kafka; PoW-replicated chain for Blockchain
Module 4 — Transactions & consistencyDatabase (Relational) (later milestones)MVCC, WAL, isolation
Module 5 — Distributed systems fundamentalsConsensus / Raft, BlockchainTwo consensus families: deterministic (Raft) vs probabilistic (Nakamoto)

Semester 07: Architecture and DDD

ModuleRecommended BYO projectsWhy it fits
Module 1 — Architecture fundamentals & qualityWeb Browser Engine (architectural case study)Browser engines are a textbook example of layered architecture with quality tradeoffs
Module 2 — Architecture patterns & modularityWeb Browser Engine, Search EngineModular pipeline (parse → style → layout → paint)
Module 3 — DDD & bounded contextsNone — design refactor better suits required projectUse the required Semester 7 project for DDD
Module 4 — API design & contract evolutionWeb Server, Redis ServerHTTP and RESP-style command protocols both force explicit framing, versioning, error, and compatibility decisions
Module 5 — ADRs & architecture reviews(all projects produce ADRs as part of evidence)Each completed project becomes a case study

Local source additions

The local Build Your Own source set adds Redis Server as a first-class project. The source ID is build-your-own/redis-james-smith; supporting source IDs are build-your-own/database-james-smith and build-your-own/web-server-node-james-smith.

Keep Database (Key-Value) focused on storage-engine durability and indexing. Use Redis Server when the goal is an in-memory data server with TCP protocol framing, event-loop behavior, TTLs, slow-client handling, and latency evidence.


Project quality rubric

DimensionMinimum acceptable evidenceStrong evidence
Workloadone stated access patternread/write mix, data size, and concurrency shape
Contractsupported API/protocol/query subsetcompatibility tests and explicit unsupported cases
State modeldocumented in-memory/on-disk structuresinvariants plus recovery or restart behavior
Failure modeone demonstrated failure casecrash, timeout, slow client, stale replica, or malformed input test
Measurementone benchmark runrepeatable script with latency, throughput, and resource numbers
Architecture noteone ADR or design notetradeoff comparison against an alternative design

This keeps book-backed projects from becoming reading assignments. They become small systems with evidence.


Build rules (architecture-flavored)

  1. The project must expose a real tradeoff, not only a happy path. Cache vs no cache, single-leader vs leaderless, hash index vs B-tree.
  2. Every data or architecture decision must name the access pattern or quality attribute behind it. "Why this index?" → "Because point lookups dominate range scans in this workload."
  3. Build small mechanisms from scratch when they teach. Use production tools when the module is about operating the decision.
  4. Diagrams, ADRs, query plans, and failure traces live close to the code.
  5. One operational tradeoff documented per project. What is sacrificed and what is gained.

Source