Software Architecture: After Infatuation Comes the Shock

In 2014, when I was working as a professional developer at a gaming company with around 25 developers, I heard about microservices for the first time at a conference - and was immediately excited. We were developing a role-playing game in which players guided their character through different worlds, collected loot, and managed their inventory. My idea seemed obvious: a standalone inventory service that managed equipment, cleanly separated from the rest of the application. Different game modes would share this service. Reusable and modern.

So I presented the concept to the CEO. His answer came quickly: “Too complex for what we are trying to do. Not pragmatic enough.” I was frustrated and thought: He has no vision. He does not understand where the industry is heading. What else would you expect from someone who does not look beyond his own horizon at conferences? Today, more than ten years later, I am grateful to him. Pragmatism usually pays off more than enthusiasm. Here is how developers can protect themselves from that trap.

What Happened Instead: Monolith, On Time, Failed

So we built a monolith. The game was finished on time - and still failed because it found no market. No product-market fit. We stopped development.

But that is exactly why the monolith was the right decision. If we had built microservices, we would have reached the same conclusion months later, only with a much higher bill. The distributed architecture would not have made the game better. It would only have made us slower.

And if the game had worked? Then we could have split the architecture later, backed by a proven business model and real scaling needs. Nobody should underestimate how far vertical scaling can take you. Microservices only become necessary at a scale that very few companies will ever reach. Netflix has 2,500 developers working on one product. Many others probably have fewer than 15.

Recognizing the Pattern: Technology Infatuation

What happened to me in 2014 is something I now regularly see with clients. They discover a technology at a conference or in a blog post, get excited, and that excitement grows into conviction. Then something dangerous happens: the solution starts looking for its problem.

The technology changes. In the late 1990s it was Enterprise JavaBeans, in 2005 SOA with the Enterprise Service Bus, in 2012 NoSQL, in 2015 microservices, in 2018 Kubernetes, in 2022 event sourcing. But the behavior stays the same.

One client has been discussing Kubernetes for years, even though their application is stateful and there is no need for horizontal scaling. Another fell in love with event sourcing without ever having a concrete problem to solve with it. The enthusiasm is steady. The right context often is not.

When Event Sourcing, Kafka, and Microservices Replace the Feature

This became especially clear to me at another company that wanted to rebuild its existing product. The old software was too inflexible, and development cycles were too long. A small team of five full-stack developers started the rebuild - and reached for the big toolbox: event sourcing, Kafka as the message broker, Kubernetes for infrastructure, plus a microservice architecture.

The result after 18 months: hardly any productive features. The team had massively underestimated the complexity. Event sourcing - the idea of storing every state change as an event instead of only storing the current state - sounds elegant in conference talks. In implementation with a five-person team, however, the effort multiplies with every iteration: projections must be built and maintained, event migrations are expensive, and debugging becomes archaeology through layers of past state changes.

The technical enthusiasm in the team was still high. The technology was interesting, and learning was fun. What was missing was reflection: Does this bring us closer to the goal? In the end, the company stopped the project. Not because of the technology choice alone, but the technical dead end accelerated the decision significantly.

What would the alternative have been? With a simpler architecture - a modulith, a relational database, a simple deployment pipeline - the team would have had something demonstrable after three to four months. The insight that the product did not fit the company strategy would have come much earlier, and the decision to stop the project would have cost only a fraction as much.

What 18 Months of Overengineering Cost

Let us do the math. Five developers, 18 months of development time. There are around 220 working days per year, so about 330 working days per person over 18 months. At a realistic cost rate of 700 euros per developer day, that gives us:

5 developers x 330 days x 700 euros = 1,155,000 euros.

More than one million euros. For a project that produced hardly any usable features.

What would a pragmatic approach have delivered in the same time? A working product after a few months, real user feedback, data-based decisions instead of assumptions - and above all the ability to recognize early whether the product had a future.

The visible costs are one thing. The invisible costs weigh more heavily: delayed market feedback, postponed strategic decisions, missed opportunities. This accidental complexity does not arise from bad intent. It arises from a technology decision that obscured the view of the product.

Why Even Smart Developers Fall Into the Trap

Technology infatuation is not a sign of incompetence. Quite the opposite. It is often the best developers who go to conferences, read blog posts, and want to try new technologies. The problem is not curiosity. The problem is missing corrective forces.

The Conference Effect

Conference talks show success stories. They show how a technology solved a specific problem. What they rarely show are the surrounding conditions: team size, budget, years of prior work. A 45-minute talk cannot transport that context. What remains is enthusiasm without classification.

Resume-Driven Development

New technologies make CVs more attractive. Anyone who can show Kafka and Kubernetes in their profile gets more recruiter messages. That is not malicious. It is a rational incentive - but one that works against the company’s interests when the technology does not fit the problem.

Social Proof

“Netflix does it too.” Yes, with thousands of developers, millions of users, and an infrastructure budget larger than the revenue of most companies. Referring to the big players sounds convincing, but it completely ignores the context.

Underestimated Vertical Scaling

How far can a well-built monolith go? A single application on modern hardware can easily serve tens of thousands of concurrent users. But the scaling problems that microservices solve never occur in the vast majority of companies.

Leaders should know this pattern - not to blame developers, but to create the right counterweight. Everyone who develops software should honestly ask themselves: Am I solving a problem for my employer, or a problem for my CV?

What Helps Instead: Pragmatic Decision Culture

Technology enthusiasm is not the problem. Missing reflection and missing decision culture are.

One simple question helps me before I propose a technology: Am I solving a real problem with this, or am I looking for a problem for my solution? If I cannot describe the problem in two sentences, the technology is probably not the answer. That sounds banal, but it would have saved me from the microservice idea in 2014.

Leadership is just as important. My CEO made and explained a clear decision back then. That was frustrating, but it worked - because even a no gives the team clarity. A clear “We are not doing this because our priority is feature delivery” is better than months of discussions without a result. Endless technology debates cost more than the supposedly wrong decision.

What I also keep seeing with clients: new technology is discussed before the basics are in place. Automated tests are missing, the deployment pipeline is fragile, monitoring provides little insight, release cycles stretch over weeks. New technology on a shaky foundation does not make the foundation more stable. It makes it more expensive.

A pragmatic sequence looks different:

1. Name the problem. Which concrete business or delivery problem should the technology solve?
2. Check the simplest viable solution. Would a modulith, a relational database, or a better deployment pipeline be enough?
3. Assess operating cost honestly. Can the existing team run the solution over time?
4. Explain the decision. A clear no is better than months of technology debate.

Technology may come. But only once the need is proven, not because it sounded good at a conference.

Why the CEO Was Right

The CEO of my gaming company did not make a technology decision in 2014. He made a business decision: We do not yet know whether this game works, so we build it in a way that lets us find out quickly. He was right.

Technology decisions are business decisions. Anyone who forgets that builds architecture for the CV instead of for the product. A team that receives a clear decision can focus on what helps the product. A team that discusses technology for months cannot.

The best architecture is the one you do not need today and can still build tomorrow.