--- type: Hub title: Scalable architecture design description: Scale data, services and traffic layers before they break, with staged architecture design and no full rebuild. Get in touch. resource: https://nationaldigital.com.au/platform-engineering/scalable-architecture-design/ tags: - platform-engineering - Platform Engineering - Cloud Infrastructure - System Integration - Legacy Modernisation - scalable architecture design - cloud engineering - legacy system modernisation - api development - application modernisation - platform engineering vs devops - staged legacy modernisation - system integration services timestamp: '2026-09-29T08:26:20.290Z' language: en-AU publisher: National Digital author: Cameron Young authorRole: CEO readingTimeMinutes: 8 wordCount: 1599 datePublished: '2025-10-07' dateModified: '2026-09-29' pillar: platform_engineering canonical: https://nationaldigital.com.au/platform-engineering/scalable-architecture-design/ --- _Home — Platform Engineering — Scalable architecture design_ *HUB · 5 GUIDES* # Scalable architecture design Scale data, services and traffic layers before they break, with staged architecture design and no full rebuild. Get in touch. **Quick answer:** Scalable architecture design separates a platform's data, service and traffic layers so each can scale independently, avoiding a full rewrite as an Australian business grows. _Last updated 29 September 2026_ ## What does scalable architecture design actually change in a platform? It separates a platform's data, service and traffic layers so each can be scaled, secured or replaced on its own timeline as it nears capacity, without forcing a full rewrite. **Additional Context** Most platforms don't fail all at once; usually one layer, often the database or a monolithic service, hits its ceiling first. Scalable architecture design identifies that layer and re-architects it in isolation before the next one becomes the constraint. _High confidence · Verified 29 Sept 2026_ *Foundations* ## 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](/platform-engineering/scalable-architecture-design/service-separation) often find the real blocker isn't the code split itself but the data layer underneath it, which is why [staged legacy modernisation](/platform-engineering/scalable-architecture-design/database-sharding) 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. *Scaling Risk* ## Why scaling problems compound quietly **Problem:** Growing platforms tend to fail one layer at a time: a database connection pool maxes out, a deployment freezes because two teams share the same monolith, or a traffic spike takes down a service other systems depend on. Left alone, these incidents multiply as trading volume grows, and each one erodes confidence in the platform's ability to support the next stage of the business. **Common Pain Points** - **Database as single point of failure** — One shared database handles every write, so growth in one part of the business slows every other part down. - **Monolithic deployments** — Any change requires deploying the entire application, so releases get riskier and less frequent as the platform grows. - **Traffic spikes without failover** — A single region or server handles peak load, so unexpected demand can take core systems offline. **Business Impact** - Time Wasted: Engineering hours diverted from product work into firefighting recurring outages - Cost Implication: Cloud spend inflated by over-provisioning used as a substitute for architectural fixes - Opportunity Cost: New features and integrations delayed while teams work around a platform that can't scale cleanly **Solution:** A staged architecture program that separates one constrained layer at a time, whether that's the database, a monolithic service or the traffic layer, so the platform gains headroom without a disruptive full rewrite. **Our Approach** 1. **Diagnose the actual constraint** _(Early discovery phase)_: Trace outages and slowdowns back to the specific layer causing them, rather than assuming the whole stack needs rebuilding. 2. **Separate and modernise in sequence** _(Following the architecture review)_: Re-architect the constrained layer first, using API-first patterns so dependent systems keep working throughout. **Expected Outcome:** A platform where each layer scales independently, so new capacity gets added exactly where the business needs it. *Key Takeaways* ## What growing platforms need to get right early Scalable architecture design fixes the specific layer causing growth pain, staged so the business keeps operating and without the disruption of a full platform rebuild most growing platforms don't need. - **Scaling problems show up in one layer before the whole platform** Database connection limits, monolithic deployments and single-region hosting each fail independently, so diagnosis has to be specific rather than a wholesale infrastructure review. _Critical_ - **Staged modernisation keeps the business trading throughout** Separating services and data incrementally avoids the downtime and risk of a full-platform rewrite, which is rarely justified for a platform of this scale. _Critical_ - **Platform engineering and system integration solve different problems** Platform engineering builds the internal tooling and environments; system integration makes sure separated services and existing tools like Xero or HubSpot keep exchanging data correctly. _Important_ - **API-first design is what makes later scaling changes cheaper** Defining clear API contracts between services early means database sharding, load balancing or queueing can be introduced later without renegotiating every integration point. _Important_ ## What the data says about legacy risk and cloud reliance Public reporting from Australian government sources consistently flags legacy and poorly segmented systems as risk factors, and shows a steady shift toward cloud-hosted infrastructure among Australian businesses. - **Growth in reported vulnerabilities: 28%** _Significance: high_ — Publicly reported vulnerabilities grew 28% in FY2024-25, and unpatched, poorly segmented legacy systems are where that exposure accumulates. _(Source: ASD/ACSC, Annual Cyber Threat Report 2024-25)_ - **Businesses using cloud technology: 59%** _Significance: medium_ — A majority of Australian businesses use cloud technology, so most architecture decisions now involve cloud-hosted infrastructure rather than solely on-premises hosting. _(Source: ABS Characteristics of Australian Business 2021-22)_ - **Staged modernisation preference: Favoured over big-bang rewrites** _Significance: medium_ — Government digital transformation guidance favours incremental, staged approaches to legacy modernisation over single large-scale replacement projects, reflecting the operational risk of big-bang cutovers. _(Source: Digital Transformation Agency guidance on legacy system modernisation)_ **Methodology:** Points are drawn from published Australian government sources rather than internal survey data, and presented qualitatively where a precise Australia-wide figure is not publicly available. *Build vs Buy* ## 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](/platform-engineering/scalable-architecture-design/load-balancing) 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](/platform-engineering/scalable-architecture-design/queue-systems) 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](/case-studies/luxico/) 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. ## Talk to an Architecture Specialist Discuss the specific layer that's constraining growth, whether that's the database, a monolithic service or traffic handling, and get an indicative view of what a staged architecture program would involve. ## Scalable Architecture Design: Common Questions ### What is platform engineering, in practical terms? Platform engineering is the practice of building the internal tooling, environments and standard patterns that let a team ship and scale software safely, things like deployment pipelines, environment provisioning and observability. For a growing business it usually shows up as part of a broader architecture project rather than a standalone team, at least until the platform reaches a scale that justifies dedicated internal platform staff. ### How is platform engineering different from DevOps or SRE? DevOps is a set of practices for releasing software faster and more reliably. Site reliability engineering focuses on keeping live systems within defined reliability targets. Platform engineering builds the shared tooling and standard patterns, like deployment pipelines and load balancing, that make both of those practices possible without every team reinventing them from scratch. ### What does API development have to do with scalable architecture? Clear, versioned APIs are what let one layer of a platform change without breaking everything connected to it. Good API development practice, defining contracts before separating services, is usually the difference between a staged modernisation that works and one that turns into a tangle of point-to-point fixes. ### Should a growing business build custom software or buy an off-the-shelf platform? Most of the time, the honest answer is both: keep the platforms already doing their job, such as Xero or HubSpot, and invest custom API development in the integration layer connecting them. A full custom rebuild is rarely justified unless the core business process itself is the differentiator. ### How long does a scalable architecture project typically take? It depends heavily on which layer is constrained and how many systems depend on it. A focused piece of work, such as separating one service or introducing database sharding for one table, is a materially different undertaking to a multi-layer modernisation program, so scope is usually set after a short architecture review rather than estimated upfront. ### Does legacy system modernisation always mean a full rewrite? No. A full rewrite is the highest-risk option and usually the least necessary one. Staged modernisation, separating and replacing one component at a time while the rest of the platform keeps running, is the approach that keeps a business trading throughout the project and is what most growing platforms actually need. ## In this hub · every guide - [Load balancing for Australian hosting](/platform-engineering/scalable-architecture-design/load-balancing/) — 8 min - [Database sharding: a staged approach](/platform-engineering/scalable-architecture-design/database-sharding/) — 8 min - [Service separation without a big-bang rewrite](/platform-engineering/scalable-architecture-design/service-separation/) — 7 min - [Queue systems for Australian infrastructure](/platform-engineering/scalable-architecture-design/queue-systems/) — 9 min - [Pos System Integration](/platform-engineering/scalable-architecture-design/pos-system-integration/) — 8 min ## Related **Parent:** - [Platform Engineering](/okf/platform-engineering.md) **Children:** - [Load balancing for Australian hosting](/okf/platform-engineering/scalable-architecture-design/load-balancing.md) - [Database sharding: a staged approach](/okf/platform-engineering/scalable-architecture-design/database-sharding.md) - [Service separation without a big-bang rewrite](/okf/platform-engineering/scalable-architecture-design/service-separation.md) - [Queue systems for Australian infrastructure](/okf/platform-engineering/scalable-architecture-design/queue-systems.md) - [Pos System Integration](/okf/platform-engineering/scalable-architecture-design/pos-system-integration.md) **Related:** - [Cloud engineering](/okf/platform-engineering/cloud-engineering.md) - [System integration](/okf/platform-engineering/system-integration.md) # Citations - [ABS – Business Use of Information Technology](https://www.abs.gov.au/statistics/industry/technology-and-innovation/business-use-information-technology) — ABS statistics tracking Australian business adoption of cloud computing and digital infrastructure over time. - [Australian Cyber Security Centre – Resources for Business](https://www.cyber.gov.au/resources-business-and-government) — ACSC guidance identifying legacy and poorly segmented systems as recurring risk factors for Australian organisations.