Scalable architecture design

What scalable architecture design means

Scalable architecture design is the discipline of structuring a platform's data, application and traffic layers so each can grow, fail over or get replaced without dragging the rest of the system down with it. It sits at the intersection of platform engineering, cloud engineering and system integration: platform engineering builds the internal tooling and environments that make change safe, cloud engineering chooses where and how workloads run, and system integration keeps the pieces talking to each other correctly once they're separated.

For a business running on Xero, a custom order management system and a handful of internal tools, this rarely means adopting the patterns built for global-scale consumer platforms. It means identifying the one or two components that are actually approaching their limits and re-architecting those, while leaving the rest of the stack alone.

Where legacy systems break first

In practice, the first constraint a growing platform hits is rarely raw compute. It's usually a shared database that was never designed for concurrent write volumes, or a monolithic application where every deployment risks every feature at once. Teams attempting staged system decomposition often find the real blocker isn't the code split itself but the data layer underneath it, which is why staged legacy modernisation of the database usually has to run alongside service decomposition, not after it.

Application modernisation projects that skip this sequencing tend to hit a wall six to twelve months in: the services are separated, but they're still fighting over the same database locks, and none of the promised scaling benefit shows up.

Platform engineering, DevOps and SRE aren't the same job

The terms get used interchangeably, which causes confusion when deciding who to hire or engage. DevOps describes practices for shipping software faster and more reliably. Site reliability engineering focuses on keeping systems running once they're live, against defined reliability targets. Platform engineering builds the internal tooling, environments and standard patterns that make both of those possible at scale: standardised deployment pipelines, failover design and observability built into every service from the start. For a business with a handful of core systems rather than hundreds of microservices, most of that platform engineering work happens as part of the architecture project itself, not as a separate ongoing function.

Queueing is a good example of where these disciplines meet. A message queue architecture decouples the part of the system taking an order from the part fulfilling it, so a slowdown in one doesn't cascade into the other. Getting that right involves platform engineering decisions about which technology and where it runs, system integration decisions about how existing tools connect to it, and increasingly for Australian businesses, questions about where that queue and its data physically sit.

When to build custom versus buy off the shelf

Most scalable architecture work isn't about writing more custom code. It's about deciding which parts of the platform genuinely need custom API development and which parts are better served by an existing platform doing what it already does well. A business scaling its booking and payment flows doesn't need a bespoke channel manager built from scratch; the harder engineering problem is usually the integration layer connecting that channel manager to existing systems, similar to the Airbnb API integration built for a multi-property booking platform. The build-versus-buy call is rarely all-or-nothing: it's usually one integration layer built custom, sitting between two or three off-the-shelf systems that stay exactly as they are.