System Components and Dependencies

A student says the internet is broken. How do they know? Because their game won't connect. Does "game won't connect" actually prove "internet broken"? No — it could be true, but nothing so far has proven it. Welcome to dependencies.

What is a dependency

A dependency is something another part of the system needs in order to function as expected. A monitor depends on power, a display signal, a cable connection, and a working display device. A game may depend on the operating system, files, hardware, drivers, an account, the network, and an online service. Different actions have different dependency chains.

Dependencies chain together

A game depends on the operating system, which depends on hardware. Separately, the game depends on the network, which depends on a switch, which depends on a router, which depends on the internet, which reaches a game service. And separately again, the game depends on an account, which depends on an authentication service. "Game won't connect" now has several distinct branches it could actually be coming from.

Upstream and downstream

If power feeds the computer, which runs the application, power is upstream of the application. If power fails, everything downstream loses function. But if only a microphone fails, does the whole computer stop? No — the microphone is one branch, not the trunk.

Blast radius

Borrowing a useful technical phrase: blast radius means how much of the system is affected when a given component fails. One mouse failing affects one station. One network switch serving twelve stations failing affects up to twelve stations. Same category of failure — hardware breaks — very different scope.

This matters for esports operations specifically. One failed headset during finals is annoying. A failed switch connecting every competition station is a different category of problem entirely. Technical staff should be thinking about dependencies, shared infrastructure, backup plans, and maintenance priorities with blast radius in mind, not treating every failure as equally urgent.

Shared dependency

Picture six PCs all connecting through one switch. The switch is a shared dependency. If one PC fails, that's one station down. If the switch fails, everyone connected to it may be affected at once.

Single point of failure

A single point of failure is a component whose failure can stop an important function because no alternative exists. One broadcast computer with no backup is a single point of failure for the broadcast — if it goes down, the broadcast stops.

Redundancy

Redundancy means having an alternative ready: a backup headset, a spare cable, a second production machine, a backup configuration, a second network path. Not every component deserves full redundancy — money and complexity both push back against duplicating everything. Evaluating a system means weighing tradeoffs, costs, benefits, reliability, and constraints against each other, not maximizing backup coverage everywhere.

Two complete backup gaming PCs for every player would be reliable and almost certainly unaffordable. System design is a series of tradeoffs, not a checklist of everything that could theoretically go wrong.

Criticality

Classify components as critical (failure stops an essential function), important (failure significantly degrades the experience, but some operation continues), or convenient (useful, but the core function survives without it).

Context changes the classification. A camera might not be critical for a player station, but it could be very important for a face-camera broadcast production. Same object, different system, different criticality — the system's goal determines importance, not the object itself.

Dependency lab: match starts in 10 minutes

You are the technical team for a lab with twelve player PCs, twelve monitors, twelve keyboards, twelve mice, twelve headsets, one network switch, one router, one internet connection, one broadcast PC, and one admin laptop. Work through six scenarios.

Scenario 1: mouse failure. Station 4's mouse stops responding. What's the blast radius, the criticality, the dependency, and the fastest reasonable response? Probably a spare mouse — which is exactly why inventory matters, a theme Lesson 3 picks up directly.

Scenario 2: switch failure. All twelve player stations lose network access. The broadcast PC, connected elsewhere, stays online. What does that tell you about shared dependencies and blast radius?

Scenario 3: game service outage. Every computer has internet access, websites work, but the game service can't be reached. A student announces "school internet is broken" — is that conclusion actually justified? No. You've isolated a different layer than the one being blamed.

Scenario 4: one player can't log in. Everyone else can. The workstation has internet, and the game launches fine. Where would you look next? Probably account, authentication, permissions, or credentials — dependency narrowing in action.

Scenario 5: broadcast monitor fails. The broadcast computer keeps operating, and the stream stays online. How critical was that monitor, actually? It depends on whether staff can safely operate without seeing it — again, the system's goal decides.

Scenario 6: router fails. Trace what parts of the system could plausibly be affected.

Build the dependency map

Use at least eight components, with arrows meaning "depends on" — not just "these look connected." Example: game client depends on operating system, which depends on computer hardware. A separate branch: game client depends on network connection, which depends on switch, which depends on router, which depends on internet.

Arrow direction has to mean something specific. If A points to B, define whether that means "A depends on B" or "A provides something to B" — pick one, and label it. A diagram isn't decoration; it's a claim about how the system actually works.

Dependency challenge

Your instructor removes one component. Your group gets sixty seconds: what stops, what still works, how do you know, and what evidence would help confirm it? This is the beginning of troubleshooting — not fixing yet, just understanding the system well enough to reason about it.

Before you leave

Complete:

1. The component with the largest blast radius in our map is __________ because __________.
2. A component with a small blast radius but high importance is __________ because __________.

Those are different concepts — make sure your answers show that.

Source note

This lesson directly supports Middle Township Unit 5 expectations involving integrated systems, network reliability, system evaluation, maintenance, repair, constraints, and cost-benefit reasoning.

The dependency model, blast-radius concept, criticality model, shared-dependency lab, and esports system scenarios are original Robotnix Academy components.