Phase 7 — Architect Interview Playbook

A Software Architect loop is not a senior-engineer loop with bigger numbers. The bar is judgment and leverage: can you make a cross-cutting decision, defend its trade-offs with data, write it down, and get many teams to adopt it? The rounds usually are:

1. System design at scale — "design a platform/service for X." They probe boundaries, contracts, data, failure, and evolution.
2. A deep architecture trade-off — "sync vs async here? strong vs eventual? build vs buy?" They want the reasoning, not the answer.
3. Architecture review of an existing/your design — find the risks, the coupling, the failure modes; propose the migration.
4. Behavioral / leadership — driving consensus, mentoring, owning a decision that was wrong, influencing without authority.
5. (sometimes) a coding/contract screen — an API/schema/idempotency problem.

1. The platform system-design playbook

Architect design questions reward structure + trade-off ownership. Use this spine.

Step 0 — Clarify the "-ilities" and the scale, out loud

Before drawing anything: "What are we optimizing — latency, throughput, consistency, cost, dev velocity? What's the scale (RPS, data size, teams, event rate)? What's the consistency requirement, and what can be eventual?" Architecture is prioritizing the -ilities; naming them first is the highest-signal move.

Step 1 — Decompose by bounded context, not by noun

Draw services along bounded contexts (cohesive business capabilities), not data tables. State the boundary criteria: high cohesion inside, loose coupling across, independent deployability, a team that can own it. Call out the distributed-monolith anti-pattern explicitly: services that must deploy together, share a DB, or chat synchronously per request are a monolith with network latency added. (pa-01)

Step 2 — Define the contracts and the communication style

For each edge, choose sync (request/reply) vs async (events) and justify it:

sync (REST/gRPC):  need an immediate answer; caller can't proceed without it.
                   cost: temporal coupling, cascading failure, you own the latency budget.
async (events):    fire-and-forget / fan-out / decoupling / load-leveling / audit.
                   cost: eventual consistency, ordering, idempotency, harder to reason about.

Name the API contract (REST resource + idempotency keys; gRPC/proto with backward-compat rules; or an event schema in a registry) and how it versions without breaking consumers. (pa-02, pa-03)

Step 3 — Data: partitioning, consistency, and the dual-write trap

State the partitioning strategy (hash / range / consistent hashing) and why; the replication + consistency model (linearizable? causal? read-your-writes? eventual?) per data set, justified by the -ilities; and how you avoid the dual-write problem when you must update a DB and publish an event — the transactional outbox, not a best-effort publish. For cross-service workflows, a saga with compensations, not a distributed 2PC. (pa-04, pa-05, pa-06)

Step 4 — Failure, reliability, and the SLO

Volunteer the failure modes and the budget: timeouts, retries with budgets + jitter, circuit breakers, bulkheads, backpressure, load shedding, graceful degradation. Frame reliability as an SLO + error budget (not "five nines everywhere") and say what degrades first. (pa-09, gw-06)

Step 5 — Ship it: IaC, GitOps, progressive delivery

"Infrastructure is declarative (Terraform/Pulumi), deployed via GitOps (git as source of truth, a reconciler that syncs + self-heals + prunes), with progressive delivery (canary/blue-green) gated on SLOs and automatic rollback." (pa-07, pa-08, gw-12)

Step 6 — Close with evolution

"I'd encode the key constraints as fitness functions (automated architecture tests — no dependency cycles, layering rules, contract compat in CI) so the design stays coherent as it grows, and capture the decision in an ADR." (pa-10)

The canonical questions, pre-solved

2. The trade-off round (where architects are made)

They'll push on one decision. Win by showing the decision framework, not a memorized answer:

• State the forces (the -ilities in tension).
• Give 2–3 options with their costs, including the one you reject and why.
• Recommend, tie it to the stated priorities, and name what would change your mind (the "we'd revisit if…").

Have crisp positions on: sync vs async (temporal coupling vs eventual consistency), strong vs eventual consistency (CAP/PACELC, per dataset), orchestration vs choreography (a central saga vs emergent events — visibility vs coupling), build vs buy, shared library vs shared service (deploy coupling vs network coupling), and monorepo vs polyrepo. Each lab's docs/analysis.md is a model of this "tradeoffs worth flagging" thinking.

3. The architecture-review round

Given a design, find: synchronous call chains that cascade (no bulkhead/breaker), dual writes, shared databases across services, missing idempotency, unbounded retries, ordering assumptions on a partitioned log, a single consistency model forced on everything, and no rollback path. Then propose an incremental migration (strangler-fig, outbox-then-cutover) — never a big-bang rewrite (gw-12).

4. Behavioral / leadership (the architect differentiators)

Prepare stories tagged to these — Apple and any architect loop probe them:

5. The 30-60-90 (say this if asked)

• 0–30 — Map the terrain. Read the top services, their contracts, and the data/event flows; draw the real (not the wiki) architecture; meet the teams and learn their pain. Ship one small paved-road improvement to earn trust.
• 30–60 — Pick a high-leverage problem. Write the ADR for one cross-cutting decision (e.g., the eventing standard, the service-contract policy, the SLO framework); socialize it in design review; prototype it.
• 60–90 — Land it and templatize. Ship the pattern as a paved road + a fitness function in CI so it spreads without you; show a before/after metric (velocity, incident rate, or a killed service). Mentor an engineer to own the next slice.

Thread: reduce coupling, increase leverage, leave the architecture more evolvable and better-documented than you found it.

6. Questions to ask them (architect-grade)

• "Where is the architecture today vs where you want it — and what's the biggest source of cross-team coupling or 'distributed monolith' pain?"
• "How are service contracts governed and evolved — schema registry, compat checks in CI, or convention?"
• "What's the eventing/streaming backbone, and how do you handle the dual-write problem and exactly-once expectations?"
• "How do platform changes ship — IaC + GitOps + progressive delivery — and how mature is rollback/SLO-gating?"
• "How does an architect actually drive a decision here — ADRs, an architecture council, RFCs? How is consensus reached and recorded?"
• "What's the hardest distributed-systems trade-off the team is living with right now?" (Their answer is your future work.)

7. One-page cheat sheet

-ILITIES FIRST — name what you're optimizing + the scale, before drawing.
BOUNDED CONTEXTS — decompose by capability; beware the distributed monolith.
SYNC vs ASYNC — immediate answer vs decoupling; own the cost of each.
CONTRACTS — REST+idempotency / gRPC+proto-compat / event schema+registry; version safely.
DATA — partition (hash/range/consistent-hash) + consistency PER dataset (CAP/PACELC).
DUAL WRITE — transactional outbox, not best-effort publish. Cross-service = saga, not 2PC.
DELIVERY — at-least-once + idempotent consumers; ordering only within a partition; DLQ.
RELIABILITY — SLO + error budget; timeouts/retries+budget+jitter; breakers; bulkheads; shed.
SHIP — IaC (declarative) + GitOps (reconcile/self-heal) + progressive delivery (SLO-gated rollback).
EVOLUTION — ADRs for the why; fitness functions in CI; paved roads; build consensus, don't gatekeep.