There are architectural decisions that don't feel like decisions. They don't show up on a board presentation, don't require budget approval, and aren't listed on the roadmap; instead, they happen quietly, embedded in a PR review, a team discussion, or the choice of communication format between two services. These are precisely the decisions that determine if you build a stable product or a fragile toy.
This post looks at two examples: choosing a communication format in AI systems and handling data duplication. These seem like minor technical details, but both trace back to the same core question that defines good architecture: who is the user? Who is consuming the output?
Choosing Communication Formats
When the answer is machines and agents, Markdown and JSON are the kings because they save token costs, fit perfectly into LLM attention mechanisms, and generate clean, predictable communication. But when the answer shifts to humans needing a rich interface, HTML is the right choice, yet it requires extreme caution. Caution is necessary because even if you ignore the risk of injecting JavaScript from an LLM into HTML - which is a direct path to data leaks and XSS vulnerabilities - the principle remains firm: the communication format is an architectural choice, not a personal preference. This isn't just about efficiency or saving money; it’s about building a product that lasts, not just a fragile toy. As the article on 'Who is the user? The question that defines good architecture' explains, this choice impacts operational costs, security, and the system's ability to scale without breaking.
Distinguishing Duplication
And that brings me to the issue of duplication. We also need to stop fearing the DRY principle. This principle is taught early in a career and becomes too sacred, causing teams to avoid any repetition as if it were a sin. But consider Netflix, which serves a show on over 15,000 servers globally. Every site you visit stores static files closest to you. This isn't negligence; it is architecture. The problem starts when teams fail to distinguish between two fundamentally different types of duplication. Bad duplication happens when you reproduce things, like buying the same stickers repeatedly instead of bundling them once. This duplication turns maintenance into a nightmare because you have two sources of truth to synchronize.
Smart duplication happens when you allow consumption multiple times, like scattering stickers around the house - one box by the bed, another in the living room. The product is the same, but it’s accessible where the consumer needs it. The difference isn't technical; it’s conceptual. When teams prioritize engineering dogma over the user, they pay the price in latency, poor user experience, and technical debt. DRY is a tool, not a religious text.
Sacred Principles?
I recently visited a team that avoided adding another database to their product at all costs, to prevent duplication. They could quote DRY in their sleep, but they never asked themselves one simple question: where do we need to use duplication to serve the consumer?
The result of that upfront capitulation: users who wait. Latency that climbs. An experience that wears down. All in the name of a principle that went from a useful guideline to an architectural prison.
This is a repeating pattern: teams treating engineering principles as sacred without re-evaluating them in the context of the product and the user. DRY is a tool, not the Ten Commandments. When it leads you to build a system that serves the code instead of the user, it is time to ask questions.
Think About the Consumer, Not the Code
What do choosing a communication format and handling data duplication have in common? Both are decisions that teams tend to make out of habit or ideology - instead of thinking about who consumes the output.
A team that picks HTML for AI-to-AI communication because "that's what we know" pays the price in tokens, in security, and in stability. A team that avoids data duplication because "DRY is sacred" pays the price in latency and user experience.
In both cases, the business risk is real: the opportunity cost of architecture that doesn't fit the consumer accumulates into technical debt that is very difficult to pay off later.
Good architecture doesn't start with technology. It starts with the question: who is the user, and what do they need?
Takeaways
The architectural decisions that truly determine a product's fate are rarely the ones that arrive with fanfare. They are the quiet decisions - format, duplication, service structure - that accumulate over time.
- Before every architectural decision, ask who the consumer is - a human, a machine, or both. The answer changes everything.
- Re-examine principles that have become dogma - DRY, KISS, YAGNI - in the context of your specific product. A principle that goes unexamined becomes technical debt.
- Smart duplication is a legitimate architectural tool - not a sign of sloppiness. Netflix does it, and you need to know when it is the right call.
Think twice, build once. But make sure you are thinking about the right thing.