Sean Campbell

A learning roadmap · in progress

Building engineering judgment

Follow along with what I'm doing and the resources I'm using to become better at decision making & problem solving as a Software Engineer. Building everything out in the open for anyone to see.

Week 1 of 22

Redis — how bytes become a database

M1 · Storage Weeks 1–7 · Sep 7 – Oct 24

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
  1. W0 Phase 0 · ramp –
  2. W1–7 M1 · Storage –
  3. W8–9 M2 · Engines –
  4. W10–12 M3 · Encoding –
  5. W13–14 M4 · The packet –
  6. W15–19 M5 · Consensus –
  7. W20–22 Capstone –
Build 0/98 stages · 0/5 courses · 0/8 logs
Reading 0/38 chapters · 0/4 books
Foundations 0/22 items

Build

CodeCrafters, in order
  1. Redis 0 of 4 checkpoints , in progress
  2. SQLite 0 of 1 checkpoint , planned
  3. HTTP server 0 of 3 checkpoints , planned
  4. DNS server 0 of 1 checkpoint , planned
  5. Kafka 0 of 5 checkpoints , planned

Reading

anchor + light
  1. Designing Data-Intensive Applications 0 of 12 chapters , in progress
  2. A Philosophy of Software Design 0 of 5 chapters , in progress
  3. Operating Systems: Three Easy Pieces 0 of 7 chapters , in progress
  4. Database Internals 0 of 14 chapters , planned

Foundations

NeetCode
  1. NeetCode 150, pattern by pattern 0 of 18 done , in progress
  2. Courses 0 of 4 done , in progress
now
  1. Designing Data-Intensive Applications 0 of 12 chapters , in progress
  2. A Philosophy of Software Design 0 of 5 chapters , in progress
  3. Courses 0 of 4 done , in progress
  4. NeetCode 150, pattern by pattern 0 of 18 done , in progress
  5. Redis 0 of 4 checkpoints , in progress
  6. Operating Systems: Three Easy Pieces 0 of 7 chapters , in progress
  7. now · Sep 10, 2026
  8. SQLite 0 of 1 checkpoint , planned
  9. Database Internals 0 of 14 chapters , planned
  10. HTTP server 0 of 3 checkpoints , planned
  11. DNS server 0 of 1 checkpoint , planned
  12. Kafka 0 of 5 checkpoints , planned

Build, in progress · 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%

Reading · M1 · Storage

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 · M1 · Storage

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
“RESP vs JSON for a wire protocol: what Redis traded away, and the workload where I’d make the opposite call.” not started
1Prediction — before you read the answer
2Confrontation — after the build
“RDB vs AOF: the durability/latency/recovery trade I’d default to, and the workload that flips it.” not started
1Prediction — before you read the answer
2Confrontation — after the build
“Single-leader vs multi-leader: where I draw the line, and what each costs.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · 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%

Reading · M2 · Engines

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 · M2 · Engines

NeetCode 150, pattern by pattern

  • Binary Search7 problems·SQLite B-tree
  • Trees15 problems·SQLite B-tree
  • Tries3 problems
“B-tree vs LSM for this workload: which I’d reach for, and the read/write ratio that flips the call.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · 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%

Reading · M3 · Encoding

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 · M3 · Encoding

NeetCode 150, pattern by pattern

  • Heap / Priority Queue7 problems
  • Backtracking9 problems
“Versioning an API without breaking last year’s clients — the migration I’d never ship.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · 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%

Reading · M4 · The packet

Designing Data-Intensive Applications

  • 6. Partitioningsets up M5

A Philosophy of Software Design

  • 11–16. Comments & naminglight read

Foundations · M4 · The packet

NeetCode 150, pattern by pattern

  • Greedy8 problems
  • Intervals6 problems
“Compact binary protocols: where DNS’s choices (name compression, UDP) pay off and where they bite.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Build, planned · 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%

Reading · M5 · Consensus

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 · M5 · Consensus

NeetCode 150, pattern by pattern

  • Graphs13 problems·replication & partitioning
  • Advanced Graphs6 problems
  • 1-D Dynamic Programming12 problems
  • 2-D Dynamic Programming11 problems

Reading · Capstone

Designing Data-Intensive Applications

  • 10. Batch Processing
  • 11. Stream Processing
  • 12. The Future of Data Systemsfinishes DDIA

Foundations · Capstone

NeetCode 150, pattern by pattern

  • Math & Geometry8 problems
  • Bit Manipulation7 problems

Courses

  • Advanced Algorithms (optional, later)35 lessons
“Which consistency model a feature needs — and the one it’s secretly relying on.” not started
1Prediction — before you read the answer
2Confrontation — after the build
“Capstone: a published system-design writeup distilled from these decision logs.” not started
1Prediction — before you read the answer
2Confrontation — after the build

Close

Reading, in progress

Designing Data-Intensive Applications

Martin Kleppmann

– · 0/12

Close

Reading, planned

Database Internals

Alex Petrov

– · 0/14

Close

Reading, in progress

Operating Systems: Three Easy Pieces free

Remzi & Andrea Arpaci-Dusseau — Concurrency + Persistence parts only

– · 0/7

Close

Reading, in progress

A Philosophy of Software Design

John Ousterhout

– · 0/5

Close

Foundations, in progress

Courses

–

Close

Foundations, in progress

NeetCode 150, pattern by pattern

–

Close

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.

0 cards in rotation · 28 authored
Build 0 Reading 0 Foundations 0 Judgment 0 Behavioral 0

Progress is shared — what you see is the live, saved state. The owner can unlock edit mode to check items off.

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.