Architecture
The discipline of deciding what NOT to build. Good architecture is mostly about keeping future options open at a price you can afford today.
Architecture is Economics
The job isn’t to build the “best” system; it’s to build the system that maximizes business options per dollar spent. A startup needs to move fast (monolith, shared database). A mature company needs to move safely (microservices, clear boundaries). Same problem, different constraints, different architecture.
Seams and Boundaries
The best architectures I’ve seen share one thing: clear seams. Microservices, domain-driven design, event-driven architecture—these are all ways of saying “split the system so teams can move independently.”
The key is identifying seams before you need them. You don’t know exactly what will scale, but you know databases and message queues scale well. You don’t know what will change, but you know change happens at team boundaries. Design so that when change comes, it doesn’t require rewiring the entire system.
Technical Debt is Architectural Debt
Bad code is easy to fix. Bad architecture is expensive. A monolith that’s well-written is fine until you want two teams to own two pieces—then you’re rewriting.
The patterns that work:
- Interfaces over implementations: Build against contracts, not concrete classes. Swap implementations without rewiring callers.
- Async boundaries: If two services talk synchronously, they’re coupled. Async (queues, events) decouples them.
- Independent deployability: If changing service A requires coordinating with service B, they’re not actually independent.
The Rule of Three
Don’t abstract until you see the pattern three times. One-off code is fine. Two instances might be coincidence. Three instances, and you know there’s a pattern worth extracting. This applies to services, schemas, and databases too—until you’re sure the division makes sense, keep things simple.