Software Architect · Module 02
In architecture there is almost never a 'correct' option. There is the option 'we are deliberately buying this property at this price.'
Latency · consistency · maintainability · cost of complexity
The architect doesn't hunt for best practice. The architect names the axes of choice and the price along each one.
A decision without a price isn't a decision
A plane is faster than a train, but pricier, weather-sensitive, and won't drop you in the city centre. "The plane is better" is bad architectural talk.
A trade-off is exchanging one property for another. The most common axes in systems: latency vs. throughput, consistency vs. availability, simplicity vs. flexibility, time-to-market vs. maintainability, operational cost vs. development speed, vendor control vs. build cost.
The professional version of this conversation sounds like: "We're going with managed Postgres because the team is small and operational speed matters more to us than full control of the storage layer." Or: "We're not introducing Kafka right now, because we don't need replay or high throughput, but the operational complexity would be very real tomorrow."
Complexity must buy a concrete capability
You can cook in a one-bedroom apartment fitted out with an industrial kitchen. Living in it is harder.
Complexity isn't always bad. Sometimes it's needed: multi-region, event sourcing, sharding, service mesh, CQRS, Kubernetes. But each of those has to buy a specific property that already matters or almost certainly will.
If the team can't name what the complexity is buying, that's usually over-engineering. If the team ignores real existing pain in the name of simplicity, that's under-engineering.
A trade-off is only useful when it actually changes the decision.
Example: REST or GraphQL
A restaurant menu works when the dishes are standard. A salad-builder works when every customer wants their own combination.
REST fits when resources are stable, caching helps, clients look alike, and the API needs to be simple for external integrations. GraphQL is good when there are many clients, the shapes of the data vary, and the frontend keeps suffering from overfetching or underfetching.
The trade-off: GraphQL gives the client flexibility but complicates observability, field-level authorization, caching, rate limiting, and performance control. REST is simpler operationally but can multiply endpoints and force clients into several round trips.
An airport has a control tower. That doesn't mean the bike rack needs one.
Copying the architecture of Netflix, Uber, or Amazon without their scale is cargo cult. Big companies have different loads, teams, compliance, legacy, and cost of downtime. Their decision can be right in their context and harmful in yours.
The architect has to be able to say: "Yes, it's an industry pattern. No, our problem isn't there yet."
- What trade-off axes does the current decision sit on? - What is the complexity buying us? - What happens if we pick the simplest option? - What signal will tell us it's time to add complexity?