Milestone map
Milestone map
3 milestones
Design a Multi-Region Data Architecture
8–14 weeks (includes CAP/PACELC study)
Study the CAP theorem, PACELC theorem, and consistency models (eventual consistency, strong consistency, read-your-own-writes). Design a multi-region architecture for a write-heavy application: specify the data replication strategy (active-active vs active-passive), the consistency model for each data type, and the conflict resolution approach. Document the design in an Architecture Decision Record.
Proof required
Submit: an architecture design document (at least 600 words) for the multi-region data architecture including: replication topology diagram, consistency model per data type with justification, conflict resolution approach with an example of a conflict and how it would be resolved, and an ADR for the most significant architectural decision. A senior cloud architect or distributed systems engineer must review and confirm the design is coherent and the consistency model choices are justified.
What gets checked
- Design specifies consistency models per data type — not a single consistency model for the entire system
- Conflict resolution approach includes a concrete example showing how a specific conflict would be resolved
- A senior cloud architect or distributed systems engineer has confirmed the design is coherent
Common mistakes
- Design that selects one consistency model for all data without explaining why different data types might need different models
- Conflict resolution approach that describes the strategy without a concrete conflict example
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the design specify consistency models per data type with justification?
- Does the conflict resolution section include a concrete example of a specific conflict?
- Ask: 'what happens to write availability in your design if the cross-region link fails?' — tests CAP understanding
Implement and Test Multi-Region Failover
8–14 weeks (after milestone 1)
Implement a proof-of-concept multi-region application (using a cloud provider's free tier or a local simulation with Docker): two 'regions' with a shared data store that supports replication, a load balancer that routes traffic, and an automated failover mechanism. Test the failover by deliberately taking down one region and measuring recovery time and data loss.
Proof required
Submit: a public GitHub repository containing the multi-region proof-of-concept (Docker Compose or cloud infrastructure code); a test script that takes down one region and records recovery time and data loss; and a written failover report (200 words) showing measured recovery time and data loss, with an explanation of what determines each. A senior cloud architect or distributed systems engineer must confirm the implementation demonstrates real failover behaviour.
What gets checked
- Two regions are deployed and the failover script actually takes one down — not a simulated description
- Failover report shows measured recovery time and data loss from a real test — not estimated values
- A senior cloud architect has confirmed the implementation demonstrates real failover behaviour
Common mistakes
- Failover test that only describes what would happen without executing the actual region failure
- Failover report with estimated values rather than measured values from the actual test
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Did the failover test actually execute a region failure — not describe it?
- Are recovery time and data loss measured values — not estimates?
- Ask: 'what tradeoff did you make in your replication strategy that affected the measured data loss?' — tests understanding of the consistency vs availability tradeoff
Present the Multi-Region Architecture in a Design Review
4–8 weeks (after milestone 2)
Write a complete architecture document for the multi-region system: data replication topology, failover runbook, capacity model for cross-region traffic, and cost analysis. Present to a senior cloud architect or distributed systems engineer who challenges at least two design decisions.
Proof required
Submit: a complete architecture document (at least 800 words) with replication topology, failover runbook, cross-region traffic capacity model, and cost analysis; and a recording or transcript of a design review with a senior cloud architect or distributed systems engineer who challenged at least two design decisions.
What gets checked
- Architecture document includes all four components — replication topology, failover runbook, capacity model, and cost analysis
- Failover runbook is step-by-step and operational — not a high-level description
- A senior cloud architect challenged at least two design decisions in the documented review
Common mistakes
- Failover runbook that describes what happens rather than the specific steps an operator must take
- Cost analysis with estimated costs but no source for the estimates
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Is the failover runbook step-by-step and operational — not descriptive?
- Does the cost analysis cite a source for the estimates?
- Were at least two design decisions challenged in the documented review?
Part of