System architecture decision checklist

Workload and scale

We know how many people and systems will use this, today and in a year.
We know the balance of reads and writes, as a rough ratio.
We have named the busiest hour of the busiest day and estimated its load.
We have checked whether one database and one application can handle that peak before planning anything larger.

Data

We have listed each type of data the system stores and who owns it.
For each type, we know whether it must always be correct or may lag, such as invoices versus an activity feed.
We have written down how long each type is kept and when it must be deleted.
We know which data is personal, confidential or regulated, and where it may be stored and processed.
We have tested a restore from backup, or scheduled when we will.

Speed and availability targets

We have a measured response target, such as 95% of pages in under 2 seconds.
We have an availability target and know how many minutes of downtime a month it allows.
We know what an hour of downtime costs the business, so the target is worth what it costs to meet.
We know who is told, and when, if a target is missed.

Integration and failure

We have listed every system this reads from or writes to, with the method (API, webhook, file) and a named contact.
We have confirmed rate limits and licensing permit the volume we expect.
For each dependency, we have decided what happens when it is slow or down: queue and retry, show a cached copy, degrade a feature or stop and tell the user.
Retried work can run twice without creating a duplicate order, invoice or message.
A person is alerted when two connected systems stop agreeing, not only when a server stops.

Security and compliance

We have a table of roles showing who may see and change what.
We have named the laws, standards or contract clauses that apply.
Secrets and API keys are held in a managed store, never in code or in the browser.
Consequential actions are logged with who did what and when.
If AI is involved, we know what data reaches the model vendor and which actions need a named person to approve them.

Team and cost

We have named who builds this and who runs it after launch, including who responds at 2 AM if that matters.
The design uses technologies our team, or a partner under contract, can already operate.
We have a monthly running cost estimate today and at three times the load, with its assumptions written down.
Monitoring, backups, updates and incident response are assigned to a named owner.

Change and reversibility

We have named the three most likely changes in the next year, such as a new country, product line or five times the volume.
We have marked each major choice as easy or expensive to reverse, and spent our analysis on the expensive ones.
We start with one application in clear modules unless we have a measured reason to split it.
We know how we would leave any vendor this design depends on, and roughly what that would cost.

If several sections have gaps, a discovery call with Kastling is a no commitment way to talk through which answers matter most for your system. Bring the checklist, and we can work through it with you.

See results