Deliverables

The curriculum covers what an architect should know. This covers what an architect actually hands over: 55 artifacts, each with a worked example, a note on when it is worth producing, who reads it, and the ways it usually goes wrong. Filter by the artifact's type, the kind of engagement that calls for it, the stack or industry it is drawn against, or the audience it is written for.

Identify the deliverable → 42 diagrams, shown one at a time with the answer withheld. Nothing to submit.

4 of 55 deliverables shown.

flowchart LR
  commit(["commit to main"]) --> build

  subgraph ci["Continuous Integration"]
    direction TB
    build["build<br/><i>pinned deps, hermetic</i>"]
    unit["unit tests<br/><i>&lt; 4 min</i>"]
    scan["SAST + dependency<br/>+ secret scan"]
    sign["sign artifact<br/>+ emit SBOM"]
    build --> unit --> scan --> sign
  end

  sign --> reg[("artifact registry<br/><i>immutable, digest-addressed</i>")]

  subgraph cd["Continuous Delivery"]
    direction TB
    dev["deploy dev<br/><i>auto</i>"]
    ctest["contract tests"]
    stage["deploy staging<br/><i>auto</i>"]
    nft["performance +<br/>resilience suite"]
    dev --> ctest --> stage --> nft
  end

  reg --> dev
  nft --> gate{"release gate<br/><i>automated checks +<br/>change record</i>"}
  gate -->|"pass"| canary["canary 5%<br/><i>15 min bake</i>"]
  gate -->|"fail"| stop(["blocked"])
  canary --> analyse{"error rate and<br/>latency within SLO?"}
  analyse -->|"yes"| full["progressive rollout<br/><i>25% → 50% → 100%</i>"]
  analyse -->|"no"| rollback(["automatic rollback"])

Behavioural View

CI/CD Pipeline Diagram

The path from commit to production as ordered stages, showing what each one proves, what it produces, and where a human is still in the loop.

Pipeline Architecture Build

flowchart TB
  subgraph prod["Cluster: prod-eu (regional, 3 AZ)"]
    direction TB
    cp["Control plane<br/><i>managed · private endpoint</i>"]
    subgraph pools["Node pools"]
      direction LR
      np1["system<br/><i>taint: CriticalAddonsOnly</i>"]
      np2["general<br/><i>3–30 nodes · spot 40%</i>"]
      np3["memory<br/><i>taint: workload=memory</i>"]
      np4["gpu<br/><i>taint: workload=gpu</i>"]
    end
    subgraph ns["Namespaces"]
      direction LR
      n1["team-orders<br/><i>quota · NetworkPolicy<br/>default-deny</i>"]
      n2["team-pricing<br/><i>quota · NetworkPolicy</i>"]
      n3["platform<br/><i>mesh · ingress · logging</i>"]
    end
    cp --- pools
    pools --- ns
  end
  subgraph nonprod["Cluster: nonprod-eu"]
    direction TB
    x1["shared node pool<br/><i>spot 90%</i>"]
  end
  reg[("Image registry<br/><i>signed images only</i>")] --> prod
  reg --> nonprod
  gitops["GitOps reconciler"] -.->|"applies desired state"| prod

Deployment & Infrastructure View

Kubernetes Cluster Topology

How many clusters, split by what, which node pools exist and what isolates one tenant from another.

Cluster Architecture Design

sequenceDiagram
  autonumber
  participant B as Browser
  participant A as App / BFF
  participant I as Identity Provider
  participant R as Resource API

  B->>A: GET /protected
  A-->>B: 302 to IdP (PKCE challenge, state, nonce)
  B->>I: authorise request
  I->>B: authenticate + MFA
  I-->>B: 302 back with authorisation code
  B->>A: code + state
  Note over A,I: back channel — browser never sees these
  A->>I: exchange code + PKCE verifier + client secret
  I-->>A: access token (10 min), refresh token, id token
  A->>A: store tokens server-side<br/>set HttpOnly SameSite cookie
  A-->>B: session cookie only
  B->>A: subsequent request + cookie
  A->>R: call with access token (Bearer)
  R->>I: fetch/refresh signing keys (JWKS, cached)
  R->>R: verify signature, issuer, audience,<br/>expiry, scope
  R-->>A: 200
  A-->>B: rendered response
  Note over A,I: on expiry the BFF refreshes<br/>with rotating refresh token

Security View

Authentication Flow Diagram

The exact token exchange between browser, application, authorisation server and API — including what is short-lived, what is bound and what never touches the browser.

Secure API Design Design

flowchart LR
  user(["Customer<br/><i>untrusted</i>"])
  admin(["Admin<br/><i>privileged</i>"])

  subgraph edge["Boundary 1 — public edge"]
    cdn["CDN / WAF"]
  end

  subgraph app["Boundary 2 — application tier"]
    direction TB
    api["Order API"]
    auth["Auth Service"]
  end

  subgraph datab["Boundary 3 — data tier"]
    direction TB
    db[("Order Store<br/><i>PII + card token</i>")]
    kms[("Key Vault")]
  end

  ext["Payment Provider<br/><i>third party</i>"]

  user -->|"F1 HTTPS"| cdn
  cdn -->|"F2 HTTPS + mTLS"| api
  admin -->|"F3 admin console"| api
  api -->|"F4 token introspection"| auth
  api -->|"F5 TLS + parameterised"| db
  api -->|"F6 fetch DEK"| kms
  api -->|"F7 HTTPS outbound"| ext
  ext -->|"F8 webhook — signed"| cdn

Security View

Threat Model Data Flow Diagram

Processes, stores and flows with trust boundaries drawn across them, so that every boundary crossing can be enumerated for threats.

Threat Modelling Design