The Best System Architecture Often Begins Outside the System
By Skyrit Lai
Database schemas and APIs are downstream of business rules. When the domain is misunderstood, clean implementation can still encode the wrong reality.
01 / Systems
Understand the domain
Learn how money, approvals, ownership, accounts, transactions, and other operational concepts actually behave before turning them into fields and endpoints.
02 / Systems
Identify invariants
Define what must remain true regardless of timing, user action, or implementation detail. These invariants give the system a stable reference when exceptions appear.
03 / Systems
Make architecture an expression
Only then should the rules become records, APIs, transactions, events, and services. Architecture is most useful when it makes the domain clearer rather than hiding it.
The thought to take with you
Architecture is the technical expression of how well a team understands the business rule.
Related work
Where this thinking shows up.
Business and technology · Software systems and data
Put the thinking into practice.
Service
Business Tools & Internal Systems
Scoped dashboards, internal tools, and lightweight applications shaped around operational work and business rules.
Service
Business & Technology Consulting
Clarify a business challenge, map requirements, and compare practical technical options before choosing what to build.
Note
Why Good Technology Projects Start With Business Questions
Teams often jump from a problem directly to a feature, platform, or automation. Technology becomes more useful when the decision it needs to improve is clear before implementation begins.
Note
Structuring Data for Scale with PostgreSQL Partitioning
As operational data grows, predictability matters as much as raw query speed. Partitioning can help a data model reflect time, tenant, retention, and maintenance boundaries more deliberately.
Note
Designing Multi-Database Systems
Serving several organisations from one application can require more than an additional connection string. Data boundaries, migrations, observability, and operating responsibility all become architectural concerns.