Architecture on Maceage's Blog

Conway's Law

Mon, 05 Oct 2026 00:00:00 +0000

(Originally drafted in July 2019 during my tenure at Xero. Republished here in October 2026 with updated context and removed proprietary references)

“A system is never the sum of its parts. It is the product of the interactions of its parts.” — Dr. Russell Ackoff

Every sufficiently large software platform gives its users the impression that it’s a single, unified thing running on unicorns and magic. In reality, it has always boiled down to software running on servers that is developed and managed by people. And those people - how they communicate, where they sit, who owns what - quietly shape the systems they build in ways they rarely notice.

System Design Learnings

Fri, 30 Aug 2024 00:00:00 +0000

As a software engineer who grew up developing desktop applications before moving into web development, I spent most of my career in the depths of application code rather than infrastructure.

Hosting and networking were handled by other teams or companies – my responsibility was writing software that ran on top of that stack, not worrying about the foundation beneath it.

But that landscape has shifted. System design interviews are now ubiquitous in tech hiring, particularly at scale-focused companies. These interviews assess your ability to architect and scale systems – a skill set that’s become as crucial as coding ability itself.

AWS Solutions Architect - Professional

Wed, 03 Jul 2024 00:00:00 +0000

After earning the Advanced Networking Specialty, the Solutions Architect – Professional exam was the natural next rung on the ladder – and, honestly, one of the more demanding ones. It’s less about memorising services and more about knowing which service trade-offs to recommend when a scenario hands you a broken architecture and five ways to fix it.

These notes come from working through the AWS Solutions Architect – Professional path on Pluralsight. They’re organised around the exam’s major themes: data stores, networking, security, migration, scaling, resilience, operations, and cost. I’ve kept them flash-card dense on purpose – that’s how I learn – but I’ve flagged the traps and decision points that seem to show up repeatedly.

Codifying Architecture: Diagrams as Code

Sun, 03 Mar 2024 00:00:00 +0000

(Originally drafted in August 2019 during my tenure at Xero. Republished here in March 2024 with updated context and removed proprietary references)

Engineers love writing code. There’s nothing quite like instantly seeing the fruits of your labour appear on a screen – immediate feedback and the joy of getting something working.

Engineers, however, tend to hate writing documentation. It takes time, it’s seen as overhead to “real work,” and so it falls by the wayside. The next engineer to come along is told: “Oh, that’s out of date – just look at the ‘self-documenting’ code instead.”

The C4 Model: From Attendee to Facilitator

Sun, 25 Feb 2024 00:00:00 +0000

(Originally drafted in December 2019 during my tenure at Xero. Republished here in February 2024 with updated context and removed proprietary references)

In late 2019, I attended a workshop at YOW! Melbourne run by Simon Brown, the creator of the C4 model. It turned out to be one of the most useful conference sessions I’ve ever been to.

What made it valuable wasn’t salesmanship – though you could be forgiven for initially wondering whether you were sitting through a pitch. Simon was excellent at explaining why the format exists, why other approaches tend to fall down, and what C4 offers compared to heavier alternatives like UML and BPMN.

Cloud Design Patterns

Sun, 18 Feb 2024 00:00:00 +0000

Touring the Azure Cloud Design Patterns Library

29 Patterns in 14 Lunchtimes

A few years ago, I ran a Design Patterns Community of Practice at work. Over fourteen sessions, we worked our way through nearly the entire Azure Cloud Design Patterns catalog – one of the best-curated collections of distributed systems wisdom available for free.

This post is the full tour: every pattern we covered, what it’s for, and when to reach for it.