Archives

Assembly load failures after every deploy — and slots don't fix it. Why the warm-up probe was blind by design, and what a health check actually buys you.

Timeouts, retries, circuit breakers, backpressure — you can add all of them and be less reliable. Classify the failure first, or the pattern is decoration.

Analysis paralysis and "just start typing" are both answers to a question nobody asked. Design in proportion to reversibility — and spike for the rest.

A Design Authority gives teams architectural consistency without the bureaucracy — but only with executive teeth and a deliberately light touch.

The strangler fig is the safe way to replace a legacy system, not the easy one. What decides it: the seam, the system of record, and whether you finish.

Most architecture problems are people problems in disguise. Why shared context — not tooling — is the real constraint, and the only lever that moves it.

Observability isn't free — sampling, cardinality and retention are all decisions. How to buy the signal you need without paying for the noise you don't.

A deployment keeps failing intermittently and Azure is the suspect. How to prove it's the platform, not your code — and how to know when you've proven it.

Eventual consistency sounds like an excuse for wrong data. In the language of money, letters and obligations, it's just how the business already works.

“Exactly-once delivery” is a promise no broker can keep. What you actually get — and can build on — is at-least-once delivery plus idempotent consumers.

Saving to your database and publishing a message look like one step. They're two, and the gap between them is where you lose data. The outbox pattern closes it.

Observability isn't an ops bolt-on you add after go-live — it's an architectural decision you make at design time, or pay for in the dark later.

Azure's defaults optimise for working in five minutes, not being safe in five minutes. The secure posture is opt-in — and closing that gap is your job.

A feature flag looks like an if statement with a dashboard. It's really an architectural decision — you've split deploy from release and made it reversible.

A forty-year-old piece of security maths that tells you whether to fix a risk, insure it, avoid it, or live with it — and how to show your working.

Nobody got fired for adding another control. But security you can't afford to run, or that everyone routes around, isn't security — it's theatre with a budget.

Zero-downtime isn't a feature you switch on — it's a property you design for, one backwards-compatible step at a time, using expand/contract.

When a digital transformation stalls, everyone blames the tech. The real barriers are almost never technical — and pretending otherwise is how you keep failing.

Underneath three interchangeable-sounding buzzwords is a single architectural decision: where should the work live, and who owns the outcome when it goes wrong?

We hunt for the person who was unethical and rarely find one — because most of what a system does to people was designed in at the whiteboard, not acted out.

A C4 diagram shows you every box and every arrow in a system — and stays completely silent on the only questions that matter when someone comes to change it.

Two teams build the same feature list and ship completely different systems — because the non-functional requirements, not the features, decide the shape.

I wrote off enterprise architecture as big-company ceremony — until a greenfield rewrite with no governance changed my mind, and not the way vendors would like.

Contract testing lets you decouple deploys by sharing a spec, not a code package — each side proves it honours the contract on its own, without the other running.

You split into services so each could ship alone. Then a shared contracts package quietly stitched the deployments back together — that's deployment coupling.

Deferring a decision isn't dodging it. The last responsible moment is the point past which waiting costs you an option — so decide then, not before, not after.

Taught that duplication is the enemy, we abstract too early. But the wrong abstraction costs more than the duplication it replaced — and is far harder to undo.

An architecture fitness function turns a design rule from a wish into a test that fails the build when it's broken — and the best ones steer, not just forbid.

There's no 'right' architecture to find and lock in — only one that fits the forces on you now. The real job is keeping it able to change when they shift.

The decision is the cheap part; the reasoning behind it is what evaporates. Architecture decision records are a small, deliberate defence against that loss.

An anti-corruption layer is sold as a wall against a vendor's mess. It's really a double-sided socket — the same seam lets you swap either side independently.

Drawing module boundaries where the business already cut them assumes the business decided where. Often it hasn't — and that unmade decision is the architect's job.

The microservices-versus-monolith war is tired. The systems I've actually shipped are usually a bit of both — and on purpose.

Every time you turn a function call into a network call, you start paying a tax. Worth it sometimes — but know the bill before you sign up.

The two ideas from Domain-Driven Design you can actually use on Monday — where to draw your boundaries, and what you can change in one go.

The cheapest insurance against someone else's mess leaking into your codebase — and why changing payment vendors three times didn't hurt.

Not every decision deserves the same agonising. The trick is telling two-way doors — the ones you can walk back through — from one-way doors you can't.

Conway's Law in practice: your system will look like your org chart whether you like it or not — the only question is whether you planned for it.

We obsess over making things easy to add. The systems that age well are the ones where things are easy to remove.

The most honest two words in architecture — why every decision is a trade-off, and the real skill is finishing the sentence.

Why I've finally got round to starting a blog, and what I plan to write about here.