AI Translated Document

This document was translated using an AI translation tool.
Due to the nature of AI translation, some sentences or terms may be interpreted differently from the original intent.
There may be mistranslations or inaccuracies, so please refer to the original text or consider additional review if accuracy is critical.
Your suggestion for a better translation would be highly appreciated.

Original Document in Korean

Software Architecture Is Determined by Invariants, Not Extensibility¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
Draft: July 2022 / Revised: November 2025

[Interpretive Note] This article was written to prompt reconsideration of the real costs that arise when current structural constraints are blurred for the sake of “future extensibility.”

Executive Summary¶

Many people emphasize extensibility when introducing an architecture.
But in reality, what determines the lifecycle—or "death"—of an architecture is what cannot be easily changed (invariants).
For example, MSA (Microservices Architecture) is often highlighted for its ability to split systems into independently scalable services.
MSA necessarily involves network processing between services.
There is also a principle that each service must own its own data.
If you don't follow this, you pay the costs but gain none of the benefits.
Therefore, the core of architectural choice is not what extensibility you will have, but what costs you are willing to pay.
Never pay a price you cannot afford.
By its nature, MSA inevitably has higher network and CPU usage for the same computation.
The flexibility in deployment comes with coding constraints—costs are paid from the start.
You must have management staff to handle dynamic deployments to reap the benefits.
This means that for small-scale services (e.g., under 5 AWS EC2 8vCPU/32GiB machines + load balancer), MSA is unlikely to have a good ROI.
Netflix did not start with MSA. They switched when their existing structure reached its limits.

What Is Extensibility?¶

Extensibility is the ability of a system to flexibly add resources or change structure to handle increased load, data, or user demand without performance degradation. For example, adding servers when users surge, or integrating with new external systems—it's the ability to respond to unforeseen variability.

But every mechanism comes with inseparable drawbacks and costs due to its unique characteristics.

What Are Invariants?¶

Invariants are constraints in system structure or operation that cannot be easily changed—"structural limits." For example, in a pipeline architecture, you can easily swap out individual pipe blocks, but you can't discard the start-to-end pipe structure itself. Changing the data format flowing through the pipes is also hard, since it's a contract all blocks must follow—changing it means total loss of compatibility. Compared to this, changing a linear pipe to a T-junction is a smaller problem.

Architecture Lifecycle¶

The architecture lifecycle covers the entire process: design, adoption, operation, change, and retirement. Code is easier to modify than physical assets, and refactoring techniques have advanced. But every architecture has a backbone that supports the whole system, and breaking that backbone is hard.

So, when requirements collide with the architecture's invariant constraints, radical change becomes impossible—and that's when the architecture approaches "retirement."

Netflix did not start with MSA. They switched when their existing structure reached its limits.

The Cost Structure of MSA¶

MSA has very high fixed costs. Marketing calls it "flexible deployment," but honestly, it's "random deployment." We can't predict where users will flock. So MSA starts with a backbone to handle "random deployment." From the start, you can't share data between unit services—every data fetch has a cost, and transactions (like rollbacks) are only valid within a service. Simple function calls (memory address jumps) become network transmissions, and you must account for the latency and cost. To scale databases per service, you must manage many small databases and storage systems, or the whole system's availability is limited by DB specs. Backup and restore management is also a cost. To recoup these costs, you must have management staff on hand. Automation of deployment and operations is not a benefit, but a necessary result to recoup costs.

If you use MSA at small scale, you may face 3x development costs and 5x operating costs.

The ROI Structure of MSA¶

For MSA to achieve ROI, you must bear relatively high fixed costs even for the same computation, so the system must deliver high added value.

In other words, you must leverage brand value to sell at a higher price than the minimum cost of potential competitors.

Since all internal processing has network overhead, you must be tolerant of latency.

So, you should not build a stock trading system with MSA.

MSA can be deployed across continents, but in that case, you must be 10x more tolerant of latency.

You may have many fragmented small databases, but each store's workload is simple, making optimization and distribution easier. But you also need enough DBAs to handle this.

Even if you auto-scale internal service units in the cloud, you need staff to monitor and respond to the network infrastructure.

Especially, only when you have "situations" where demand fluctuates by hour or day does having many management staff become worthwhile.

Comparing with On-Premise economics...

On-Premise has lower development costs, but you must estimate max capacity and maintain that scale 24/7.
MSA has higher development costs, but you can always adjust scale to current demand.

So, unless you can recoup development costs through elastic operations, MSA is not economical.

Can a Small Startup Afford These Costs?¶

Some may say it's possible, but I would never do it.

The structural costs and operational complexity of MSA are hard for small startups to bear. Startups operate with limited staff and resources, and need to enter the market quickly. In this context, MSA's network overhead, data consistency management, monitoring needs, and multiple database management slow development and increase operational burden.

The true value of MSA is realized only with large-scale traffic, frequent service expansion, and many independent development teams. In other words, it's a way for large companies to break up internal elements like specialized small ventures, achieving partial optimization for overall optimization.

But anyone who has studied algorithms knows that greedy strategies don't always work well.

Conclusion¶

Whatever you choose, never pick an architecture for its strengths.

IT systems typically last 5–10 years; assume 7. Architecture is the backbone, and is hard to change for at least 5 years. You can swap out isolated modules, but changing architecture means changing how modules communicate—almost all modules must be modified, and performance characteristics change for each situation.

In reality, variation of architecture is possible, but change is not.

Check List

Check the costs each architecture demands.
Confirm what will not change for at least 5 years.
There are many choices with similar strengths but very different costs.
Only consider architectures whose costs you are willing to pay.

Author¶

HJ, Ph.D. / Software Architect
(js.seth.h@gmail.com)
https://js-seth-h.github.io/website/Biography/

Over 20 years in software development, focusing on design reasoning and system structure - as foundations for long-term productivity and structural clarity.

Researched semantic web and meta-browser architecture in graduate studies,
with an emphasis on structural separation between data and presentation.

Ph.D. in Software, Korea University
M.S. in Computer Science Education, Korea University
B.S. in Computer Science Education, Korea University