</> MAANG.io
system design · 301

Advanced

Master system design interviews with scalable architecture patterns, distributed systems, and real-world design challenges.

0/480 solved 0% complete

Section 4: Declare It, Don't Command It - API Design (with Pushback)

Executive Summary: The deploy system has four contracts. CI registers an immutable release by digest and, on merge, starts a rollout that runs for hours. Humans steer it with pause, resume, rollback and freeze. And 100,000 host agents watch for their desired state and report what they actually run. Every contract is declarative and idempotent, because callers retry, operations outlive any HTTP request, and two people can act on the same rollout within seconds. The interviewer pushes on five shapes: who registers the release, mutable tags, the 202, If-Match on resume, and pull versus push.

The interviewer nods at the Section 3 numbers. "Small control plane, fine. Show me the interfaces."

You: "Four callers with very different needs: CI, engineers, on-call humans, and an agent on every host. I'll take them in the order Sam's release r-1432 meets them."

Sequence diagram: CI posts release with digest and signature to the Deploy API (201 release r-1432), then posts a rollout of r-1432 on the standard plan (202 with rollout id); the orchestrator writes desired digest and new generation to the desired-state store, which sends a watch event to the host agent; the agent fetches, verifies, drains and restarts, then reports status with generation_seen and health; the orchestrator reads actual state (batch converged) and Sam GETs the rollout for stage and gate evidence

Releases: Registered Once, by Digest

When CI finishes building commit a1b2c3d, it registers the result:

POST /v1/services/checkout-api/releases
{
  "digest": "sha256:9f4e…",
  "commit": "a1b2c3d",
  "provenance": { "builder": "ci", "source": "checkout-api@a1b2c3d" },
  "signature": "<CI signature over digest and provenance>"
}
→ 201 Created
{ "release_id": "r-1432", "status": "candidate" }

There is no PUT or PATCH. The digest, commit and provenance never change; only the system moves the status (candidate, deployed, bad). A retried POST with the same digest returns the existing release, so CI can retry freely.

Interviewer: "Why does CI register it? The deploy system could build from the commit itself."

You: "Then the bytes we canary aren't provably the bytes we ship. We build once and promote that same digest through every stage. A rebuild per environment can pick up a different base image or dependency, and then the canary tested something else. It also keeps the signature meaningful: CI signs what it built and tested, and agents refuse anything unsigned (Section 10 covers that chain)."

Interviewer: "Can I deploy checkout-api:latest?"

You: "No. The API takes release IDs, and each maps to one digest. The CLI may resolve a tag for convenience, but it sends the digest it resolved, and the digest is what gets audited. A tag that moves between the canary and region C means different hosts ran different code under one name." This choice never flips.

Quick check before moving on:


Sign in to continue reading

The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.

Sign in to read the full lesson

Sign in to MAANG.io

Use your Google or Microsoft account — no password to remember.

Continue with Google Continue with Microsoft

Please accept the terms above to continue.