Skills

Implement Cloud-Native Design Patterns on a Real Deployment

10 weeks · 0 milestones

Implement 3–5 cloud-native design patterns — circuit breaker, bulkhead, retry with exponential backoff, saga, or event sourcing — on a real deployment on AWS, GCP, or Azure, producing a working system with a deployment URL the reviewer can access. For each pattern implemented, write a trade-off analysis explaining: why this pattern was chosen over alternatives, what failure scenario it addresses, and what complexity cost it introduces. The running deployment is the proof that the patterns actually exist in the system, not just in a diagram. Proof: a cloud architect or senior SRE inspects the running deployment during the review and asks 'what happens if I call this endpoint while the circuit is open?' — you must demonstrate the live behaviour, not describe it from the documentation.

Part of: Computer Science & Data · Proves for: Engineers, PG

Milestone map

3 milestones

Build a Containerised Microservice Application

8–16 weeks (including learning containerisation)

Implement an application consisting of at least three communicating services, each containerised with Docker, and orchestrated with Docker Compose or Kubernetes. The application must implement at least two of the following patterns: API gateway, circuit breaker, service discovery, event-driven communication, or sidecar. Deploy to a cloud platform (any major provider has a free tier).

Proof required

Submit: a public GitHub repository containing the application code, Dockerfiles for each service, and an orchestration configuration file (docker-compose.yml or Kubernetes manifests); a README documenting the architecture and the two patterns implemented; and a live URL or screenshot proving the application is deployed and reachable. A senior cloud engineer or architect must review the repository and confirm in writing that the patterns are correctly implemented.

What gets checked

Three or more communicating services, each containerised, with orchestration configuration committed to the repository
Two cloud-native patterns are demonstrably implemented — not described in a README without code evidence
A senior cloud engineer or architect has confirmed in writing that the patterns are correctly implemented

Common mistakes

Building one monolithic service in a single container and describing it as a 'microservice architecture'
Implementing patterns in the README description without the code reflecting the patterns

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Are three or more services in the repository, each with a separate Dockerfile and service definition?
Which two patterns are implemented — can the candidate point to the specific code implementing each?
Ask: 'what happens if service 2 becomes unavailable — how does the application behave?' — tests circuit breaker understanding

You'll sign in first, then come straight back here.

Implement Observability and Resilience Patterns

8–12 weeks (after milestone 1)

Extend the milestone 1 application with production-quality observability: distributed tracing (OpenTelemetry or Jaeger), structured logging with a correlation ID propagated across services, and health check endpoints. Implement at least one resilience pattern in code: retry with exponential backoff or a bulkhead. Write an Architecture Decision Record (ADR) for each major design choice.

Proof required

Submit: the updated public GitHub repository with observability and resilience code; a working distributed trace screenshot showing a request spanning multiple services; a structured log sample showing correlation ID propagation across services; and at least two ADRs (one per major design decision) following the standard ADR template (context, decision, consequences). A senior cloud engineer or architect must review the ADRs and confirm in writing that the decisions are sound.

What gets checked

Distributed trace screenshot shows a request spanning at least two services — not a single-service trace
Structured log sample shows the same correlation ID in logs from at least two different services
Each ADR follows the standard template — context, decision, consequences — and was confirmed sound by a senior engineer

Common mistakes

Adding logging without correlation IDs — correlation is the property that makes distributed logging useful
ADRs that describe what was implemented rather than why it was chosen over alternatives

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Does the distributed trace show a request spanning at least two services?
Do the structured logs from different services share the same correlation ID?
Read the ADRs: do they discuss alternatives that were rejected, or only describe the choice made?

You'll sign in first, then come straight back here.

Document, Present, and Defend the Architecture

4–6 weeks (after milestone 2)

Write a complete architecture document for the system: component diagram, data flow diagram, failure mode analysis (what happens when each component fails), and a deployment runbook. Present the architecture to a senior cloud engineer or architect and answer challenging questions about the design tradeoffs.

Proof required

Submit: a complete architecture document (component diagram, data flow diagram, failure mode analysis, deployment runbook); and a recording or written transcript of a design review session with a senior cloud engineer or architect where you answered at least three specific challenging questions about design tradeoffs.

What gets checked

Architecture document includes all four components — component diagram, data flow diagram, failure mode analysis, and deployment runbook
Design review was conducted with a senior cloud engineer or architect with cloud-native experience
Transcript or recording shows at least three challenging questions were asked and substantively answered

Common mistakes

Failure mode analysis that only lists what can fail without describing what the system does when it fails
Design review with a colleague who does not challenge the decisions — the reviewer must push back on at least some choices

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Does the architecture document include all four components?
Was the design review conducted with someone with genuine cloud-native experience?
Does the transcript show at least three challenging questions — not confirmatory ones?

You'll sign in first, then come straight back here.

Part of

Cloud Architecture →

Related outcomes

All outcomes

Skills

Implement Cloud-Native Design Patterns on a Real Deployment

10 weeks · 0 milestones

Part of: Computer Science & Data · Proves for: Engineers, PG

Milestone map

3 milestones

Build a Containerised Microservice Application

8–16 weeks (including learning containerisation)

Proof required

What gets checked

Three or more communicating services, each containerised, with orchestration configuration committed to the repository
Two cloud-native patterns are demonstrably implemented — not described in a README without code evidence
A senior cloud engineer or architect has confirmed in writing that the patterns are correctly implemented

Common mistakes

Building one monolithic service in a single container and describing it as a 'microservice architecture'
Implementing patterns in the README description without the code reflecting the patterns

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Are three or more services in the repository, each with a separate Dockerfile and service definition?
Which two patterns are implemented — can the candidate point to the specific code implementing each?
Ask: 'what happens if service 2 becomes unavailable — how does the application behave?' — tests circuit breaker understanding

You'll sign in first, then come straight back here.

Implement Observability and Resilience Patterns

8–12 weeks (after milestone 1)

Proof required

What gets checked

Distributed trace screenshot shows a request spanning at least two services — not a single-service trace
Structured log sample shows the same correlation ID in logs from at least two different services
Each ADR follows the standard template — context, decision, consequences — and was confirmed sound by a senior engineer

Common mistakes

Adding logging without correlation IDs — correlation is the property that makes distributed logging useful
ADRs that describe what was implemented rather than why it was chosen over alternatives

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Does the distributed trace show a request spanning at least two services?
Do the structured logs from different services share the same correlation ID?
Read the ADRs: do they discuss alternatives that were rejected, or only describe the choice made?

You'll sign in first, then come straight back here.

Document, Present, and Defend the Architecture

4–6 weeks (after milestone 2)

Proof required

What gets checked

Architecture document includes all four components — component diagram, data flow diagram, failure mode analysis, and deployment runbook
Design review was conducted with a senior cloud engineer or architect with cloud-native experience
Transcript or recording shows at least three challenging questions were asked and substantively answered

Common mistakes

Failure mode analysis that only lists what can fail without describing what the system does when it fails
Design review with a colleague who does not challenge the decisions — the reviewer must push back on at least some choices

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Does the architecture document include all four components?
Was the design review conducted with someone with genuine cloud-native experience?
Does the transcript show at least three challenging questions — not confirmatory ones?

You'll sign in first, then come straight back here.

Part of

Cloud Architecture →