Infrastructure · Security · Engineering
Tell us what you need
Home / Application Engineering / Hosting Architecture Review
Hosting Architecture Review
Building an application has never been easier. Working out what it should run on has not changed at all — and it is the decision that determines what the next three years cost you.
We model your workload properly, tell you what to build, and what it will cost to run.
Sized from measured inputs. Never from a template.
Finished or nearly finished, and not yet hosted properly.
If it is not written yet, there is nothing to measure.
What to build, what it costs monthly, and when to change it.
Build it yourself, hand it to your provider, or have us run it.
Why this decision matters more than it looks
Almost everything else about a new application is reversible. You can rewrite a feature, change a framework, redesign an interface. The things decided at deployment — which region, which database, whether environments were separated, how identity works — are the ones that turn into migrations later.
| The decision | Made by default | What it costs later |
|---|---|---|
| Instance size | The provider’s recommendation, or a figure chosen for headroom. | Paid monthly, forever, on capacity nobody measured |
| Database | On the application server, sized without measurement. | The first real load spike takes the whole thing down |
| Environments | A single server, with changes tested in production for want of anywhere else. | The outage that was avoidable, and the data that was not recoverable |
| Region | The default, or the one nearest the developer. | A migration, once someone asks where the data lives |
| Identity | Shared credentials, appropriate to three people and retained past thirty. | Access nobody can retire when the third person leaves |
| Backups | Provider snapshots, untested. | Discovering at the worst moment that they do not restore |
| Scaling | Deferred while current capacity holds. | Rebuilding under pressure, with users watching |
Each is inexpensive to decide at the start, and expensive to revisit later.
What the review covers
Not a checklist against best practice. Your numbers, your workload, and a specification that follows from them.
CPU, memory and instance count derived from your measured request rate, concurrency and response profile — not from the size of your codebase, which tells you nothing.
Engine, sizing against the working set rather than total data, connection pooling, backup schedule, and where it sits relative to the application. Most scaling problems are database problems.
Local, staging and production — what each is for, what separates them, and the rule that staging never shares production data.
LDAP, Active Directory or SSO, how administrative access is granted, and how it is removed when somebody leaves.
Modelled explicitly, because egress is the line item that surprises people and it is rarely in anybody’s first estimate.
Certificates, records, and which region you deploy into given where your users are and what obligations apply to your data. Free to choose on day one, a migration to change afterwards.
One machine, then a separate database, then a second application server — with the measurement that tells you it is time for each step, so the first design is not thrown away.
Sizing from a template is guessingwith more confidence.
A worked example
The example below is constructed rather than drawn from a client, and the figures are illustrative. It is here to show the method — how a specification follows from measurement rather than from a template.
An internal business application, built in-house, about to be opened to roughly 300 daily users across three offices. Currently running on one machine under somebody’s desk. No staging environment. Backups are the hosting provider’s snapshots, never restored.
| Measurement | Result | Why it matters |
|---|---|---|
| Requests at peak | 22 per second, against 4 on average | Peak sizes the machine. Sizing on the average would have under-built it nearly six times over |
| Concurrent users at peak | About 180 | Drives connection pooling and session handling, not CPU |
| Response time, p95 | 240ms | With 22 req/s this means roughly 5 requests in flight at once — modest |
| Database working set | 4.2 GB of 11 GB total | Only the working set needs to sit in memory. Sizing on total data would have doubled the bill |
| Egress | About 140 GB per month | The line item nobody includes in a first estimate |
| Storage growth | About 3 GB per month | Sizing on today’s 11 GB would need revisiting within a year |
| Component | Specification | Reasoning |
|---|---|---|
| Application server | 4 vCPU, 8 GB RAM | Five requests in flight needs the headroom is for deployment and background jobs rather than request handling |
| Database server | Separate machine, 4 vCPU, 16 GB RAM | Working set of 4.2 GB plus indexes plus filesystem cache, with room to grow before memory becomes the constraint |
| Staging | 2 vCPU, 4 GB RAM, own database | A fraction of production, shut down outside working hours. Never shares production data |
| Storage | 120 GB, expandable | Three years of growth at the measured rate, rather than a number that felt safe |
| Backup | Nightly, off-server, 30 day retention, immutable | Off-server because a backup on the same machine is not a backup |
| Access | Directory-backed sign-in, no shared accounts | Three people today. Shared credentials become unremovable at eight |
Add a second application server when sustained CPU passes 60% at peak, or p95 response passes 400ms — whichever comes first. Increase database memory when the working set reaches 70% of RAM. Move to read replicas only if read load exceeds writes by more than four to one.
Each is a number somebody can watch on a dashboard, rather than a feeling that things seem slower.
A team of forty users on a single virtual machine asked us to design a container platform, because they had been told that was the next step.
Their measured peak was under 3 requests per second, their database was smaller than the memory it already had, and their machine sat at 11% CPU. The recommendation was to change nothing except the backups, which had never been tested, and to revisit the question if sustained load tripled.
That review took a morning and removed a platform from the plan. If your numbers say the same thing, that is what you will be told.
This example is illustrative. It will be replaced with a real anonymised review before launch.
How it works
Access logs, current utilisation, or the guides which set out exactly what to measure and the read-only commands to measure it. If nothing is running yet, we work from expected load and say plainly which figures are assumptions.
Sizing, database, environments, access, region and cost — including the options we rejected and why, because the reasoning is the part you can reuse.
A written document with the sizing, the reasoning, the monthly cost and the scaling triggers, plus the architecture drawn out. We walk you through it on a call so you can argue with it — the reasoning matters more than the numbers, because it is the part you reuse when things change.
Build it yourself, hand it to your existing provider, or have us build and run it. All three are normal outcomes and none of them is a failure.
Who this is for
If you are in the second column we will say so at the first conversation.
Before you pay anyone
They set out what to measure, how to measure it, what the numbers mean, and how to separate environments and back things up properly. If they answer your question, you do not need the review — and the specification is yours regardless of what follows.
What it is written in, roughly how many users you expect, whether anything is running yet, and what is worrying you about hosting it. We will tell you whether a review is worth doing.
An engineer replies within two business days.