09 · Architectural Taste: What Separates Good Architects Beyond the Framework
The first eight chapters gave you the "teachable" part — frameworks, patterns, processes. But you'll soon hit a sobering fact: two people who've both memorized the framework can still produce architectures of wildly different quality. That missing part is called taste. This chapter explains what taste is, why it determines an architecture's "personality," and how to grow it — by comparing real-world cases.
Frameworks can be "taught"; taste can only be "grown"
Think of the first eight chapters as learning to write: frameworks, patterns, and processes are "grammar and vocabulary" — they ensure your sentences are error-free. But "grammatically correct" and "well-written" are two different things.
Architecture is the same. A framework takes you from 0 to 70 (you don't make fatal mistakes); but from 70 to 90 takes something else:
Taste — the judgment to pick, among the "several reasonable options" a framework yields, the one that's accurate, elegant, and fits here and now.
Note the key insight: a good framework doesn't give you one answer — it converges on a few defensible candidates. Then what? Which one? When do you break convention? The framework goes silent here; taste takes over.
Taste isn't mysticism or innate talent. It's the intuition you internalize after seeing enough good architectures and enough bad ones. The good news: since it comes from "seeing a lot," it can be accelerated by deliberately looking and comparing.
Framework / patterns / process Taste / judgment
─────────────────────────── ────────────────
teachable, memorizable only grown, from exposure
keeps you from big mistakes (70) makes it elegant (90)
converges to a few options picks right, knows when to break rules
has standard answers no standard answer, only "more fitting"Truth 1: The same problem has no single correct answer
A beginner's deepest obsession is "what's the standard answer to this problem?" Taste's first lesson is to accept: architecture has no standard answers.
Don't believe it? Watch two top experts openly disagree:
- Martin Fowler wrote MonolithFirst: nearly all successful microservices started as a monolith that grew too big and got split; those built as microservices from scratch mostly end up in trouble.
- Then Stefan Tilkov, on the same site, published Don't start with a monolith: for some systems destined to be distributed, monolith-first is a detour.
Two world-class architects, on the same site, giving opposite advice — this isn't "someone's wrong," it's the best proof that the answer depends on constraints.
Now two textbook successes that chose oppositely:
| Stack Overflow | Netflix | |
|---|---|---|
| Architecture | Monolith + few servers + vertical scaling (Nick Craver's breakdown: 200M requests/day on fewer than a dozen web servers) | Full microservices + global distribution (hundreds of services) |
| Why | Small team, predictable load, cost-sensitive, obsessed with simplicity | Huge org, global elasticity, massive concurrency, teams must evolve independently |
| Result | Wildly successful | Wildly successful |
Two opposite choices, both right — because their constraints are completely different.
💡 Taste's first lesson: an architecture's "personality" comes from its constraints' "personality."
Hence a life-saving rule: copying someone's architecture without copying their constraints is a disaster. Seeing a big company use some flashy architecture and copying it — while ignoring that your "team size, traffic, cost, compliance" aren't remotely in the same league — is the most common and most fatal beginner mistake.
Truth 2: The five facets of taste (each nailed to a real case)
Taste sounds vague, but it has facets you can observe concretely and cultivate deliberately.
Facet 1 · An obsession with "simple," a pain reflex to "complexity"
Rich Hickey's classic talk Simple Made Easy busts a confusion:
Simple ≠ Easy. Simple means "one fold/braid" (an objective structure); easy means "near at hand, familiar" (subjective convenience). People manufacture complexity by chasing easy (use what I know, what I can pick up now).
Tasteful people pursue simple even when it isn't easy at first. Seeing a design, their reflex is "can this be simpler?" rather than "what else can I add?"
That's also DHH's stance in The Majestic Monolith: for the vast majority of web apps, a small team should make its monolith majestic — not invent distributed misery by replacing method calls with network calls.
Facet 2 · Don't follow fashion (busting the "microservices = advanced" myth)
This is the chapter's most striking part — a string of real reversals that slap the trend in the face:
- Amazon Prime Video: moved its video-quality monitoring from microservices/serverless back to a monolith, cutting cost by 90%. (The New Stack report — even AWS's own team did this.)
- Segment: Goodbye Microservices — merged 140+ microservices back into a monolith, going from "an outage every day and a half" to "one engineer deploys in minutes."
The lesson is not "microservices are wrong" (Netflix uses them well). The lesson is: following the herd is wrong.
💡 Taste = resisting the lure of "looking advanced." When everyone chants some buzzword, the tasteful person doesn't ask "is it trendy?" but "does it fit my constraints? can I afford the cost?"
Facet 3 · Spend your "innovation" on the cutting edge only
Dan McKinley's brilliant metaphor Choose Boring Technology:
Every company has only a limited number of "innovation tokens." Each unproven, unfamiliar tech you adopt spends one — because you'll hit every pothole no one's hit before. Don't waste tokens on "a trendier database"; save them for your real competitive edge.
Taste shows up as: use boring, mature, predictable tech for the vast majority of the system; only spend a token on the one or two genuinely differentiating points.
Facet 4 · Knowing when to break the rules
Best practices and design principles are essentially safety nets for people who haven't grown taste yet — follow them and you won't die.
But tasteful people go further: they understand the "why" behind each rule, and therefore know "when that why doesn't hold, and it's time to break it."
- "Don't optimize prematurely" is a good rule; but when you know a read path will melt on launch, pre-installing a cache hook is a justified break.
- "Don't denormalize" is a good rule; but denormalizing for read performance (see 05 · Data & State) is also a break.
⚠️ The danger isn't breaking rules — it's "breaking them without understanding them." Break without understanding = recklessness; break after grasping the why and pricing the cost = taste. Master the rules first, then become their rebel.
Facet 5 · Aesthetics: recognizing "ugly" — and recognizing "schools"
A seasoned architect, looking at a design, recoils the way a writer recoils at a broken sentence. Common "ugliness":
- Over-engineering ugly: a five-person team with a dozen microservices, spending most of its energy debugging "why can't services talk to each other."
- Leaky-abstraction ugly: claims to be encapsulated, yet you must understand its internals to use it right.
- Inconsistency ugly: three naming styles and three error-handling styles in one system, like three people talking past each other.
- Too-clever ugly: a dazzling design no one understands, that no one (including the author) dares touch six months later.
This "recoil" isn't innate — it comes from seeing enough clean ones that you recognize the dirty ones.
But aesthetics is more than "spotting ugly" — it has schools. Like architecture (the building kind) has minimalism and baroque, software architecture has different aesthetic doctrines. And the most influential ones today are embodied by big companies. Seeing the schools, then deciding where you stand, is taste's crucial leap.
Truth 3: Big-company architectural tastes — and which one you should pick
Looking at a company's architecture is like looking at someone's dress style: a whole value system sits behind it. These few companies represent the most influential "architectural tastes" today. None is superior — only fitting. Each is the product of that company's unique constraints.
| Company | Aesthetic core | Signature fact | Cost / prerequisite |
|---|---|---|---|
| Amazon | Service autonomy, draw boundaries with interfaces | 2002 Bezos "API Mandate": teams may only communicate via service interfaces, "or be fired" (it later birthed AWS) | A whole mountain of distributed complexity; even Amazon pragmatically reverts to a monolith for cases like Prime Video |
| Netflix | Embrace failure, built for resilience | Chaos Monkey / chaos engineering: randomly kills instances in production; "the best way to avoid failure is to fail constantly" | Enormous engineering investment; only justified when "massive scale + high availability is the lifeline" |
| Engineering rigor, unified infra for planet-scale | In-house Borg (Kubernetes' ancestor), Spanner, Bigtable — everything for extreme scale | Extremely heavy; copying it below Google scale is cargo-culting | |
| Shopify | Monolith's simplicity + module discipline | A 2.8M-line Ruby "modular monolith": module boundaries instead of splitting services | Requires discipline to hold boundaries; but healthily defers "should we split" |
| 37signals / Basecamp | Extreme restraint, less is more, dare to defy trends | Majestic Monolith + a high-profile 2023 cloud exit to its own hardware, projected to save $10M+ over five years | Needs the nerve to go against the grain; optimized for small-team efficiency and cost |
| Stack Overflow | Performance geek, do the most with the fewest machines | 200M requests/day on fewer than a dozen web servers: vertical scaling + monolith + aggressive caching | Disdains "solve everything by adding machines"; demands obsessive performance focus |
See the pattern? The right three (Shopify / 37signals / Stack Overflow) and the left two (Amazon / Netflix) have nearly opposite tastes — the former embrace simplicity, monoliths, restraint; the latter embrace distribution, services, redundancy for extreme scale. Yet all are wildly successful. Because taste is a product of constraints: Netflix must handle global elasticity; Basecamp wants small-team happiness.
So, which taste should you pick?
This is the question you should care about most, and the answer is clear:
The vast majority of individual developers and small teams should lean toward the 37signals / Stack Overflow / Shopify end — not Google / Netflix.
The reason is simple: your constraints look like Basecamp's, not Netflix's. Few people, need speed, limited budget, load nowhere near "global elasticity." Google/Netflix's taste grew out of their massive scale and org; forcing it onto yourself is wearing an ill-fitting gown — expensive, exhausting, and not even good-looking.
So, the default taste for individuals / small teams, five rules to remember:
- Monolith first (modular monolith). Don't touch microservices unless the org is genuinely too big to coordinate — remember Prime Video and Segment both "came back."
- Choose boring technology. Save your few innovation tokens for what truly differentiates you.
- Be a neat freak about complexity. Before adding any component / service / abstraction, ask "will it die without this?"
- Vertical scaling first. For a long time, "add capacity" is cheaper and simpler than "add machines + go distributed" (Stack Overflow is living proof).
- "Simple" always beats "looks advanced."
💡 Taste should be "backward-compatible": master the simplest tier first, upgrade only when cornered.
Most project tragedies come from using Netflix's taste to do Basecamp-sized work. When your constraints truly change (hundreds of engineers, global traffic, teams stepping on each other), you'll naturally move toward the Amazon/Netflix end — and by then you'll have enough taste to know how far to move.
In one line: learn Basecamp's restraint first; only then have you earned the right to talk about Netflix's complexity.
How to grow taste (five practical things)
Taste comes from "broad exposure + deliberate reflection." Five things you can start today:
- Read real architectures, a lot. Read the 21 templates here as maps, then first-hand engineering blogs worth subscribing to: Netflix TechBlog, Shopify Engineering, Stack Overflow / Nick Craver, Martin Fowler, InfoQ, High Scalability.
- Deliberately compare similar systems. Pick two products doing similar things, force yourself to list how their architectures differ, then answer the key question: "which constraint difference causes this?"
- Do a "post-mortem" on every decision. Three months later, was the trade-off right? Which assumption was wrong? (That's the value of ADRs.)
- Cultivate a pain reflex to complexity. Every time you want to add something, force yourself to answer "will it die without this?"
- Read "reversal / slap-in-the-face" stories specifically. Cases like "microservices back to monolith" are the best vaccine for calibrating your trend-immunity.
An exercise you can do right now: open the Social Feed template, then ask: would Twitter and a niche community of a few thousand have the same feed architecture? If not, which constraint causes the difference? (Hint: scale, hotspot distribution, real-time requirements…)
Chapter summary
- Frameworks keep you from big mistakes (70); taste makes it elegant (90). Frameworks are teachable; taste is grown through "exposure + reflection."
- Architecture has no standard answer. Fowler vs Tilkov openly disagreeing, Stack Overflow vs Netflix choosing oppositely and both succeeding — personality comes from constraints; copying architecture without constraints is a disaster.
- Five facets of taste: ① obsession with simple, pain reflex to complexity (Hickey, DHH); ② don't follow fashion (Prime Video, Segment reversals); ③ spend innovation tokens sparingly (Choose Boring Technology); ④ know when to break rules only after grasping them; ⑤ recognize "ugly."
- Architectural taste has schools, and you should pick the "restraint" end. Amazon/Netflix (distributed, for extreme scale) vs 37signals/Stack Overflow/Shopify (monolith, restraint) — opposite yet both successful; individuals and small teams should default to the latter. Learn Basecamp's restraint before talking about Netflix's complexity.
- Practice: read real architectures, compare similar systems, post-mortem decisions, keep a pain reflex to complexity, read reversal stories.
This is the last chapter — and the real beginning.
Remember Chapter 01: writing code is disappearing, judgment is getting valuable. And the top layer of judgment is the taste in this chapter — it has no finish line; it grows with every system you've seen.
So close the tutorial and go read, compare, reflect. We've handed you the framework; the taste, you must feed yourself, one real system at a time.
👉 Start here: pick a template and take it apart, or let architecture-copilot walk your next project's architecture through, question by question.