Your Microservices Charge an Executive Function Tax

You open Grafana. Fourteen dashboards. Three queues “nobody remembers who created.” An alert firing in #incidents while someone asks on Slack what the correct deploy path is for billing in staging.

You’re not debugging. You’re rebuilding a mental map.

That’s not lack of experience. That’s architecture that externalized complexity into your head.

The tax that doesn’t show up on the spreadsheet

When we talk microservices, we talk scale, team autonomy, independent deploys. All true.

What rarely makes it onto the ledger is mental state.

Every new service brings an API contract, a queue, per-environment config, a pipeline, an owner (or no owner), a debug path when things go wrong. It’s not a line on the architecture diagram. It’s a whole package someone has to hold in working memory to operate the system safely.

Cognitive psychology calls part of this extraneous load — effort spent not on the problem itself, but on the bad packaging. Sweller and others have been talking about this for decades in learning contexts. On a distributed platform, the “bad packaging” often has a nice name: best practice.

Microservices without governance become cognitive debt. Compounding. No visible interest until the day nobody knows how checkout talks to inventory without opening six repos and asking on Slack.

Context switching isn’t “just distraction”

Mark, Gudith, and Klocke measured this in 2008: interruption in digital work increases stress and time to resume the task. Not productivity-coach opinion — data.

Distributed debugging is serial interruption. You don’t read a stack trace. You hunt trace IDs across services, correlate logs, discover the timeout came from a config that only exists in staging’s values.yaml, ask who touched the queue — and when you get back to the original bug, half the context is gone.

That’s permanent dual-tasking: fix the incident and rebuild the mental model of the system at the same time.

For people with ADHD or a tighter working memory budget, the cost isn’t linear. The system punishes anyone who already needs more external structure — but it degrades everyone trying to keep three flows in their head while the pager goes off.

Cognitive accessibility isn’t just contrast on the customer-facing site. It’s how many services you force a human to simulate mentally before their coffee gets cold.

What I call a complexity budget

Teams have a cloud budget. Headcount budget. Sometimes even a “technical debt” line on a slide.

Almost never a cognitive complexity budget.

Here’s how it works: every architectural decision spends invisible points from the team’s capacity to understand, operate, and evolve the system.

New service coupled to three more? Points.

Another way to configure an environment? Points.

“Easier to ask on Slack”? Points — and high interest, because tribal knowledge doesn’t scale and goes on vacation with the person who had it.

Feature flags across twelve services with no catalog? Points.

Generic observability — fifty metrics, zero opinion on what matters? Points.

Nobody needs to formalize this in Excel on day one. But you need to stop treating complexity as external to design. It’s not a side effect. It’s first-class material.

What actually helps (without romanticizing the monolith)

I’m not selling “go back to the monolith” as a religion. Distributed makes sense at real scale.

What doesn’t make sense is distributing without compressing what humans need to know.

A service catalog someone actually maintains. Preferably derived from code where you can — Backstage with a plugin that reads the real repo, not aspirational YAML alone. Clear boundaries: who owns it, what’s in, what’s out, which queue talks to whom.

Opinionated observability. Summary dashboard → drill-down. Alerts that point to the runbook in git, not “ask in the channel.” Alert fatigue isn’t just sensory noise — it’s pure cognitive load.

GitOps or a single source of truth for config. If staging and prod diverge somewhere nobody documented, you exported complexity to the brain of whoever’s on call.

Runbooks versioned next to the code. “Just ask on Slack” is an internal API with infinite SLA and hallucinated documentation.

RFCs with an explicit question: how many mental models are we adding? Who pays that bill six months from now?

That’s not kindness. That’s engineering.

Backstage — and the day the catalog lied

Worth talking about Backstage, because it’s the most complete example the industry has of “let’s organize this mess.”

On paper, it solves half this article: system catalog, ownership, dependencies, links to Grafana, the repo, the runbook. One place. Source of truth. The dev stops rebuilding the mental map from scratch every on-call shift.

It works. When it works.

The problem is what happens when the catalog becomes a second source of truth — hand-typed metadata, a catalog-info.yaml someone forgot to update in the PR, one wrong word in a descriptor, an owner who changed teams but nobody touched the YAML.

On a normal day, nobody notices. Backstage shows a beautiful page. Confident. Lying.

On Black Friday — or that Friday 6pm deploy that shouldn’t have shipped but the manager said it was urgent — the mental map everyone trusted blows up. Because the catalog didn’t reflect the system. It reflected what someone thought the system was three sprints ago.

That’s not a Backstage failure. It’s a model failure: metadata as truth without enforcement.

I’ve done the other thing twice — a Backstage plugin that didn’t trust the pretty YAML. It mapped from code. Repo, pipeline, OpenAPI in the repo, whatever was actually there. Raw truth.

If the code was broken, the mapping broke with it. The catalog went red, or disappeared, or screamed in CI. Ugly. Honest.

Everyone knew before the pager, not after.

Metadata isn’t useless. Some things code doesn’t carry: business owner, criticality tier, SLA, incident channel link. That needs YAML or some explicit record.

But everything that already lives in code — service name, real dependencies, API contract, deploy target — shouldn’t be re-typed by a tired human on a Friday. Humans forget. Code doesn’t.

The complexity budget math is simple: a catalog that lies is cheap day to day and expensive during an incident. A code-derived catalog costs more upfront. It pays dividends later.

If you have Backstage and still depend on “remember to update catalog-info” — you didn’t buy a catalog. You bought Notion with a Spotify skin.

The question missing from the RFC

Before approving another service, ask it straight:

How many more bits of context does every dev on the team need to carry to avoid breaking production on a Friday?

If the answer is “oh, they’ll learn” — you don’t have architecture. You have a bet.

If the answer is “we document it” — show me where. In the repo. Linked from the alert. Versioned.

If the answer is “just one more small microservice” — count again. Small on the diagram, large in someone’s head.

Closing

Cloud scaled. Deploy scaled. Slack scaled.

Developer working memory — didn’t.

Treating microservices as zero cost to understand is the same category of mistake as treating an inconsistent API as an “implementation detail.” Except the bill shows up as burnout, long incidents, and good people leaving because “nobody here ever knows where anything comes from.”

A complexity budget doesn’t need to become a corporate framework tomorrow.

It needs to become an honest question at the next architecture meeting.

And if someone laughs — ask again. People who laugh usually aren’t on call.

References

• Mark et al. (2008) — The cost of interrupted work
• Sweller — Cognitive Load Theory (overview)