Fault Line

The first words of an incident report were "that's not our responsibility."

I get it. But from the user's perspective, the service is one thing. Where the failure happened doesn't matter. It turned into a fight because the boundary was unclear.

The OSI model splits responsibility into seven layers. The physical layer handles cables. The data link layer handles frames. The network layer handles routing. Each layer does its own job and doesn't meddle with the layers above. A beautiful separation. And because of it, you know that asking the L7 team about an L3 failure is pointless. Clear boundaries make triage possible.

API interfaces have the same structure. A line drawn between the sender and the receiver. Past this line is your job. Before this line is mine. Argument types, response formats, error code definitions. All of it is a declaration: responsibility changes here.

The monorepo versus multirepo debate is, at its core, about where to draw the line. Split repos and team boundaries become explicit. Use a monorepo and boundaries blur, but overall consistency gets easier. It's not about which is right. It's about where you want the line.

Projects with clear boundaries triage fast when incidents happen. When bugs surface, you can see where to fix them. Projects with blurry boundaries are the opposite. Everyone worries about everything. Nobody decides anything. When unspoken favors start accumulating between teams, that's a red flag.

This sounds like a technical discussion, but it's an organizational one too. Microservice boundaries are team boundaries. API design is a contract between teams. Conway's Law is correct. System structure mirrors org structure. Designing where responsibility splits means designing the organization itself.

With years of experience as an engineer, you develop a kind of tab completion for where to draw the line. But once you step away from work, nothing you type autocompletes.