Most architectures don't fail because of brilliant decisions made too late. They fail because of ordinary decisions made too eagerly — premature microservices, premature abstractions, premature framework choices. Here are five principles that age well, drawn from 17+ years of building systems that had to survive growth.
1. Boring tech wins more than it loses
Postgres, Django, Rails, Express, Spring — these tools are boring on purpose. They have decade-deep documentation, a labour market full of engineers who know them, and known scaling characteristics. The team that picks Postgres and ships in 6 weeks usually beats the team that picks a trendy newcomer and spends 3 weeks learning it.
Pick the boring tool unless you have a specific reason — measured, not imagined — that the boring tool won't work.
2. Loose coupling is more important than DRY
Junior engineers learn DRY (Don't Repeat Yourself) early and apply it religiously. Senior engineers know DRY is a tactic, not a goal. The real goal is loose coupling: minimizing the number of places that change when one thing changes.
Two pieces of code that look the same but change for different reasons should not be deduplicated. Premature DRY creates abstractions that look elegant on day one and crush velocity by year two. Bad abstractions are far more expensive than duplication.
3. Observability is not a phase 2 problem
The cheapest time to add structured logs, metrics, and traces is at the start. By the time you "need" observability, the system is on fire and you can't see why. Every long-lived service should ship with:
- Structured logs with request IDs that propagate across service boundaries
- RED metrics (Rate, Errors, Duration) on every external boundary
- Distributed tracing for any request that crosses two or more services
This is 1-2 days of upfront work that pays back the first time something breaks at 3am.
4. Database choices outlive everything else
You will rewrite your frontend three times. You will swap your job queue. You might even rewrite the backend in a different language. You will not easily change your primary database. The data model and the database engine are the most expensive decisions to reverse.
Practical implications:
- Default to a relational database. Reach for NoSQL only when you have a measured reason
- Don't shard until you have to. Single-instance Postgres scales further than most teams realize — well into eight figures of revenue
- Read replicas before you reach for caching layers. Caching adds correctness bugs; replicas don't
5. Optimize for change, not perfection
The most useful architectural property isn't elegance — it's changeability. Every system you ship will be wrong about something within 12 months. The question is: when you discover it's wrong, can you change it without rewriting?
Concretely, that means:
- Deploys are boring and fast (≤10 minutes, multiple times per day)
- Feature flags exist for any change with non-trivial risk
- Test coverage is high enough that you can refactor without panic
- Database migrations are reversible by default
The principle behind the principles
Every one of these comes back to a single idea: defer decisions until you have the information to make them well. Premature microservices, premature DRY, premature optimization, premature abstraction — all variants of the same mistake. Make the smallest reasonable bet, ship it, and let real usage tell you what to do next.
We've watched a lot of teams reach scale without these principles, and a lot more crash into a wall trying to. If you'd like a second opinion on your architecture roadmap, that's exactly the kind of conversation our consultancy practice is built around. Get in touch.