Milestone map
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
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?
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?
Part of