Google Cloud / Advanced: Governance, Reliability, and Architecture / Lesson 18
Architecture Decisions and Validation Boundaries
Choose service patterns from requirements and document alternatives, tradeoffs, ownership, and evidence still needed.
On this page
Lesson goals
- Compare execution, state, identity, and operational requirements.
- Separate requirement fit from weighted preferences.
- Create a reviewable decision record and migration plan.
A service name is not a complete architecture
Begin with user operations, data semantics, load shape, latency, failure targets, security boundaries, cost ownership, and team capability. Compute Engine can suit required OS control; Cloud Run can suit supported managed execution patterns; Cloud SQL supplies relational behavior; Cloud Storage supplies object behavior; Pub/Sub decouples delivery under its contract. None is a universal default for every workload.
An application usually combines services, so the interfaces matter more than a product list. Record identity, network path, state ownership, timeout/retry, schema, and observability at each boundary. A diagram that omits a required key, database, or operator can hide the most important failure dependency.
Check hard requirements before preference scores
The first offline example selects candidates from an invented capability matrix when OS control is a hard requirement. It is not a current product feature database. A real comparison must verify supported features, execution environments, region/edition availability, and operating constraints in current official documentation. A high preference score cannot compensate for a violated mandatory requirement.
After screening, compare tradeoffs transparently: operational burden, deployment speed, state model, portability needs, scaling behavior, and recovery complexity. Weights represent stakeholder judgments, not objective cloud truth. Preserve alternatives and sensitivity when a small weight change reverses the choice.
requirements = {"os_control": True}
candidates = [{"name": "vm-pattern", "os_control": True}, {"name": "managed-request-pattern", "os_control": False}]
fits = [item["name"] for item in candidates if all(item.get(key) == value for key, value in requirements.items())]
print("synthetic fit", ",".join(fits))
synthetic fit vm-pattern
Only the invented vm-pattern meets this local requirement; no product compatibility is tested.
State and consistency drive many service choices
Decide whether data needs relational transactions, object replacement, a cache, an event log, or another explicit model. Avoid storing required durable state in an ephemeral runtime or pretending a queue acknowledgment is an atomic database commit. Align connection budgets, idempotency keys, migrations, retention, and recovery points across service boundaries.
Synchronous calls propagate latency and availability dependencies; asynchronous boundaries add buffering, retries, ordering, and operational ownership. Neither pattern is automatically more reliable. Define user-visible completion and how partial effects are reconciled. Keep business correctness separate from a providerโs transport or replication guarantee.
A decision record should expose unresolved evidence
The second program checks that an invented decision record has a requirement, alternative, owner, and validation-status field. It deliberately reports cloud evidence as unverified. A well-structured record helps review, but its completeness is not proof that the chosen architecture works. Link each important claim to an official contract, model, or authorized test result.
Record rejected alternatives and the conditions that would reopen the decision. Include data movement, access changes, migration compatibility, rollback/roll-forward, and operator training. A phased migration needs explicit cutover, consistency, and retirement criteria instead of a single diagram arrow.
decision = {"requirement": "request handling with external durable state", "alternative": "vm-managed application", "owner": "service-team", "cloud_evidence": "unverified"}
assert all(decision.get(field) for field in ("requirement", "alternative", "owner", "cloud_evidence"))
print("record_complete", True)
print("cloud_evidence", decision["cloud_evidence"])
record_complete True
cloud_evidence unverified
The local record is structurally complete while openly retaining unverified cloud evidence.
Match the claim to the level of evidence
Distinguish a syntax check, offline model, provider schema check, reviewed plan, deployed service check, integration test, recovery exercise, and measured user outcome. Passing one does not imply the next. This course executes only harmless offline models and parsers. All cloud/CLI/Terraform documents remain non-runnable, and no account, service, credential, or configured environment is touched.
Before authorized implementation, assign owners to remaining checks and update assumptions against current service documentation. Preserve limits and dates rather than calling a design universally secure, cheap, compliant, or highly available. A defensible decision makes tradeoffs and missing evidence reviewable so future changes can be evaluated honestly.
Common errors and fixes
A product list is treated as a validated architecture.
- Why it happens
- Integration contracts and shared dependencies were omitted.
- How to fix it
- Map operations, state, identity, network, and failure behavior.
- Prevent it next time
- Trace at least one end-to-end user journey.
Preference scores override a hard requirement.
- Why it happens
- A ranking tool replaces requirement validation.
- How to fix it
- Screen mandatory constraints first and verify actual product support.
- Prevent it next time
- Record weights and sensitivity separately.
A local model is presented as a tested deployment.
- Why it happens
- Evidence levels were conflated.
- How to fix it
- Label exactly what executed and what remains unverified.
- Prevent it next time
- Keep approved test records and current assumptions.
Check your understanding
1. A team chooses Cloud Run because it wants less OS administration but the application requires persistent local shared files. What should happen next?
Show worked solution
Revisit the state requirement and verify the selected execution/storage contracts. Redesign required durable/shared state into a suitable service or choose another justified pattern; do not assume a managed request runtime preserves local files across instances. Compare consistency, latency, access, migration, and recovery implications. The operational preference is useful but cannot erase a mandatory data requirement.
2. What can a reviewer conclude from record_complete=True and cloud_evidence=unverified?
Show worked solution
The invented local schema has the required fields, but no cloud behavior is demonstrated. Use the record to assign verification work, check current official contracts, and plan authorized implementation/tests. Do not turn metadata completeness into a claim about IAM, networking, quotas, costs, deployment success, or recovery. The explicit gap is valuable evidence about the review state.
Key takeaways
- Select service patterns from explicit requirements and state semantics.
- Decision records preserve alternatives, tradeoffs, owners, and unresolved evidence.
- The strength of a claim must not exceed the validation actually performed.