Computer Science · Grade 12

Active learning ideas

Distributed Systems and Microservices

Active learning works well for this topic because students need to experience the complexities of distributed systems firsthand. By building and testing systems, they see why monoliths and microservices behave differently under real conditions, which helps them move beyond abstract definitions.

• Ontario Curriculum Expectations
• CS.N.11
• CS.SE.2

• 35–50 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Project-Based Learning
• 50 min · Pairs

Compare and Contrast: Monolith vs Microservices

Provide students with a simple monolithic web app code. In pairs, refactor it into three microservices using Node.js and Express. Deploy locally with Docker, then test scalability by simulating user load with tools like Artillery.

Explain the advantages of a microservices architecture over a monolithic application.

Facilitation Tip

During Compare and Contrast, assign each pair of students one monolith and one microservices scenario so they must articulate differences using the same metrics.

What to look for

Present students with two application scenarios: one requiring rapid feature iteration and high user concurrency, the other a small internal tool. Ask them to identify which scenario would benefit more from a microservices architecture and justify their choice with one specific reason.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Activity 02

• Project-Based Learning
• 35 min · Small Groups

Failure Simulation: Distributed Resilience

Divide class into small groups representing services in a ride-sharing app. Use cards to simulate network failures or service crashes. Groups redesign communication protocols to maintain functionality, discussing recovery strategies afterward.

Analyze the challenges of managing data consistency in a distributed system.

Facilitation Tip

In Failure Simulation, limit the network failure scenarios to three distinct cases so students focus on identifying patterns in system behavior.

What to look for

Pose the question: 'Imagine a distributed system where a user's profile service and order history service fail independently. What are two potential impacts on the user experience, and what strategy could mitigate one of these impacts?' Facilitate a class discussion on fault isolation and recovery.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Activity 03

• Project-Based Learning
• 45 min · Individual

Design Challenge: Web App Distributed System

Assign a scenario like an online bookstore. Students individually sketch architecture diagrams for microservices handling users, inventory, and payments. Share and iterate in whole-class critique, focusing on data consistency.

Design a simple distributed system for a web application.

Facilitation Tip

For the Design Challenge, provide a starter stack diagram but force students to justify each service boundary with a one-sentence design rationale.

What to look for

On an index card, ask students to list one advantage of microservices over monoliths and one challenge of managing data consistency in a distributed system. They should provide a brief, one-sentence explanation for each.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

Activity 04

• Project-Based Learning
• 40 min · Small Groups

Data Consistency Lab: Eventual vs Strong

Set up a shared database simulation with Google Sheets. Small groups update inventory across 'services' under different consistency models, tracking conflicts. Debrief on trade-offs for performance versus accuracy.

Explain the advantages of a microservices architecture over a monolithic application.

Facilitation Tip

In the Data Consistency Lab, require students to log timestamps with every record update so they can trace eventual consistency delays.

What to look for

Present students with two application scenarios: one requiring rapid feature iteration and high user concurrency, the other a small internal tool. Ask them to identify which scenario would benefit more from a microservices architecture and justify their choice with one specific reason.

• Apply
• Analyze
• Evaluate
• Create
• Self-Management
• Relationship Skills
• Decision-Making

A few notes on teaching this unit

Teachers often start with concrete examples before theory, using real systems like Netflix or Uber to ground discussions. Avoid lectures that over-explain CAP theorem early; instead, let students discover consistency challenges through controlled experiments. Research shows that students grasp distributed concepts better when they build systems first and then layer on theory as needed to explain what they observe.

Successful learning looks like students comparing monolithic and microservices architectures using measurable data, designing resilient systems that account for failure, and explaining trade-offs in performance and consistency with evidence from their labs and simulations.

---

Watch Out for These Misconceptions

• During Compare and Contrast: Monolith vs Microservices, students may assume distributed systems are always faster.

  During Compare and Contrast, have students measure response times for identical requests in both architectures using a simple load test script, then analyze why network overhead often slows distributed systems.

• During Failure Simulation: Distributed Resilience, students may believe microservices eliminate all single points of failure.

  During Failure Simulation, intentionally break a shared dependency like a central database and observe how other services degrade; use these observations to discuss when redundancy fails.

• During Data Consistency Lab: Eventual vs Strong, students may think data consistency is handled automatically in distributed systems.

  During Data Consistency Lab, have students track the number of stale reads in their logs and use this data to justify why strong consistency requires extra coordination protocols.

---

Methods used in this brief

• Project-Based Learning