Triunnia Labs

Plan Your Solution

Dev, Test, and Production Environments

Types of Deployments

Every Component Scales on Its Own Terms

Overview

Arch is a distributed system where each microservice is a self-contained unit. Because nothing is tightly coupled to a single host, the architecture scales with your requirements. A small internal tool and a high-traffic consumer platform can both run Arch — the deployment model is different, but the application code is not. Choose the model that fits where you are today, knowing you can move to a larger model without rewriting anything.

All-In-One

All components run on a single host. One Sql Server instance serves every microservice database. The Control Panel, all Arch microservices, and your application containers share a single Docker network on the same machine. This is the simplest model to set up and operate: one machine to provision, one place to monitor, one place to update. It suits internal tools, low-traffic services, and early-stage products where simplicity matters more than redundancy.

Distributed

The database tier and the service tier run on separate machines. Sql Server — whether a dedicated VM or a managed service — is no longer on the same host as the microservices. This separates resource contention, lets each tier scale independently, and allows teams that already operate managed database infrastructure to plug Arch into what they have. The Control Panel and all microservices continue to operate the same way; only the connection strings and urls change.

Clustered

Each microservice runs as a cluster of replicas behind a load balancer, managed by a container orchestration platform such as Kubernetes or Docker Swarm. Because each Arch microservice is stateless at the request level, replicas can be added or removed without coordination. The Application Api, Keys Api, Users Api, and every other microservice scale independently — a spike in authentication traffic scales the Application Api without touching the Keys Api. This model is the foundation for high-availability, high-traffic production systems where individual components must absorb variable load without affecting the rest of the platform.

Choosing a Model

Start with the simplest model that meets your current requirements. All-In-One is the right default for most new deployments. Move to Distributed when you need managed database infrastructure or when the database and service tiers need to scale at different rates. Move to Clustered when individual services need to absorb traffic spikes independently or when your availability requirements exceed what a single replica can provide.

These models are not mutually exclusive. A production system might use Distributed for its database tier and Clustered for one or two high-traffic microservices while the rest run as single replicas. Because each component is independent, you can apply the right scaling decision to each piece without committing the entire system to one topology.