Ramp week
Foundations ramp — get fluent before the first socket
Phase 0 · ramp Week 0 · the week before Week 1
Ramp week
Redis — how bytes become a database
M1 · Storage Weeks 1–7 · Sep 21 – Nov 7
Ramp week
SQLite — B-trees vs LSM
M2 · Engines Weeks 8–9 · Nov 9 – Nov 21
Ramp week
HTTP server — encoding & the wire
M3 · Encoding Weeks 10–12 · Nov 23 – Dec 12
Ramp week
DNS server — the binary packet
M4 · The packet Weeks 13–14 · Dec 14 – Dec 26
Ramp week
Kafka — consistency & consensus
M5 · Consensus Weeks 15–19 · Dec 28 – Jan 30, 2027
Ramp week
Systems in the wild — the writeup
Capstone Weeks 20–22 · Feb 1 – Feb 20, 2027
Ramp week
Build · M1
Redis
Build a Redis server from raw sockets to replication — defend choosing an in-memory store over disk, and name exactly when that choice breaks.
– · 0%
“RESP vs JSON for a wire protocol: what Redis traded away, and the workload where I’d make the opposite call.” not started
“RDB vs AOF: the durability/latency/recovery trade I’d default to, and the workload that flips it.” not started
“Single-leader vs multi-leader: where I draw the line, and what each costs.” not started
Build · M2
SQLite
Read a real SQLite database by hand — page headers, the B-tree, an indexed query — and predict which storage engine wins a query pattern before benchmarking.
– · 0%
“B-tree vs LSM for this workload: which I’d reach for, and the read/write ratio that flips the call.” not started
Build · M3
HTTP server
Build an HTTP/1.1 server — requests, responses, headers, compression, keep-alive — and reason about encoding and evolution on the wire.
– · 0%
“Versioning an API without breaking last year’s clients — the migration I’d never ship.” not started
Build · M4
DNS server
Build a DNS server — construct and parse the binary packet format, handle name compression, forward queries — and appreciate compact wire encoding.
– · 0%
“Compact binary protocols: where DNS’s choices (name compression, UDP) pay off and where they bite.” not started
Build · M5
Kafka
Build a Kafka broker — the partitioned log, offsets, fetch and produce — and name the consistency model a system needs versus the one it secretly relies on.
– · 0%
“Which consistency model a feature needs — and the one it’s secretly relying on.” not started
“Capstone: a published system-design writeup distilled from these decision logs.” not started
Reading
A Philosophy of Software Design
- 1–3. Complexity & its symptomsthe judgment lens
Designing Data-Intensive Applications
- 1. Reliable, Scalable, Maintainable Applicationsthe rubric for every later call
Foundations
Courses
- Python for Coding Interviews40 lessons·the refresher
- Algorithms & Data Structures for Beginners35 lessons·start it
NeetCode 150, pattern by pattern
- Arrays & Hashing9 problems·begins here
Reading
Designing Data-Intensive Applications
- 3. Storage and Retrievallog-structured hash indexes
- 5. Replication
Operating Systems: Three Easy Pieces
- P1. Persistence — I/O devices & disksalongside RDB/AOF
- P2. Persistence — files & directoriesalongside RDB/AOF
- P3. Persistence — crash consistency (fsck/journaling)alongside RDB/AOF
- P4. Persistence — log-structured file systemsalongside RDB/AOF
- C1. Concurrency — threads & locksalongside replication
- C2. Concurrency — condition variables & semaphoresalongside replication
- C3. Concurrency — common bugs & deadlockalongside replication
A Philosophy of Software Design
- 4–6. Modules should be deeplight read
Foundations
Courses
- Algorithms & Data Structures for Beginners35 lessons·finish it
- Core Skills — implement the data structures20 lessons
NeetCode 150, pattern by pattern
- Arrays & Hashing9 problems·Redis hash store
- Two Pointers5 problems
- Sliding Window6 problems
- Stack7 problems
- Linked List11 problems
Reading
Designing Data-Intensive Applications
- 2. Data Models and Query Languages
- 3. Storage and Retrievaldeep — B-trees vs LSM-trees
Database Internals
- 1. Introduction and Overviewthe exact match for this build
- 2. B-Tree Basics
- 3. File Formats
- 4. Implementing B-Trees
Foundations
NeetCode 150, pattern by pattern
- Binary Search7 problems·SQLite B-tree
- Trees15 problems·SQLite B-tree
- Tries3 problems
Reading
Designing Data-Intensive Applications
- 4. Encoding and EvolutionJSON, Protobuf, Avro, schema migrations
Database Internals
- 5. Transaction Processing and Recoverytrailing read
- 6. B-Tree Variantstrailing read
- 7. Log-Structured Storagetrailing read
A Philosophy of Software Design
- 7–10. Information hiding & general-purpose designlight read
Foundations
NeetCode 150, pattern by pattern
- Heap / Priority Queue7 problems
- Backtracking9 problems
Reading
Designing Data-Intensive Applications
- 6. Partitioningsets up M5
A Philosophy of Software Design
- 11–16. Comments & naminglight read
Foundations
NeetCode 150, pattern by pattern
- Greedy8 problems
- Intervals6 problems
Reading
Designing Data-Intensive Applications
- 7. Transactions
- 8. The Trouble with Distributed Systems
- 9. Consistency and Consensus
Database Internals
- 8. Introduction and Overview (Distributed)the distributed half begins
- 9. Failure Detection
- 10. Leader Election
- 11. Replication and Consistency
- 12. Anti-Entropy and Dissemination
- 13. Distributed Transactions
- 14. Consensus
A Philosophy of Software Design
- 17–21. Consistency, obvious code, trendslight read — finishes the book
Foundations
NeetCode 150, pattern by pattern
- Graphs13 problems·replication & partitioning
- Advanced Graphs6 problems
- 1-D Dynamic Programming12 problems
- 2-D Dynamic Programming11 problems
Reading
Designing Data-Intensive Applications
- 10. Batch Processing
- 11. Stream Processing
- 12. The Future of Data Systemsfinishes DDIA
Foundations
NeetCode 150, pattern by pattern
- Math & Geometry8 problems
- Bit Manipulation7 problems
Courses
- Advanced Algorithms (optional, later)35 lessons
The repeating 2-hour day
Mon–Fri · build days
- 0:00–0:25
- Foundations warm-up — one course lesson early on, then one NeetCode problem in the week's pattern.
- 0:25–1:45
- Build — the current CodeCrafters stage. The anchor; most of the hour goes here.
- 1:45–2:00
- Read — a few pages of the week's anchor chapter; jot one note toward the log.
Saturday · ship day
- 0:00–1:00
- Close the week's build — finish or refactor the current stage; clear anything stuck.
- 1:00–1:30
- Reading catch-up — the “light” book (APoSD, then OSTEP / Database Internals).
- 1:30–2:00
- Write the decision log — the real artifact. This is what turns three tracks into one skill.
How to read this schedule
- It's loose on dates, strict on order. Build hours are CodeCrafters' own estimates — if a stage takes longer, slip the dates and keep the sequence.
- Build is the spine; everything else hangs off it. On any given day, most of the 2 hours is the build.
- Saturday ships the artifact. The decision log is the deliverable. Miss a build stage and recover; don't skip the log.
- Database Internals & OSTEP can trail the build. DDIA and APoSD finish within the 23 weeks; the rest carries past it.
- Foundations is front-loaded. The courses cluster in the ramp and M1, so from SQLite onward more of each day goes to the build.
Retention — spaced review
The other tracks ask "have I done it?" This one asks "do I still know it?" A card enters rotation once its milestone is checked off, then resurfaces on an SM-2 schedule. The count is public; the schedule is private.
Complete a milestone to put its cards in rotation.
Complete a milestone to put its cards in rotation.
All caught up.
Progress is shared — what you see is the live, saved state. The owner can unlock edit mode to check items off.