The Carpenter's Square and the Weaver's Loom: On Alignment and Entanglement in System Interfaces

There's a quiet moment in maintaining any service when you must decide how its components will speak to each other. The choice often feels trivial, a simple selection of protocol or data format, but the consequences ripple outward, shaping the very character of your system's operations. Lately, I've been thinking of this choice not in technical terms, but as two contrasting philosophies: the Carpenter's approach and the Weaver's.

The Carpenter's approach is one of strict alignment. Picture a carpenter using a square to ensure two pieces of wood meet at a perfect 90-degree angle. The interface is that square. It is rigid, unambiguous, and absolute. In our world, this is the gRPC service definition, the strictly typed API call, the structured log entry that must conform to a schema before it’s even written. The carpenter’s system is built on predictability; a malformed request cannot physically fit into the allotted space. When something goes wrong, the failure mode is often immediate and obvious—a compilation error, a rejected connection. The lines are clean, the joints are tight, and the whole structure gains a certain kind of robust beauty from its precision.

Contrast this with the Weaver's approach, which embraces a degree of entanglement. A weaver works with a loom, intertwining threads to create a fabric. The strength and pattern emerge from the relationships between the threads, not from the rigid placement of individual strands. This is the system that communicates with flexible JSON payloads, where services gracefully ignore fields they don't understand. It's the log file that begins as a simple stream of text, accumulating context and variation over time as different parts of the system add their voices. The weaver’s system is built on resilience and adaptability; it can absorb unexpected data and continue functioning, finding utility in the messy, organic growth of information.

The Cost of the Right Angle

Neither approach is inherently superior, but each carries a distinct operational tax. The Carpenter’s square demands upfront investment. You must design the interface with care, define your schemas meticulously, and accept that change, when it comes, will require a coordinated effort—you’re planing down all the connecting pieces at once. The rigidity that provides stability can become a straitjacket, making it difficult to prototype rapidly or to integrate with a third-party system that doesn’t share your exacting standards.

The Weaver’s loom, for its part, taxes you later. The initial freedom is seductive. You can bolt on a new service that writes a slightly different log line, or add a field to a payload without renegotiating a contract. But this flexibility accumulates a kind of technical debt, a creeping entanglement. One day, you’ll need to parse those logs, and you’ll find a dozen subtle variations of the same message. You’ll discover that a service you depend on has been quietly adding fields that yours has ignored, and now a critical function depends on data you never knew you were using. The system becomes a living entity, its behaviour not fully documented in any one place but spread implicitly across its interconnected parts.

My own tendency has long been toward the Carpenter’s square. I like the certainty. Yet, I’ve come to appreciate that the most resilient systems often live in the tension between these two ideals. Perhaps the core service endpoints are built with the carpenter’s precision, ensuring data integrity where it matters most. But around the edges, for auxiliary functions like internal metrics or non-critical event logging, the weaver’s flexibility allows for the organic experimentation and adaptation that keeps a system alive. The art, I suspect, lies not in choosing one over the other, but in knowing which tool—the square or the loom—is right for the joint you are trying to make.

Notes & further reading

A few pages I came back to while writing this: