Phase 6 — Production Systems (M9–M11, W37–W44)¶

You have crossed a line. Phases 0 through 5 taught you a language, a discipline, and a technical vocabulary. Phase 6 teaches you the thing that separates “person who knows C++” from “person a company will pay $$$ to ship C++ into production.” That thing is not more syntax. It is the operational stack around your code: how it talks to other services, how it is observed, how it is measured under load, how it is squeezed for the last 3ms, and how it survives a bad Tuesday.

Thesis: learning is over — this is shipping-grade¶

Everything from here forward is about evidence you can point to. When a hiring manager at a serious C++/ML shop asks you “have you shipped this?”, you now start answering yes, and you can hand them a URL, a Grafana screenshot, a k6 report, a blog post with before/after flamegraphs. This is the phase where the roadmap stops being education and starts being a portfolio factory. Treat every artifact this phase produces as public and permanent.

The four skills you build in Phase 6 — RPC, observability, profiling, and low-level tuning — are the four things applied ML infrastructure engineers do all day. You are done copying tutorials. You are learning to instrument, measure, and defend performance claims.

What you build (W37–W44)¶

Week	Focus	Deliverable
W37	gRPC + Protobuf, unary + streaming	Working echo + streaming service, TLS wired
W38	HTTP layer, JSON, WebSockets	REST facade around the gRPC service
W39	Logging + metrics + tracing	spdlog + prometheus-cpp + OTel exporter wired
W40	P6.1 — gRPC ML inference service	ONNX model served over gRPC, TLS, load-tested
W41	Profiling: perf, Tracy, Instruments, flamegraphs	Slow function found and fixed in P6.1
W42	P6.2 — Full observability harness	Grafana + Jaeger + Prom stack, 3 dashboards live
W43	Allocators, compiler flags, PGO/LTO	Rebuild P6.1 with tuned allocator + PGO
W44	P6.3 — Profiling case study blog post	Public post, before/after numbers, >2x speedup

Exit criteria (all 15 must be true at W44 checkpoint)¶

A gRPC C++ service (P6.1) is running on a public Linux VM you can curl from anywhere.
That service serves an ONNX model behind unary AND bidi-streaming RPCs.
It advertises a Prometheus /metrics endpoint with at least request-count, latency histogram, and per-model gauge.
It exports OTLP traces to a Jaeger or Grafana Tempo instance you can screenshot.
It is TLS-terminated, not plaintext.
It handles deadlines and returns DEADLINE_EXCEEDED correctly when the client cancels.
You have a k6 or ghz load test in the repo showing p50/p95/p99 at concurrencies 1, 8, 32, 128.
You have run perf record (or Instruments on Mac) at least once against P6.1 and can read the report.
You have generated at least one flamegraph and stored it in the repo.
You have compared jemalloc vs mimalloc vs system malloc on your workload and picked one with numbers.
You have rebuilt P6.1 with -flto=thin and at least attempted PGO; you know whether it helped.
Your code has spdlog async logging with rotating file sink and structured (JSON) output.
You have written at least one blog post (P6.3) with real before/after profile data, published publicly.
You know what “at-least-once” vs “exactly-once” means and which one your service provides.
You can explain, in one paragraph, why your service tail latency looks the way it does.

If any of the above is a “no” at W44, extend Phase 6 by up to 2 weeks. Do not roll unfinished infrastructure into Phase 7 — capstones need this foundation solid.

What most people get wrong in “production C++”¶

Three lies you will be tempted to believe. Kill each one now.

Lie 1: “Performance = -O3.” No. Performance is a loop: hypothesize → measure → change → re-measure → keep or revert. -O3 is a starting flag, not an optimization. Engineers who confuse the compiler flag with the discipline never break p99. The discipline is what makes you rare.

Lie 2: “Async gRPC is optional.” For toy code, sure. For anything a company would pay for, no. The synchronous gRPC C++ API burns a thread per in-flight RPC and falls over at four-digit QPS. Every serious C++ gRPC production service uses CompletionQueue or the newer callback API. Learn it in W37 and never look back.

Lie 3: “Observability is a Kubernetes thing.” Metrics, traces, and structured logs are code concerns. Grafana just draws pictures. If your binary does not emit histograms and spans, no orchestrator will save you. Wire observability in from day one of P6.1, not “later.”

The mental shift this phase demands¶

Phases 1–5, you were an author. You wrote code and read code. Phase 6, you become an operator. You now care about:

What your service does at 3am under load you didn’t plan for.
How much memory it holds after 24 hours of uptime.
Whether a single slow downstream call takes the whole pool down.
Whether your p99 is 5x your p50 (bad) or 1.3x your p50 (good).
What your binary looks like in perf report — not what it looks like in your editor.

If Phase 5 asked “does it run?”, Phase 6 asks “does it run well, forever, under attack, and while I sleep?” Different question. Different answers.

Time budget: 10–15 hrs/week¶

Rough weekly split for this phase:

6 hrs — hands-on building (services, dashboards, benchmarks)
3 hrs — reading + docs (gRPC internals, prometheus best practices, one perf paper)
2 hrs — writing (README updates, the P6.3 blog post, git commits with real messages)
1–4 hrs — buffer for the debugging you did not plan for, because production teaches you

Do not skip the writing. The blog post is not vanity — it is the artifact that converts your Phase 6 hours into hireable signal.

Files in this phase¶

01_grpc_and_protobuf.md — the RPC layer.
02_http_and_web_services.md — REST/WebSocket surface.
03_logging_metrics_tracing.md — the three pillars.
04_profiling_and_perf.md — read this twice; it is the file that differentiates you.
05_allocators_and_memory.md — where malloc time goes.
06_compiler_and_optimization.md — LTO, PGO, -march=native.
07_distributed_basics_for_cpp_engineer.md — the 20% of distributed that matters at your level.
projects.md — P6.1, P6.2, P6.3 specifications.