The Architecture Was Correct. The Decision Wasn’t.

Let me give you a situation.

You have 7 engineers and around 11 months of runway. You have a few paying customers, but you are still not sure whether you have product-market fit. Your biggest customer wants an important feature in the next 8 weeks.

Now your engineering team proposes this architecture:

• Microservices
• Kubernetes
• Event-driven communication
• Separate databases
• Independent deployments
• Autoscaling
• Multi-region support
• Proper observability

Technically, it looks great.

It can scale. It is resilient. Different services can be deployed independently. One failure will not bring down the complete system.

But, there is just one small problem:

Your company does not need any of this right now.

Your system may survive 10 million users. But your business may not survive the next 10 months.

That is how a technically correct architecture becomes the wrong business decision.

Technically correct does not mean correct

When you review an architecture, you normally ask these technical questions:

1. Will it scale?
2. Is it secure?
3. Can you maintain it?
4. What happens when one service fails?
5. Can different teams work independently?

These are good questions. You should ask them. But there are a few other questions that are just as important:

• How much will it cost to build?
• How much will it cost to operate?
• How many engineers will be busy maintaining it?
• What will you not build because your team is working on this?
• When will this architecture actually start giving you value?

And the most important one:

• What happens if your business assumptions are wrong?

You can build a perfect system for a future that never arrives.

The architecture is technically correct. Your timing is not.

You are not really choosing an architecture

You are spending your company’s limited resources.

Every architecture decision costs something:

• Engineering time
• Money
• Calendar time
• Team attention
• Hiring capacity
• Future flexibility

So when you approve an architecture, you are not just approving some boxes and arrows. You are deciding where your company will spend its next six months. This is why architecture is also a business decision.

The problem is that technical benefits are easy to see.

You can see

• Better isolation.
• Separate services.
• Clean boundaries.
• A lovely diagram that will look great in a presentation.

But the business cost is usually hidden.

You do not see

• The customer feature that was delayed.
• The engineer who will be fixing deployment pipelines at 2 AM.
• The extra meetings needed because one change now touches five teams.
• The candidate you could not hire because your stack became too specialised.

You only see these things later.

And by then, changing the architecture has become another large project.

Let’s look at some real-world examples next.

Segment had more than 140 services

Segment is a good example because its original decision was not stupid.

It separated different destinations into different services. This gave the team isolation. A problem in one destination did not have to affect everything else.

It worked.

Then the number of destinations kept growing.

Eventually, Segment had more than 140 services. Shared library changes had to be tested and deployed across many services. Versions started moving apart. Small changes that should have taken a few hours could take days. Engineers were also being paged when smaller services suddenly received traffic spikes.

Segment later combined those services into a single service. After improving its test setup, it could run tests for all its destinations in milliseconds. One engineer could deploy the complete service in minutes.

Now, it would be easy to look at this story and say:

“Microservices are bad. Monoliths are good.”

That is NOT the lesson.

Segment itself said that the original architecture worked for some time. It solved a real problem.

The issue was not that the architecture was always wrong.

The issue was that the company kept paying for it after the cost became higher than the value.

An architecture can be correct when you choose it, and wrong two years later.

But architecture decisions rarely come with an expiry date.

Once something is called “our architecture”, people start protecting it like a family member.

Shopify has another interesting example

Clean boundaries can also become a trap.

In Shopify, it worked on dividing its large monolith into cleaner packages with proper boundaries. On paper, this made complete sense.

Clean domains. Clear dependencies. Better isolation.

Who would say no to that?

But Shopify later wrote about how this ideal model did not match how its code actually worked. Its team spent months trying to isolate even one package. After completing much of the planned work, the code still could not run properly on its own.

The team realised that the tool and the target architecture were pushing it towards an ideal picture, not necessarily towards useful results.

This is something you should be careful about. Sometimes you start with a real problem. Then slowly, without noticing it, the architecture itself becomes the project.

You stop asking:

“Is this helping us ship?”

You start asking:

“How close are we to the ideal dependency graph?”

You stop solving the customer problem.

You start solving the diagram.

Do not confuse modern with better

There is also a strange belief in our industry that newer architecture is automatically better architecture.

Monolith sounds old.

Microservices sound modern.

Kubernetes sounds serious.

Serverless sounds efficient.

Event-driven sounds scalable.

But these words do not tell you whether the decision is right.

GitHub has continued to operate a very large Ruby on Rails monolith. GitHub has described it as nearly two million lines of code, with more than 1,000 engineers working on it and around 20 deployments per day.

This does not prove that you should build a monolith.

It proves that the label alone tells you almost nothing.

A monolith can be fast to change.

Microservices can be tightly coupled.

A modular system can be difficult to operate.

A messy-looking system can be extremely useful.

Your architecture should be judged by what it allows your business to do.

Not by how impressive it sounds when you explain it to another engineer.

The real problem is the objective

Your architecture is normally designed to optimise something.

Maybe you are optimising for scale.
Maybe reliability.
Maybe team independence.
Maybe development speed.
Maybe cost.
Maybe security.

The mistake happens when you optimise the wrong thing.

Imagine that your biggest risk is not traffic.
Your biggest risk is that nobody wants your product.

In that situation, building for massive scale does not reduce your biggest risk.

It may increase it.

You are spending time protecting yourself from a future outage while ignoring a current product problem.

The system becomes safer. The company becomes less safe.

Ask whether the pain is real

Before you approve a major architecture project, ask a very simple question:

Are you solving pain that exists today, or pain that you imagine may exist later?

Future planning is important. But there is a big difference between preparing for a likely problem and building a complete solution for a possible problem.

You may believe you will have ten engineering teams next year.

Great. But…

1. Do you have a hiring plan for those teams?
2. Do you have the budget?
3. Do you have the revenue?
4. Is your current team actually blocked because people cannot deploy independently?
5. Or are you building an architecture for an organisation that currently exists only in a Google Sheet?

Do not build for ten teams just because one day you might have ten teams.

Build in a way that does not make ten teams impossible.

That is a much cheaper goal.

Count the complete cost

Most architecture proposals include the cost of building the new system.

They rarely include the cost of owning it.

You also need to count:

• Monitoring
• Deployment systems
• Security updates
• On-call work
• Testing
• Infrastructure
• Documentation
• Team training
• Cross-service debugging
• Dependency upgrades
• Extra coordination
• Hiring people who understand the stack

And then there is the biggest cost - the work you will not do.

Suppose six engineers spend six months moving your system to a new architecture. That is not only 36 engineer-months.

It may also mean six months without an important customer feature.
Six months without testing a new market.
Six months without improving onboarding.
Six months without fixing retention.

The architecture may save you money three years later.
But will the business still exist three years later?

This is not an argument against long-term thinking. It is an argument against pretending that time is free.

Ask what must become true

For every large architecture decision, ask:

What must become true for this investment to pay us back?

Maybe you need to reach a certain level of traffic.
Maybe you need five independent teams.
Maybe the infrastructure cost needs to cross a certain number.
Maybe you need customers in several regions.
Maybe regulations require stronger isolation.

Write these conditions down.

Do not say:
“We will need this when we scale.”

That sentence can justify almost anything.

Say:
“This becomes valuable when we have five teams deploying independently, or when traffic reaches this level, or when infrastructure cost crosses this amount.”

Now you have something you can review.

Without that, “scale” is just a magical future place where every expensive decision becomes correct.

Always keep a simpler option

Whenever you review an architecture, compare it with at least one simpler option.

Not a fake option that is clearly terrible.
A serious simpler option.

• Can you improve the existing system?
• Can you separate only one part?
• Can you use a managed service?
• Can you delay the decision for six months?
• Can you create better module boundaries without splitting the deployment?
• Can you first fix your tests, ownership, or release process?

Sometimes the architecture is not the real problem.

• Maybe your teams cannot move independently because product decisions are centralised.
• Maybe releases are slow because testing is bad.
• Maybe incidents are painful because ownership is unclear.

You can split the system into 100 services and still keep all these problems.

You will just have 100 places to experience them.

Make the exit cheap

You will make wrong assumptions.

I will make wrong assumptions.

Your team will make wrong assumptions.

This is normal. The dangerous decision is not always the one that can fail. It is the one that becomes extremely expensive to reverse.

So ask:

• How will you undo this?
• Can you move gradually?
• Can you run both systems for some time?
• Will your data become difficult to move?
• Are you depending on skills that only one engineer has?
• Can you delete this architecture if the product changes?

The best early architecture is often not the one that supports every possible future.

It is the one that is easiest to change after you learn which future is real.

Architecture is a bet

Every architecture diagram contains assumptions.

You are making assumptions about:

• Traffic.
• Team size.
• Customer needs.
• How long will the product exist?
• What will become expensive later?

The problem starts when you treat those assumptions as facts.

So the next time you review an architecture, do not only ask:

• “Is this technically correct?”

Also ask:

• “Correct for which company?”
• “Correct at what stage?”
• “Correct for which problem?”
• “And correct at what cost?”

Because your system can be scalable, secure, and beautifully designed.

And still be the wrong thing to build.

Thanks for reading! This post is public so feel free to share it.