Whenever a product starts to feel slow, the instinct is to reach for a faster language, a better cache, or a new database. Most of the time the real problem is one layer up: the architecture was designed for a simpler version of the business.
Before diving in, two sources worth keeping close: Martin Fowler on architecture for the vocabulary, and Google's Core Web Vitals for the user-facing performance signals Google actually ranks on.
What we actually mean by "performance"
Three different things get lumped together under the same word:
- Perceived performance — does the UI feel snappy to a human?
- Throughput — how many operations per second can the system sustain?
- Latency under load — what does the p95 look like when the system is busy?
Most user-facing complaints are about perceived performance. Most scaling problems are about throughput and tail latency. The architectural moves that fix one rarely fix the others — so step one is always diagnosing which problem you have.
Architecture decisions that pay back for years
Draw a clean seam between reads and writes
The single biggest lever in most products. Reads outnumber writes by orders of magnitude. Separating them lets you scale independently — read replicas, aggressive caching, materialised views on the read path — without complicating write correctness.
Make async paths first-class
Anything that does not need to happen inside the request cycle should not happen inside it. Emails, webhooks, search indexing, analytics fan-out, AI calls. A queue and a worker are almost always cheaper than trying to shave milliseconds off a synchronous path.
Put boundaries where the team boundaries are
Microservices do not make you faster. Well-placed seams do. Draw your service (or module) boundaries where your team boundaries naturally live — that is where the coupling cost of sharing code is highest, and where a network or queue buys you organisational clarity.
Pick the right store for each job
One relational database is the right default. But do not fight it to do what it is bad at. A search index for search, a time-series store for metrics, an object store for blobs, a vector store for agent retrieval. Each gets its own backup and migration strategy, but each also stops being a bottleneck. PostgreSQL's own docs on what it is good at stop a lot of premature-database-swap decisions.
Architecture decisions that bite
- Premature microservices. A two-engineer team with six services spends more time on plumbing than product.
- Shared mutable caches across services. The hardest bugs in a career live here.
- Leaving observability for later. If you cannot answer "what is slow right now" in under five minutes, your production is a black box.
The AI-agent angle
Agent-heavy applications add a few architecture questions on top:
- Where do prompts live? Versioned in code, with tests. Not in a Google Doc.
- Where do embeddings live? In a dedicated vector store with a retention policy.
- Cost governance. Every agent call should be attributable — per user, per feature. A single misbehaving prompt can burn hundreds of dollars a day.
- Human approval gates. Architecturally, agent actions with real-world consequences must go through an explicit approval queue.
A practical review checklist
Once a year, walk your architecture through this list:
- Can we identify the ten slowest endpoints? What is common about them?
- What is the cost of one additional user per month? Can we predict it?
- Where do we still have a single point of failure we have not documented?
- Which database table grows fastest? What is the plan when it is 10x bigger?
- If our team doubled tomorrow, where would the merge-conflict pain be worst?
Each answer points at an architectural bet that needs a refresh.
Closing thought
High performance is rarely about a single heroic optimisation. It is about a set of small, boring structural decisions that keep the system legible to the team under pressure. Legible systems can be tuned. Illegible ones get rewritten — usually at exactly the wrong time.
If you are staring at a legacy system wondering whether to refactor or rewrite, talk to us — we do a lot of architecture audits and most of them land somewhere sensible in the middle.