Programming is often seen as abstract mathematics: formulas, logic, zeros and ones, a world of pure ideas with no friction and no gravity. That is partly true. But the longer I design real systems, the more convinced I am that they live by laws strikingly similar to physical ones. They have mass, inertia, load, material fatigue and even something like entropy.
This article is a bit philosophical, I warn you honestly. But out of the philosophy grow quite practical conclusions about why some systems live for years while others fall apart within six months, even though they looked the same at the start.
Logic: a foundation you cannot cancel
Every program rests on logic. If an order is paid, it can be shipped. If an item is out of stock, it cannot be reserved. These rules are absolute inside the system, like the laws of logic in mathematics. Break them, and the system starts producing absurdities: shipping unpaid orders, selling things that do not exist.
The most valuable thing about a system's logic is that it reflects the logic of the business. Not the programmer's logic, not the framework's logic, but the real rules by which the company works. When I talk about architecture, I am first of all talking about how precisely the logic of the code matches the logic of the domain. That is the foundation. Everything else is built on it.
Statics: the skeleton of the system
Every system has a static part. It is the database structure, the set of entities and the relationships between them, the classes and modules of the code and their dependencies on each other. Statics describes what the system is made of, just as a bridge drawing describes its beams, cables and supports.
Statics has a property I call static complexity. The more entities, relationships, layers and dependencies, the harder the system is to learn. A new developer opens the project and sees three hundred tables, a thousand classes and a web of links between them. He needs weeks to understand how it all works. Static complexity makes a system hard to learn.
Part of that complexity is unavoidable: if the business is complex, its model will be complex too. But a large part is born of carelessness. Duplicate tables that appeared because nobody knew about the existing one. Modules depending on each other in a circle. Names that say nothing. This is dead weight the bridge has to carry.
Dynamics: what happens when traffic crosses the bridge
Now the dynamics. This is what happens when the system is running. Data flows, user requests, background jobs, integrations with other services, peak-hour load. A bridge on paper and a bridge with trucks crossing it at rush hour in a crosswind are two different things.
Dynamic complexity makes a system unpredictable. When many processes run at once, interact, wait for each other and compete for resources, effects appear that cannot be seen by looking at the code. Two operations, each correct, together give a wrong result. A system that works perfectly with ten users falls over with a thousand. A bug shows up once a week and disappears as soon as someone starts looking for it.
The nastiest problems in my practice have always been dynamic. A static error is visible in the code. A dynamic one is visible only in motion, and often only in production, under real load, at the worst possible moment.
Resilient dynamics
Bridge engineers have long known a paradox: a bridge that does not bend at all is not the strongest. A rigid structure accumulates stress under wind and load and at some point breaks. A good bridge is designed to bend a little, flex, damp vibrations and return to its original position. That is resilience.
Systems are the same. The art of architecture, in my view, lies in creating what I call resilient dynamics. A system must be able to change without destroying its fundamental logic. A new feature is added, the load grows, a business process changes, and the system flexes and adapts instead of cracking.
How do you achieve that in practice?
- Keep the statics simple: fewer entities, fewer links, clear names. A light bridge is easier to hold up.
- Isolate parts from each other: a change in one module should not ripple through the whole system.
- Protect the logic: business rules should live in one place, not be duplicated in ten, so that they stay unchanged when the load or the interface changes.
- Watch the dynamics: monitoring, logs, metrics. A bridge without stress sensors collapses suddenly, a bridge with sensors gives warning in advance.
- Test under load before the load arrives on its own.
And more
The physical analogies do not end there. Systems have inertia: the bigger and older a system is, the harder it is to change its direction. They have entropy: without constant care any code gradually slides into disorder, like a room nobody cleans. They have material fatigue: decisions that were right five years ago stop withstanding today's requirements.
I am not claiming programming is physics. But the mindset of an engineer who builds bridges is useful to any software architect. It makes you think not only about how a system looks on paper but also about how it will behave in the wind.
That is why we at Ingello pay so much attention to statics: Fractal generates the data and code structure by uniform rules, so the system's skeleton is light and predictable. And we observe and test the dynamics on real data, because only in motion can you see whether the bridge will hold. If you want to understand how resilient your system is, ask not "how is it built" but "what will happen to it if tomorrow the load doubles and the business changes one process". The answer to that question is the real assessment of the architecture.
