Part 11 · Hands-On — Ship It

Ten Parts of theory. Now we spend one Part making it real on a single, small, completely ordinary service — and watch every idea from the book click into place around it.

The service is Snip, a URL shortener. It is the one we designed in the sibling System Design · First Principles book: a small HTTP API that takes a long URL, stores a short code → URL mapping in Postgres, caches hot lookups in Redis, and redirects. Two endpoints — POST /shorten to create a code and GET /:code to redirect — plus a /healthz and a /metrics. That is the entire app. We deliberately picked something boring, because the point of this Part is not the app. The point is everything around the app: the path a change takes from a developer’s keyboard to a user’s browser, and every place that path could have been a manual, error-prone step.

The goal of this Part is one sentence: one commit reaches production safely, automatically, and observably.

• Safely — a broken change is stopped before users see it, and if one slips through, the blast radius is tiny and the rollback is one action.
• Automatically — no human SSHes anywhere, builds anything by hand, or runs kubectl apply against prod. The pipeline does the same thing every time.
• Observably — when the change is live, you can see whether it’s healthy, on real signals, in seconds — not guess.

Each of those three words is a Part of this book made concrete. This capstone is the recurring thread of the whole book — what manual, error-prone step does this remove, and how does it make production safer? — applied end to end, to one service, with copy-pasteable config at every step.

   commit ─► CI: build · test · scan · sign ─► image in registry
                                                     │
                                                     ▼
   GitOps repo (desired state in git) ◄── bump image tag ── pipeline
        │
        ▼
   Argo CD reconciles ─► Kubernetes ─► canary 10% → 50% → 100%
                                          │
                                          ├─ metrics healthy? promote
                                          └─ metrics bad?    auto-rollback

Nothing in that diagram is new. Every box was taught in an earlier Part; here we wire them together.

Roadmap for this Part

Read these in order — they are the steps a single commit takes, start to finish.

#	Page	What it ships	Draws on
2	The Plan: Commit → Production	The full pipeline on one page, with target DORA metrics	DORA, CI/CD
3	Containerize the App	A small, non-root, multi-stage Dockerfile for Snip	Dockerfiles, Images & Layers
4	The CI Pipeline	A complete GitHub Actions workflow: build, test, scan, sign	Pipelines, Scanning
5	The Observability Stack	Metrics, logs, traces, a ServiceMonitor, an alert	Metrics, Three Pillars
6	Canary Deploy	An Argo Rollout that auto-promotes or auto-rolls-back on SLOs	Deployment Strategies, Argo CD
7	Where to Go Next	The journey recapped, what’s omitted, and where to study next	Platform Engineering

By the end you will have, in front of you, the actual files that take Snip from commit to production — and you will be able to point at any one of them and say which manual step it killed and which kind of outage it prevents.

The first job is to draw the whole pipeline before we build any piece of it, so every later page has a map to slot into: The Plan: Commit → Production.

Check your understanding

1. The goal of this Part has three adverbs — safely, automatically, observably. What does each one concretely mean for a single commit reaching production?
2. Why does the Part deliberately choose a “boring” service like a URL shortener instead of something complex?
3. Snip has two data stores, Postgres and Redis. What role does each play, and which one is the source of truth for the short-code mapping?
4. The roadmap maps each step to earlier Parts. Pick any one step and name the Part it draws on and the manual step it removes.
5. Using the book’s recurring thread, restate the whole capstone goal in one sentence.

Show answers

1. Safely = a bad change is stopped before users see it, and any that slips through has a tiny blast radius and one-action rollback. Automatically = no human SSHes, hand-builds, or runs kubectl against prod; the pipeline is identical every run. Observably = once live, health is visible on real signals in seconds, not inferred.
2. Because the app is not the lesson — the path around it is. A boring, well-understood service lets all the attention go to the pipeline, the safety gates, and the observability, instead of the business logic.
3. Postgres holds the durable, authoritative short-code → URL mapping (the source of truth); Redis is a cache that speeds up hot lookups but can be rebuilt from Postgres at any time.
4. Example: Containerize the App draws on Containers; it removes the manual, per-machine “build it on my laptop and hope it runs the same in prod” step by freezing the runtime into an image. (Any roadmap row’s answer is acceptable.)
5. One commit reaches production safely, automatically, and observably — every step replacing a manual, error-prone action with an automated one that makes production safer.