Software Architecture: The Decisions That Are Hard to Reverse
Architecture is the decisions that are expensive to change later. Here's which ones to take seriously early.
Software architecture is often discussed as if it's a set of patterns to apply. More practically, it's the set of decisions that will be expensive to reverse once the system is in production and has users. Understanding which decisions have high reversal costs — and which don't — determines where to invest design time.
Data model decisions are the hardest to reverse. The shape of your core entities, how they relate to each other, and what constraints you enforce at the database level propagate through every layer of the system. A data model that made sense for version one can make every subsequent feature awkward to implement. Spending time on domain modeling before writing code pays back disproportionately.
API contracts are expensive to change once external systems depend on them. Internal APIs (between services you control) can be refactored with coordinated changes. External APIs (consumed by customers or partners) require versioning, migration paths, and communication. Design external APIs with the assumption that they'll outlast the internal system implementation behind them.
Authentication and tenancy models are difficult to change in production. Adding multi-tenancy to an application designed as single-tenant requires touching the data model, every query, and all authorization logic. Migrating from one authentication system to another requires handling existing sessions, token migration, and user communication. These are worth designing correctly before you have users.
Technology choices with high integration surface — database, message broker, search engine — are relatively expensive to replace. Choices with low integration surface — testing frameworks, logging libraries, utility functions — are cheap to change. Invest design time proportional to the integration surface.
The decisions that are easy to reverse: folder structure, naming conventions, most framework configuration. Don't spend architecture time on these. The decisions that are hard to reverse: data model, API contracts, tenancy model, authentication strategy. Spend real time here.