Chaos Engineering Toolkit for Teaching Distributed Systems
A tool that injects controlled failures into a running system, network delay, packet loss, process kills and clock skew, so students can see what actually happens when infrastructure misbehaves. Teaching distributed systems failure by causing it rather than describing it.
Intermediate
A small team, or one strong student willing to learn something new.1 semester, 2 students
5 to ship
3 optional extrasSuggested stack
What you should ship
- Fault injection covering network latency, packet loss, partition, process termination and resource exhaustion
- Experiment definition specifying a hypothesis, a fault, a duration and the metrics to observe
- Automatic recovery guaranteeing the system returns to normal even if the tool itself crashes
- Result recording showing system behaviour against the stated hypothesis
- A sample distributed application plus at least 5 documented experiments with their outcomes
If you have time left
- Byzantine faults such as a node returning plausible but incorrect responses
- Automatic discovery of the smallest fault that breaks a given system
- A guided teaching mode that steps a student through experiments in order
The problem
Distributed systems failure modes are taught as descriptions. Students learn the phrase network partition without ever having watched a system behave badly during one, and the lesson does not stick.
What you build
A fault injector, an experiment framework built around hypotheses, guaranteed recovery, and a set of documented teaching experiments.
The safety property that is not optional
Recovery must be guaranteed even if your tool dies. Every injected fault needs a deadline enforced independently of the process that created it, so a crashed controller cannot leave a cluster partitioned. Implementing that properly is a genuine engineering problem and the first thing an examiner should ask about.
Why hypotheses make it engineering rather than vandalism
The discipline is not breaking things, it is stating what you expect to happen, breaking something, and comparing. An experiment definition should require the hypothesis up front, and the report should show where reality disagreed. Those disagreements are the whole point.
The deliverable with the most value
The documented experiments. A sample application plus five experiments with recorded outcomes is directly reusable teaching material, and it demonstrates that your tool works better than any feature list.
Scope warning
Container level fault injection in one orchestrator. Do not attempt kernel level fault injection or multi-cloud support.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.
Follow along
New writing, resources and project ideas land here first.