The moment that exposed the gap
Interviewer: "So, can you tell me some common Software Patterns?"
I sat silent for 15 seconds. Not because I don't design systems—I do, every day, at a Fortune 50 company. But because when he offered one word—"Hexagonal"—I realized he was asking about a pattern that assumes one team owns all layers.
In my world, ten teams own ten layers. I don't build hexagons. I build organs in a larger organism. And the pressure I feel isn't about keeping layers clean in one codebase or an application—it's about keeping my layer stable while the rest of the organism keeps evolving without me.
I answered, "I don't know any." But what I meant was: "The vocabulary doesn't fit my reality."
Two different kinds of architectural pressure
Architectural design centers around one thing: can what you're building withstand pressure—both vertically and horizontally?
Vertical Pressure
Academic patterns describe a vertical stack. This assumes one team, one codebase, all layers. The pressure is: can we keep layers clean so changes don't ripple through the stack? Without a team accurately addressing this pressure, business logic bleeds everywhere. For instance, a discount rule lives in three places—the UI, the database trigger, and the API mapper. Marketing changes one, forgets the other two, and suddenly customers are being overcharged. That's the kind of failure that erodes trust in your system.
Horizontal Pressure
Enterprise reality is a horizontal organism. Ten teams, ten layers, one organism. The pressure is: can we keep our layer stable so upstream and downstream teams don't have to care about our vendor's tantrums? For instance, the vendor changes a field name overnight. Our API parser crashes. The domain team never receives data. Now nobody knows who owns the fix—the integration team, the domain team, or the vendor themselves. Every team owns a layer, and each must handle their own protection so the impact doesn't ripple to the core business.
The difference in one sentence: vertical pressure is about keeping the organism healthy. Horizontal pressure is about keeping your organ alive while the rest of the body keeps moving without you.
That's the gap I felt in that interview. I'd been living in horizontal pressure my whole career, but the only words I had to describe his question were vertical.
Why the vocabulary doesn't fit
Hexagonal. Clean Architecture. DDD. Microservices. These terms all describe vertical architectures. They don't have vocabulary for horizontal realities.
There's no word for: "How do I absorb my vendor's chaos—like a Server IP Address change at 2am—so my upstream teams don't have to care?"
Or: "How do I make my layer invisible yet malleable enough that downstream teams depending on our runner infrastructure for their workflows never even notice an Allow List change?"
The patterns aren't wrong. The question isn't wrong. They're just written for a different world—an academic world where one team owns all layers and one codebase holds all concerns.
But that's not the world of a Platform Infrastructure Engineer.
What horizontal pressure actually looks like
Let me paint you a picture.
It's 2:13am. My phone buzzes. Our ingestion pipeline is failing. The vendor—let's call them Vendor X—changed their Allow List IP range without notice. Our runner infrastructure can't reach their API. Downstream teams wake up to failed workflows. Nobody knows who owns the fix because the vendor didn't tell anyone.
I don't build business rules. I don't design domain models. I build armor.
My job is to absorb that vendor's chaos—schema drift, IP changes, rate limits, timeout spikes—so the domain team never even knows it happened. If I do my job right, their team wakes up to a successful deployment. If I fail, they, including us, wake up to a P1 incident and post-mortem a week before Black Friday Sales.
That's horizontal pressure. Not purity. Survival.
So what do we call this?
I don't have a tidy answer. I don't think there is one yet.
Maybe it's "boundary architecture." Maybe it's "integration architecture." Maybe it's just "infrastructure ingestion." But whatever we call it, it needs a name—because until we name it, we can't talk about it. And until we talk about it, we can't teach it.
Consider the classic question: "Do we buy this vendor's tool, or do we build our own?"
In academic terms, that's a procurement decision. In horizontal reality, it's an architectural survival decision.
If we buy, we absorb the vendor's chaos—their IP changes, their schema drift, their rate limits, their downtime. If we build, we own the maintenance, the bugs, the on-call rotations, and the feature requests from downstream teams.
Either way, the pressure is the same: Can my layer survive the decision I'm about to make?
The patterns we have don't give us vocabulary for this. They describe the shape of a system, but they don't describe the stress of living in one layer of a distributed organism—or the financial and operational weight of choosing which chaos to absorb.
We need vocabulary that acknowledges that most of us aren't building the whole hexagon. We're building one facet. And the pressure we feel isn't just about keeping the layers clean—it's about keeping our layer alive while the rest of the body keeps moving without us.
So what now?
I still don't know if I answered that interviewer's question correctly. I assume I didn't cause well I didn't get the job.
I said, "I don't know any." And in a trivia sense, that was true. I couldn't recite the Hexagonal Architecture pattern. I couldn't diagram Clean Architecture layers from memory.
But I knew how to keep a vendor's IP change from becoming my company's P1 incident. I knew how to absorb chaos so the domain team never even knew it existed. I knew how to make my layer invisible—except when it failed.
That's not nothing. That's horizontal pressure. And it deserves a vocabulary.
Maybe you're in that same room someday. An interviewer asks you about patterns. You hesitate. But instead of silence, you say:
"I don't know Hexagonal. But I can tell you what pressure I actually feel every day—and how I keep my layer alive so the rest of the organism doesn't even know there was a problem."
And maybe that's the right answer after all.