theJugglingCompany.com

Blog · 10 June 2026 · 7 min read TechChange

The Cat's Cradle Is a System

Every strand in a cat's cradle is load-bearing. Remove one and the geometry rearranges. Real systems work the same way: the architecture diagram shows direct dependencies, but the structural ones - shared platforms, foundational infrastructure, the senior engineer who left - are doing most of the work to keep the shape.

Multiple hands from both sides holding an intricate cat's cradle of glowing orange and purple neon strings, forming a complex geometric web structure between them

A cat’s cradle is a structure of pure tension. No strand exists independently. Each is kept in position by the tension in the lines adjacent to it, which are kept in position by the lines adjacent to them, all the way back to the fingers that hold the perimeter. The geometry emerges from the web of relationships, not from any single strand.

Remove one finger and the whole structure rearranges. The same constraint logic shows up in the formal treatments of juggling: Buhler, Eisenbud, Graham, and Wright (1994) showed that a siteswap sequence is a valid pattern only when every throw height is consistent with every other one. Change one throw and you change the legality of the whole sequence. Real systems - whether string figures, juggling patterns, or production architectures - obey this kind of global constraint. Local changes are not local. They never were.

Every strand
Load-bearing
In a real dependency web, there is no such thing as a harmless removal. Every strand is maintaining tension in adjacent strands you may not be tracking.
No center
The whole web is the structure
Unlike a hub-and-spoke diagram, the cat's cradle has no single point of control. The structure is the relationships - not any node within them.
Visible
Only while held
The cat's cradle disappears the moment the hands let go. A dependency web that isn't actively maintained - documented, monitored, understood - becomes invisible before it becomes a problem.

What the diagram doesn’t show

A dependency diagram in architecture documentation typically shows boxes and arrows. The boxes are services or teams. The arrows indicate relationships. It is a useful simplification.

The cat’s cradle is the actual structure, and the actual structure has three properties that the simplified diagram misses.

First: the tension in each strand is maintained by all the other strands. You cannot understand the load on any one line by looking at it in isolation. A strand crossing the interior is under a specific tension only because of the strands crossing it, which are under their own specific tensions.

Second: the structure is only stable while all hands are present. A cat’s cradle does not freestand. It requires everyone in the frame to maintain their position. The moment one participant changes their grip, the whole structure shifts.

Third: the geometry is not designed - it emerges. No individual strand was placed with the intention of creating the overall pattern. The pattern is the aggregate of all the local decisions about where each strand crosses.

The two kinds of dependency

In juggling, there are two fundamentally different ways to be connected to another performer. One is passing - you send a prop to them and they catch it. The other is feeding - you maintain your own pattern while staying within the frame of a shared structure.

The passing relationship is direct and visible: the club travels from one hand to the other. The dependency is temporal - it happens at a specific moment and then resolves.

The feeding relationship is structural and ongoing: both jugglers are maintaining their own patterns simultaneously, but the available space for each pattern is shaped by what the other is doing. If one juggler moves, the other has to adjust. The dependency is not a transfer - it is a shared constraint on the available space.

Most real organisational and technical dependencies are the feeding kind. Two services do not directly call each other, but both consume from the same shared queue, and their independent decisions about rate and volume shape the other’s experience. Two teams do not hand work to each other, but both depend on the same platform team’s deployment pipeline, and each team’s release schedule constrains the other’s.

DIRECT DEPENDENCYSTRUCTURAL DEPENDENCYService AService Bcalls directlyvisible in architecture diagrambreaks visibly when removedeasy to find, easy to fixTeam ATeam BPlatform Teamno direct call between A and Bbut shared dependency constrains bothinvisible in most diagrams
Direct dependency vs structural dependency - both exist in every real system, but only direct dependencies appear in most documentation

The hands at the edge

In a cat’s cradle, the hands at the periphery are the most important. They define the perimeter. If one of the edge hands lets go, the entire interior collapses - not just the strands connected to that hand, but every strand that was tensioned relative to those.

In complex systems, the perimeter dependencies are exactly this: the foundational infrastructure, the shared platforms, the senior engineers who hold context about why certain decisions were made. When they change - when the hand at the edge shifts or releases - the interior rearranges in ways that are difficult to predict and often invisible until something downstream breaks.

The most dangerous dependency is the one nobody documented because it seemed obvious when it was built. Three years later, the person who built it has left. The hand at the edge is empty. The interior is still holding its geometry, for now, because the other hands haven’t moved yet.

Making the web visible

The cat’s cradle can only be understood while it is held. The moment the hands release, the structure collapses and the pattern that existed is lost. The only way to understand a cat’s cradle is to trace it while it is under tension - to follow each strand from one hand to the next, noting every crossing and every point of contact.

This is what dependency mapping does. Not a clean diagram of the intended architecture, but a tracing of the actual web under tension: every service-to-service call, every shared database, every team that depends on every other team’s output.


Reference: Buhler, J., Eisenbud, D., Graham, R., and Wright, C. (1994). “Juggling Drops and Descents.” American Mathematical Monthly, 101(6), 507-519. The combinatorial proof that a sequence of throws is a valid pattern only when every throw is consistent with every other.

Read next: The Web Is Not Built Alone - how shared infrastructure requires multiple hands to hold it.