Pick up any book on software architecture. Open any YouTube video on system design. The diagrams all share a visual assumption: components are roughly equal in size, connected uniformly, each deserving roughly the same amount of attention.

Hexagonal architecture shows a hexagon at the centre with evenly-spaced ports around the perimeter. N-tier diagrams show three clean horizontal bands. Microservices diagrams show a grid of similarly-sized boxes connected by arrows:

┌─────────────┐   ┌─────────────┐   ┌─────────────┐
│    Users    │   │   Orders    │   │  Payments   │
└─────────────┘   └─────────────┘   └─────────────┘

┌─────────────┐   ┌─────────────┐   ┌─────────────┐
│  Shipping   │   │  Inventory  │   │   Emails    │
└─────────────┘   └─────────────┘   └─────────────┘

The visual language implies a kind of structural democracy: every part of the system is a peer.

This is a convention of the medium. It is not a description of reality.

What Systems Actually Look Like

Most operations in a real system are simple. Updating a user's notification preferences. Changing a password. Fetching a configuration record. Looking up an account balance. These are, in the main, a read or a write against a well-understood record. They require correctness, but not complexity.

Then there is the dominant workflow: the thing the system actually exists to do.

In a KYC platform, it is onboarding: the workflow that accepts a customer, orchestrates document verification, runs risk scoring, evaluates the results, makes a decision, and notifies downstream systems. In a lending product, it is loan origination: credit assessment, affordability checks, fraud screening, offer generation, acceptance, and drawdown. In a logistics platform, it is dispatch: route optimisation, driver assignment, constraint resolution, live re-routing, and the cascade of updates that follows each change. In an e-commerce system, it is order fulfilment: inventory reservation, payment authorisation, warehouse coordination, shipping, and the unhappy paths for each.

These workflows are not one operation among many. They are the reason the system exists. And they are disproportionately complex: they call external services, manage state across multiple steps, handle failures and retries, enforce business rules, and produce audit trails. A payment flow is not five times more complex than a password reset. It is an order of magnitude more complex.

If you drew a system diagram where the size of each component was proportional to its complexity, it would look nothing like the diagrams in the books:

┌──────────────────────────────────────┐   ┌───────────┐
│                                      │   │  Change   │
│                                      │   │ password  │
│          Order fulfilment            │   └───────────┘
│                                      │
│  inventory · payment · warehouse ·   │   ┌───────────┐
│  shipping · retries · audit trail    │   │  Update   │
│                                      │   │ settings  │
│                                      │   └───────────┘
│                                      │
│                                      │   ┌───────────┐
│                                      │   │   Fetch   │
│                                      │   │  profile  │
└──────────────────────────────────────┘   └───────────┘

Lopsided. Asymmetric. That is the real shape of most systems.

The Mental Model Trap

The diagram convention would be harmless if it were just a drawing shortcut. The problem is that it shapes thinking.

"Be consistent" is, in general, good advice. Applied at the level of function naming, error handling, or test structure, it reduces friction and makes codebases easier to navigate. Applied at the level of architecture, it becomes a trap: the instinct to give every part of the system the same structural treatment, regardless of whether the parts are remotely similar in complexity or purpose.

The result is familiar. Teams extract a service for password reset because they extracted a service for onboarding, and consistency demands uniformity. Simple CRUD operations acquire queues, contracts, and deployment pipelines because the dominant workflow needed them. The small things get pulled upward in complexity to match the big thing, rather than the architecture acknowledging that the big thing is simply different.

Microservices thinking compounds this. The implicit message of the pattern is that every unit of functionality deserves a service boundary, independent deployment, and its own operational concerns. Applied uniformly, it imposes the full coordination tax of distributed systems on operations that would have been a function call. The password reset flow does not need a distributed system. The onboarding workflow might, eventually, if specific constraints demand it.

The uniformity instinct also, paradoxically, under-serves the dominant workflow. When everything is treated as equally important, the complex workflow does not get the focused architectural attention it warrants. The state management, the failure handling, the audit requirements, the retry logic: these deserve careful design. A uniform template applied across the board gives them no more consideration than a settings page.

Asymmetry Is a Feature

Some of the most elegant structures in computing are asymmetric by design, precisely because their designers were honest about the fact that not all positions are equal. A finger tree, for instance, is a data structure built around the explicit acknowledgement that the ends are special and should be treated differently from the bulk. The result is better performance characteristics than a uniformly-structured alternative would produce. The asymmetry is not a compromise; it is the point.

The same principle applies to system architecture. The right response to a lopsided system is not to make it symmetrical by adding complexity to the simple parts. It is to design honestly for what the system actually is: one or two dominant workflows, and a lot of simple operations. The architecture should reflect that.

What This Means in Practice

The practical implication starts before any technology decision. When approaching a new system, the first question worth asking is not "what database should I use?" or "should this be microservices?". It is: what is the dominant workflow? What makes it complex? What external dependencies does it call, what state does it manage, what failure modes must it handle?

Name it. That is the part of the system that warrants careful design. Everything else is likely to fall into place once the domain model is right.

From there, the architecture follows the shape. The dominant workflow belongs at the core, where it has access to everything it needs: the full state of the system, the orchestration logic, the transition guards, the audit trail. The simple operations live there too, as ordinary function calls. They do not need ceremony.

Where the dominant workflow calls out to genuinely heavy compute, those concerns can be extracted: an ML model for document verification, a risk scoring engine, an embedding-based similarity service. These earn their separation on concrete grounds (resource weight or independent deployment), not because uniformity demands it. Everything else stays in the core.

This is the topology described in Strategic Monolith + Satellites: a core that can absorb the complexity the dominant workflow demands, with satellites at the boundary for the work that genuinely warrants separation. The pattern works because it is designed for asymmetry. The core is not one service among peers; it is the place where the hard work happens.

Summary

Real systems are not uniformly complex. They have a shape, and the shape is almost always the same: one or two dominant workflows that account for most of the complexity, surrounded by operations that are largely simple.

The architecture diagrams we inherit do not show this. The mental model of consistency compounds it. The result is systems where the simple things are over-engineered, and the complex thing is under-designed.

Find the dominant workflow. Design for it deliberately. Let everything else be as simple as it actually is.