Architecture
The language and the decisions of system design.
What Architecture covers
Software architecture is the set of decisions about a system's structure that are expensive to change. This category covers how to draw boundaries, slice components and make decisions deliberately.
What this category covers
- Modular monoliths and microservices
- Event-driven architecture
- Slicing bounded contexts cleanly
- Anti-pattern: the distributed monolith
Solid answers in this field.
In-depth, citable documents — every recommendation with its trade-off, its cost and the case in which we decide differently.
Software That Still Runs in Ten Years
Which engineering decisions keep software viable for ten years — coupling, reversibility, operations, standards — each with its trade-offs.
Reversibility over Prediction
You cannot predict the future — so keep change cheap instead of betting on it. Which decisions to slow down and which to build reversibly.
Business Logic Doesn't Belong in Controllers
Why business rules belong in a framework-independent domain layer, not in the controller: symptoms, maintenance costs, testability, migration.
Mature Technology over Novelty
Choosing technology without chasing trends: why maturity means others already found the bugs — what the new hides, and when it's still right. Context and lifespan.
Modular Monolith vs. Microservices
Not a holy war but a decision about where complexity lives: what a modular monolith really is, and when microservices are objectively the better choice.
Build, Buy or Configure — When Custom Software Pays Off
Build it yourself, buy it or configure it — honestly, even when the answer is 'buy'. The criterion: differentiation and lifespan, hidden costs.
Why Software Projects Really Fail
Software projects rarely fail because of technology, but because engineering decisions become irreversible before the problem is understood.
Server-Side Rendering or SPA
Server-side rendered or SPA — the frontend choice that determines ten-year maintainability. Decided by interactivity and lifespan, not fashion.
Legacy Modernization Without a Big Bang
How to replace a production system incrementally and reversibly instead of via rewrite: strangler fig, anti-corruption layer, data migration, parallel runs.
Taking Over a Legacy System — the First 90 Days
Taking over a system you didn't build: understand before you change, safety nets before the first intervention, the map, capturing the behavior.
When a Rewrite Is the Wrong Decision
Why a rewrite discards embedded knowledge and chases a moving target, when a rebuild is the right call after all — and why incremental is almost always better.
Lessons learned in this field.
Mistakes and what they taught us — anonymized, without drama. The mistake is the teacher.
5,000 Lines of Copy & Paste
An Engineering Story: how roughly 5,000 lines of copied code came about, why nobody noticed the moment duplication became expensive — and what consolidating it to about a tenth taught us about DRY.
That’s a quick job.
An Engineering Story: why a single sentence became a reliable warning sign — and why Batunet now deliberately declines projects that begin this way. On the value of analysis and architecture that cannot be skipped.
Once You Start Copying.
An Engineering Story about the momentum of copying: how a defensible first copy turned into around 5,000 lines of nearly identical code, why the dangerous decision was not the first copy but the missing one the second time around — and what consolidating to roughly a tenth taught us about the right moment.
Real-Time Without a Rebuild
An Engineering Story: a system that had grown over many years suddenly needed to update in real time — a requirement its architecture was never designed for. Why the answer was not a rebuild but the targeted redesign of a single data flow. On the difference between a local requirement and a global overhaul.
Changing Direction Early
An Engineering Story: the plan was to extend an existing system. As the work progressed, it became clear that every additional feature would increase complexity. Instead of sticking to the plan, we changed direction and split features out into standalone APIs. On the cost of defending an outdated plan.
The Prototype That Wasn’t a Product
An Engineering Story: a client only wanted a proof of concept. What emerged was a usable interface. Then the undertaking was discontinued. On the difference between a feasibility study and product development — and why you have to name it from the start.
Software Is Never Finished
An Engineering Story from our longest-running client project: requirements change continuously, software is never finished — and the only robust answer is an architecture that makes change cheap. On letting go of the idea of an end state.
Removing Complexity Instead of Adding It
An Engineering Story: external API components were embedded in the monolith. They were extracted and turned into standalone APIs — resulting in a clearer architecture and independent scaling. Why taking away is often worth more than adding.
New articles in this category are published on an ongoing basis. You can already find the core terms in the glossary.
Go to the glossaryRelated topics.
Guides, decisions, services and case studies connected to this page.
Services
Architecture decisions
A concrete problem in this field?
We don't just solve it on paper. Talk to the engineers who would build it.
