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.

• Grade 12
• Computer Science
• 4 activities
• 35 min–50 min

Learning Objectives

1. Compare the advantages of a microservices architecture against a monolithic architecture for web applications.
2. Analyze the challenges of maintaining data consistency across multiple independent services in a distributed system.
3. Design a high-level architecture for a simple web application using a microservices approach.
4. Evaluate the trade-offs between scalability, resilience, and complexity when choosing a distributed system design.

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.

Prepare & details

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.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

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.

Prepare & details

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.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

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.

Prepare & details

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.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

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.

Prepare & details

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.

Setup: Flexible workspace with access to materials and technology

Materials: Project brief with driving question, Planning template and timeline, Rubric with milestones, Presentation materials

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Quick Check

After Compare and Contrast: Monolith vs Microservices, present students with two application scenarios. Ask them to write which architecture fits each scenario and one piece of evidence from their comparison tables to support their choice.

Discussion Prompt

After Failure Simulation: Distributed Resilience, pose a scenario where two services fail independently. Ask students to discuss in small groups the two most likely user impacts and one strategy they would implement to mitigate the worst impact.

Exit Ticket

During Design Challenge: Web App Distributed System, ask students to hand in a one-paragraph reflection listing one advantage of their chosen architecture and one challenge they anticipate based on their design decisions.

Extensions & Scaffolding

• Challenge: Ask students to propose a hybrid architecture mixing monolithic and microservices components for a given workload, then defend their design in a one-minute pitch.
• Scaffolding: Provide pre-labeled service blueprints for students who struggle with boundaries, asking them to fill in just the communication links.
• Deeper exploration: Have students research how service meshes like Istio handle retries and load balancing, then present their findings to the class.

Key Vocabulary

Distributed System	A system where components are located on different networked computers, which communicate and coordinate their actions by passing messages to achieve a common goal.
Microservices Architecture	An architectural style that structures an application as a collection of small, independent, and loosely coupled services, each running in its own process and communicating via lightweight mechanisms.
Monolithic Architecture	An architectural style where an application is built as a single, unified unit, with all components tightly integrated and deployed together.
Scalability	The ability of a system to handle a growing amount of work, or its potential to be enlarged to accommodate that growth, often by adding more resources.
Resilience	The ability of a system to continue operating correctly, even in the presence of faults or failures, such as network issues or service outages.