Scrolls
3 min read
On this page

How Parts Interact

Understanding a system means understanding how its pieces connect — not just what each piece does on its own. A pile of car parts is not a car. A group of talented individuals is not automatically a great team. The interactions between components are what create the system's behavior.

The Everyday Version

A Car Engine

A car engine is made of hundreds of parts, but none of them work alone.

The sequence of interactions:
1. You turn the key → sends electrical signal
2. Battery powers the starter motor
3. Starter motor turns the crankshaft
4. Crankshaft pulls pistons down, drawing in air and fuel
5. Spark plugs ignite the fuel-air mixture
6. Explosion pushes pistons up
7. Pistons turn the crankshaft
8. Crankshaft transfers power to the transmission
9. Transmission sends power to the wheels

If any single link breaks, the whole chain fails.
A perfect engine with a dead battery does nothing.
A perfect battery with a broken starter does nothing.

The critical insight: the engine's behavior comes from how parts interact, not from any single part.

A Team at Work

Consider a team of five people working on a project.

Situation A: Everyone works independently
- Person 1 builds the database
- Person 2 builds the user interface
- Person 3 writes the documentation
- They finish their pieces and try to connect them
- Nothing fits together. Months of rework.

Situation B: The team coordinates
- They agree on interfaces first
  (what data flows between components)
- Regular check-ins catch mismatches early
- When Person 1 is delayed, Person 2 adjusts their plan
- The final product works because the interactions were managed

The individual skill of each person matters less than
how well they coordinate.

A Kitchen During Dinner Rush

A restaurant kitchen is a system where timing and coordination matter more than individual skill.

Components: Chef, sous chef, line cooks, dishwasher, servers

Interactions:
- Server takes order → passes to chef
- Chef breaks order into stations → assigns to line cooks
- Line cook at grill needs plates → dishwasher must keep up
- All dishes for one table must be ready at the same time
- Server must be available when food is ready

If the dishwasher falls behind, line cooks have no plates.
If one station is slow, the whole table's food gets cold.
One bottleneck affects everything downstream.

A Family Morning Routine

Components: Two parents, two children, one bathroom

Interactions:
- Child 1 needs the bathroom → blocks Child 2
- Parent 1 making breakfast → needs the kitchen clear
- Parent 2 looking for car keys → delays departure
- Everyone needs to leave by 8:00

If one child takes too long in the bathroom,
the entire morning schedule cascades.
The system (family leaving on time) depends on
each part's timing relative to others.

Dependencies: The Glue Between Parts

When one part relies on another, that is a dependency. Dependencies define how parts interact.

Types of dependencies:

Sequential: A must finish before B starts
- Pouring concrete → waiting for it to dry → building on it
- Cannot skip or reorder steps

Shared resource: A and B both need the same thing
- Two people, one car
- Two programs, one database
- Conflict arises when both need it simultaneously

Data flow: A produces what B consumes
- The weather station produces data
- The weather app displays it
- If the station sends bad data, the app shows wrong forecasts

Timing: A and B must happen at the same time
- Musicians in an orchestra
- Synchronized traffic lights
- If timing drifts, the system breaks down

Connecting to Technology

Microservices Dependencies

Modern software is often built as many small services that talk to each other.

An online store might have:
- User Service (handles accounts and login)
- Product Service (manages the catalog)
- Cart Service (tracks what you want to buy)
- Payment Service (processes transactions)
- Shipping Service (arranges delivery)

The dependency map:
  User Service ←── Cart Service ──→ Product Service
                        |
                   Payment Service
                        |
                  Shipping Service

When you click "Buy Now":
1. Cart Service asks User Service: "Who is this person?"
2. Cart Service asks Product Service: "Is this item in stock?"
3. Cart Service asks Payment Service: "Charge their card"
4. Payment Service asks Shipping Service: "Send the package"

Each arrow is a potential point of failure.

Cascading Failures

When parts are tightly connected, one failure can bring down the whole system.

Scenario: The Product Service goes down

1. Cart Service asks Product Service for item details → no response
2. Cart Service waits... and waits... and waits
3. Cart Service threads pile up, all waiting
4. Cart Service runs out of resources and stops responding
5. Now the User Service cannot reach Cart Service
6. User sees: "The entire website is down"

Original problem: One service had a bug
Actual impact: The entire store is unreachable

This is a cascading failure. One domino knocks
over the next, which knocks over the next.

Real-world parallel: a single accident on a highway causes traffic to back up for miles, eventually blocking intersections far from the original problem.

API Contracts

An API contract is an agreement about how two parts communicate.

Think of it like a restaurant order:

The contract:
- Customer says: "I want a burger with no onions"
- Kitchen agrees: "We will deliver a burger with no onions"

In tech:
- Service A says: "I will send you a user ID as a number"
- Service B agrees: "I expect a user ID as a number
  and will return that user's name as text"

What happens when the contract breaks:
- Service A starts sending user IDs as text ("user-42"
  instead of 42)
- Service B tries to process it as a number
- Service B crashes
- Everything that depends on Service B also breaks

Contract management strategies:

Version your APIs:
- v1 sends numbers, v2 sends text
- Both versions work simultaneously during transition
- Old clients use v1, new clients use v2

Validate inputs:
- Each service checks what it receives
- If the input is wrong, reject it immediately
  with a clear error message
- Better to fail loudly than to process bad data silently

Document expectations:
- What data goes in?
- What data comes out?
- What happens on errors?
- Without documentation, every change is a gamble

Circuit Breakers

A pattern for preventing cascading failures, inspired by electrical circuit breakers.

Without a circuit breaker:
- Service A calls Service B
- Service B is down
- Service A waits 30 seconds for a timeout
- Service A tries again. And again. And again.
- Service A is now stuck, doing nothing useful

With a circuit breaker:
- Service A calls Service B
- Service B is down
- After 3 failures, the circuit breaker "opens"
- All future requests to Service B immediately fail
  (no waiting, no wasting resources)
- Every 30 seconds, the breaker lets one request through
  to check if Service B is back
- When Service B recovers, the breaker "closes"
  and normal traffic resumes

Mapping Interactions

Before you can manage interactions, you need to see them.

Step 1: List all the parts
- What components exist?
- What does each one do?

Step 2: Draw the connections
- What does each part need from other parts?
- What does each part provide to other parts?

Step 3: Identify critical paths
- Which connections, if broken, would stop everything?
- These are your highest-risk interactions

Step 4: Find hidden dependencies
- Shared databases that multiple services use
- Shared configuration files
- Network infrastructure assumed to always be available
- The clock (time synchronization across systems)

Common Pitfalls

  • Thinking in parts, not connections. Understanding each component perfectly but ignoring how they work together leads to systems that fail at the seams.
  • Assuming independence. Just because two parts do not directly talk to each other does not mean they are independent. They might share a database, a network, or a dependency.
  • Ignoring latency between parts. In-memory function calls take nanoseconds. Network calls between services take milliseconds. That difference changes everything about reliability.
  • Tight coupling without realizing it. When changing one part always requires changing another, they are coupled. This makes the system fragile.
  • Missing the human components. Systems include people. The on-call engineer, the product manager, the end user — they are all parts of the system too.
  • Building without contracts. If two services communicate without a clear agreement on format and behavior, every change risks breaking something.

Key Takeaways

  • A system's behavior comes from how its parts interact, not from the parts themselves.
  • Dependencies are the connections between parts: sequential, shared resource, data flow, and timing.
  • Cascading failures happen when one component's problem spreads through its connections to other components.
  • API contracts define how parts communicate. Breaking a contract can break everything downstream.
  • Circuit breakers and similar patterns protect systems from cascading failures.
  • To understand a system, map its parts and connections — especially the hidden ones.