For the first few years of my career, I believed software architecture was an optimization problem.
Surely there had to be a best design.
The best database.
The best deployment model.
The best integration strategy.
If we could analyse the requirements carefully enough, involve experienced engineers, and spend enough time designing the solution, we would eventually discover the right architecture.
It was an attractive belief.
It was also wrong.
I didn’t realise how wrong until I found myself leading the architecture of Cyberspace Networks’ first payment gateway.
That project changed how I think about architecture to this day.
Looking for the Right Answer
Like many architects early in their careers, I wanted certainty.
I wanted decisions I could defend for years.
I wanted designs that nobody would question.
I wanted to build systems that would simply work.
As architects, we often imagine our role is to eliminate problems before they appear.
But payment systems have a habit of exposing flawed thinking.
Because payments don’t care how elegant your diagrams are.
Money either moves correctly.
Or it doesn’t.
The First Reality Check
When we started building the payment gateway, the technical work was exciting.
We designed the platform.
Defined interfaces.
Planned integrations.
Discussed security.
Reviewed performance.
Everything looked logical.
Then the real questions started arriving.
What happens if the payment provider accepts the transaction but the response never reaches us?
Do we retry?
If we retry and the customer has already been charged, we create duplicate transactions.
So don’t retry?
Now legitimate payments may never complete.
What if we wait?
Customers begin calling support because they don’t know whether their money has disappeared.
Every answer solved one problem.
Every answer created another.
That was the moment I realised I wasn’t solving technical problems anymore.
I was balancing consequences.
Every Decision Creates a New Problem
One of the biggest misconceptions about architecture is that good architects remove trade-offs.
The opposite is true.
Good architects expose them.
Every decision gives you something.
Every decision takes something away.
Retry transactions.
Gain reliability.
Increase the possibility of duplicates.
Fail immediately.
Reduce duplicate processing.
Increase customer uncertainty.
Wait for confirmation.
Improve accuracy.
Reduce responsiveness.
None of these decisions are wrong.
None of them are perfect either.
They’re simply different compromises.
That was one of the most important lessons of my career.
Architecture is not about finding the best answer.
It’s about choosing the consequence you are most prepared to manage.
The Questions Changed
Something interesting happened after that project.
I stopped asking:
“What’s the best architecture?”
Instead, I started asking different questions.
What problem does this decision solve?
What new problem does it introduce?
Who carries the risk?
Can the business live with that risk?
Those questions completely changed the quality of my architecture decisions.
Not because I suddenly became smarter.
Because I stopped pretending perfection existed.
Years Later, The Same Lesson Returned
Many years later, while leading the PostgreSQL migration for a regulated medical platform, I encountered exactly the same principle.
The technology had changed.
The industry had changed.
The regulations had changed.
The lesson hadn’t.
Should we migrate faster?
We reduce delivery time.
We increase implementation risk.
Should we move cautiously?
We reduce technical risk.
We increase delivery cost.
Should we migrate everything together?
Greater consistency.
Greater blast radius.
Should we migrate incrementally?
Lower operational risk.
Longer transition period.
Again, there was no perfect answer.
Only different risks.
Different costs.
Different consequences.
I realised something.
Technology changes.
Architecture principles rarely do.
Why Experience Matters
This is why experienced architects often frustrate engineers.
An engineer asks:
“What should we do?”
The architect responds:
“It depends.”
That answer sounds vague until you’ve lived through enough production systems.
Because architecture is never separated from context.
The right decision depends on the business.
The customer.
The regulations.
The operational maturity of the organisation.
The team’s capability.
The cost of failure.
Remove the context, and the architecture advice becomes meaningless.
Experience teaches you that every architecture decision is attached to a business reality.
The Architect’s Real Responsibility
People often describe architects as problem solvers.
I don’t think that’s quite right.
Architects are decision makers.
More specifically, they are people trusted to make decisions when every available option has disadvantages.
Anyone can choose between a good option and a bad option.
Architecture is choosing between two good options that optimise different outcomes.
Or two imperfect options where neither feels completely comfortable.
That is why architecture often feels uncomfortable.
If every decision feels obvious, you probably aren’t making architecture decisions.
You’re making implementation decisions.
The Framework I Still Use Today
Whenever I face a significant architectural decision, I no longer ask:
“Is this the right solution?”
Instead, I ask three questions.
What do we gain?
What do we lose?
Can the organisation live with what we lose?
Those three questions have helped me more than any design pattern, framework, or technology trend.
Because they force the conversation away from preferences and toward consequences.
That is where good architecture lives.
Final Thought
Looking back over nearly two decades, from payment gateways and financial platforms to core banking systems and regulated medical software, I have reached one conclusion that has remained remarkably consistent.
There has never been a perfect architecture decision.
Not one.
Only thoughtful decisions.
Only informed compromises.
Only trade-offs made with incomplete information and competing priorities.
The architect who spends their career searching for perfect solutions will always be disappointed.
The architect who learns to understand trade-offs will build systems that survive the real world.
Because architecture has never been about perfection.
It has always been about judgment.
And perhaps that’s the most important lesson architecture ever teaches us.