🛸 Hitchhiker's Guide — Phase 16: Capstone Playbook
Read this if: you're ready to compose the whole track into a system and present it like a principal. This is the playbook for building and defending a capstone.
0. The 30-second mental model
The capstones are the JD's five hard problems, and each is a composition of labs you already built and verified. The work isn't new code — it's the seams: wiring components so all five forces (P00) hold at once, and defending every seam with numbers and ADRs. One sentence: you already built the parts; the capstone is proving you can make them flow correctly under production constraints.
1. The build recipe (every capstone)
1. Draw the lifecycle (P00): creation → ingestion → … → serving → governance → replay → deletion
2. State the FIVE-FORCE numbers: correctness guarantee, p99 latency, peak throughput, $/unit, who operates it
3. Map each box to a phase/lab (the README tables do this)
4. Define ACCEPTANCE = correctness properties (replay/dup tests) + SLOs
5. Write the key ADRs (P15): every tool choice = a dial named + deciding factor
6. Build a thin end-to-end SLICE (Docker-real engines), spec the rest
2. The five capstones, one line each
1. Global ingestion : Kafka/Protobuf/Flink → Iceberg → Athena, multi-region, exactly-once, cost/team
2. Fraud streaming : event-time + sessions + Cassandra enrichment + broadcast rules + savepoint deploys
3. Lakehouse migration: Hive/Tez/Flume → Iceberg/Flink/Athena via dual-write→validate→cutover→decommission
4. Cassandra serving : feature store, partition/TTL/consistency design, Flink upserts + rate-limited backfill
5. Governance : registry + PII + lineage + quality + certification + compliant erasure
6. THE platform : compose 1–5 into one unified (Kappa) platform
3. The seams that break (where principals earn it)
ingestion → processing : processing-time logic double-counts on replay (use event-time, P01)
processing → lakehouse : non-2PC sink duplicates on recovery (exactly-once sink, P04)
lakehouse → query : small files / no sort → scan-cost explosion (compact + Z-order, P08/09)
stream → serving : unthrottled backfill blows read SLO (rate-limit, P11)
delete → compliance : DELETE without snapshot expiry resurrects PII (P09/P14)
schema change → consumers: no CI gate → breaks downstream (compatibility gate, P03)
4. Acceptance properties to always test
replay/dup test: shuffled + duplicated input → identical output (exactly-once effect, P01)
parity (migration): legacy vs new data-diff = 0 before cutover (P13/P15)
checkpoint recovery: restore mid-stream → continue identically (P04)
read SLO under load: p99 within target with concurrent backfill (P11)
breaking change blocked in CI (P03) ; PII masked + audited (P14)
5. Presenting it (Round 1 + Round 5)
to engineers: the architecture, the dials, the failure modes, the rollback
to leadership: cost / risk / time / reliability (NOT Flink internals) — P15
the deck: lifecycle diagram + five-force numbers + ADRs + acceptance criteria + runbook + cost model
6. Beginner mistakes that mark you
- Designing without numbers (no SLO, no peak, no $).
- Ignoring the seams (each component "works" but the system double-counts/leaks).
- Big-bang migration with no parity/rollback (P15).
- No exactly-once at the external sink (P04/P09/P11).
- No cost model / no per-team attribution.
- No rollback / no runbook (P13).
7. What "done" looks like
one capstone BUILT end-to-end (verified seams), four SPEC'd (architecture + ADRs + acceptance)
five-force numbers + dials per capstone
runbook + cost model for the built one
Capstone 6 architecture doc = the unified platform (the JD's mission)
Build one for real. Spec the rest. Then read the Brother Talk, and go interview — you've done the whole lifecycle.