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.
M1 Storage — how bytes become a database
defend choosing an in-memory store over disk, and name exactly when that choice breaks.
0% +
W1 A server that speaks a protocol
By Sunday you can open a raw TCP socket, parse a wire protocol by hand, and explain why Redis chose RESP over JSON.
Build Your Own Redis — stages 1–4
Bind a TCP listener, accept connections, parse the RESP protocol, answer PING / ECHO.
codecrafters.io · Redis track
DDIA — Ch. 1
Reliability, scalability, maintainability — the rubric every later decision is graded against.
NeetCode — Arrays & Hashing
15 min daily. The hash map you reach for here is the same structure the store is built on.
Daily rhythm
One entry, ~150 words, tagged for retrieval. This is the part that turns hours into transferable judgment — and the seed of a blog post.
“RESP vs JSON for a wire protocol: what Redis traded away, and the workload where I’d make the opposite call.”
W2 An in-memory store with expiry
By Sunday you can reason about why a hash index is O(1) and what it costs you in memory and durability.
Redis — SET / GET / TTL stages
Back the store with a hash map; add key expiry and the passive/active expiry choice.
codecrafters.io · Redis track
DDIA — Ch. 3, hash indexes
Why the log-structured hash index works, and the moment it stops scaling.
NeetCode — Two Pointers
15 min daily.
Daily rhythm
“In-memory vs durable: the actual failure I’m accepting when I keep state in RAM.”
W3 Indexes & retrieval
Build secondary lookups; read DDIA Ch.3 on B-trees vs LSM as a preview of M2. (Weeks expand into the same Build / Systems / Foundations / Decision-log shape.)
W4 Persistence — RDB & AOF
Add snapshotting and an append-only log; the capstone decision log compares the two durability strategies.
M2 Storage engines — B-trees vs LSM
read a query pattern and predict which engine wins, before you benchmark.
0% +
Build Your Own SQLite
Read the real file format, walk the B-tree, run an indexed query.
DDIA Ch. 3 (deep) + Ch. 2
B-trees vs LSM-trees; relational vs document vs graph models.
Binary Search · Trees · Tries
“The workload decides the engine” — map read/write ratios to B-tree vs LSM.
M3 Encoding & the wire
version an API without breaking last year’s clients.
0% +
HTTP server + DNS server
Two CodeCrafters tracks — request/response, then resolution and caching.
DDIA Ch. 4
Encoding & evolution: JSON, Protobuf, Avro, schema migrations.
Stack · Linked List · Sliding Window
“The migration I’d never ship.”
M4 Distribution — replication & partitioning
place data and pick a leader strategy under a real failure model.
0% +
Redis replication stages
Leader/follower handshake, command propagation.
DDIA Ch. 5 + Ch. 6
Replication and partitioning.
Graphs · Heaps
“Single-leader vs multi-leader: where I draw the line.”
M5 Consistency & consensus
name the consistency model a feature needs — and the one it’s secretly relying on.
0% +
Build Your Own Kafka
Partitioned log, offsets, ordering guarantees.
DDIA Ch. 7 · 8 · 9
Transactions, the trouble with distributed systems, consensus.
Dynamic Programming · Intervals
“Which consistency model, and what it costs.”
M6 Systems in the wild — batch, streams & a real design
take a project you already shipped and write the design doc it deserved.
0% +
Finish Kafka → apply it for real
Retrofit a streaming or batch component onto Songle or Roaming.Camp.
DDIA Ch. 10 · 11 · 12
Batch, stream, and the closing synthesis.
Graphs (advanced) · Backtracking · mixed review
Capstone — a published system-design writeup distilled from the decision logs (ties into the blog).
Progress is shared — what you see is the live, saved state. The owner can unlock edit mode to check items off.