--- title: "Solution and Infrastructure Architecture" description: "Infrastructure design grounded in measured capacity data: sized correctly, redundant where it matters, documented properly and costed over three years." url: "https://nixit.io/services/infrastructure-architecture/" lang: "en" --- # Solution and Infrastructure Architecture We design the system before anyone provisions it, with sizing based on measurements and trade-offs written down. The most expensive infrastructure problems surface a few months after go-live, when the system starts behaving differently from what anyone assumed. The database cannot sustain the real write volume, the cluster cannot be patched without downtime, and staging diverges far enough from production that it stops catching anything. Nearly all of it is preventable with a serious design phase, done before hardware is ordered or the first provisioning script is written. ## How we approach design We start from measurable requirements rather than from technology preferences. What is peak transaction volume and how has it moved over the last twelve months. How much downtime is tolerable, and what does an hour of it actually cost. What regulatory constraints apply to where data is stored and processed. Who will operate this, and what does that team already know. Without answers, any diagram is guesswork with boxes. Sizing comes from measurement, not from estimates. We collect CPU, memory, IOPS and bandwidth utilisation from the current environment over a meaningful period, identify genuine peaks rather than averages, and design with a growth margin we can justify. Over-provisioning is the most common form of waste we encounter; under-provisioning produces incidents at the worst possible moment. For significant decisions we present two or three options with a three-year cost model and the trade-offs stated plainly. An architect who offers a single answer and presents it as obvious is usually hiding the compromises they made. Each major decision lands in an architecture decision record, so that two years from now somebody can reconstruct the reasoning instead of guessing at it. ## What you receive Architecture documentation covers logical diagrams, physical or cloud resource layouts, data flows between components and integration points with existing systems. Alongside that sits the network and security model, the storage and backup strategy, the recovery plan and the procedure for patching and upgrading without taking the service down. The implementation plan is phased, with acceptance criteria attached to each phase. A phase is not complete because a service was installed; it is complete when it passes the agreed tests, including behaviour under load, failover to the standby node, restore from backup and measured time to recovery. Where relevant, we design against the technical measures NIS2 expects around network segmentation, access control and logging, and against GDPR obligations on data location and protection. Building these in during design costs far less than retrofitting them onto a system already carrying production traffic. ## Who this is for The service fits organisations facing a structural change: migrating from an owned data centre to cloud or back again, replacing a virtualisation platform, standing up a second site for business continuity, or launching a product the current infrastructure was never designed to carry. It also suits engineering teams that have built a solid application and hit the ceiling of what is achievable without deliberate infrastructure design. Often the answer is not a rewrite but a better-suited storage model, proper environment separation and a scaling strategy agreed in advance rather than improvised during an incident. ## Working with a nearshore EU partner Our architects work in European time zones, which matters more than it sounds during a design phase. Review sessions happen live rather than through overnight document exchanges, and questions raised in the morning are usually resolved the same day. Being EU-based also means data residency and processing constraints are treated as normal design inputs rather than exceptions requiring special handling. ## Outcomes You leave the design phase with a document a vendor can price accurately, an internal team can build from and an auditor can read. Budget estimates come closer to reality because they rest on measured sizing rather than optimism. Most importantly, the decisions you make now stay explained in writing for whoever inherits the system later, which is the difference between infrastructure that can evolve and infrastructure nobody dares touch. ## What you get - Architecture documentation with logical, physical and data-flow diagrams - Capacity sizing derived from measured utilisation rather than estimates - Three-year cost model comparing two or three implementation options - Architecture decision records capturing trade-offs explicitly - Phased implementation plan with acceptance criteria per phase ## Technologies VMware vSphere, Proxmox VE, Kubernetes, Terraform, PostgreSQL, HAProxy, Ceph, AWS, Azure ## Frequently asked questions ### Is a separate architecture phase worth the cost? Design typically costs a small fraction of total project budget. The alternative is discovering in production that the storage model or the sizing was wrong, which is several times more expensive to correct. Architecture is the cheap part of the project. ### Should we move to the cloud or stay on our own hardware? It depends on how predictable your workload is. Stable, steady-state workloads are frequently cheaper on owned hardware in colocation over a three to five year horizon, while variable or uncertain workloads favour cloud. We build the cost model for both and you decide on the numbers. ### How do you decide how much redundancy is justified? We start from the cost of an hour of downtime to your business and the RPO and RTO you actually need. Redundancy without a stated requirement doubles cost for no gain, and missing redundancy at a critical point causes expensive outages. Whatever level is chosen gets documented along with the reasoning. ### Can you design for EU data residency requirements? Yes, and it is a routine constraint in our work. We design around specified regions, keep personal data within the EU, and document processing locations and sub-processors so the design supports your GDPR record-keeping rather than complicating it.