InterviewKata
Software architecture · Level 3: Architecture styles · Module 17 of 46

Choosing and combining styles

You've now met the main architecture styles. Real systems rarely use just one: an auction site might run its bidding on space-based units, its catalogue as a microkernel, its payments as a microservice, and connect them all with events. This module pulls Level 3 together: how to choose a style from the characteristics you need, how styles combine, and how to tell when an existing architecture should be replaced rather than patched.

See it builtThe Architecture styles track builds this style for one bike-share app, with code you can run: 16 Choosing and combining styles.

1. The idea

Planning a town, not a building. Housing, a market, a hospital and a power station each get the kind of building that suits them, connected by roads and utilities. Nobody insists the hospital look like the market for consistency. But every building type you add needs people who know how to run it, so a small town keeps the variety low.

Choosing a style is a sequence of questions you've already learned to answer:

  1. Which characteristics matter most? The top three from Module 04. Each style rates differently (the star tables in Modules 11–16).
  2. Do different parts need different characteristics? If yes, they need separate quanta (Module 09), which means a distributed style, or a hybrid.
  3. What shape is the domain? Variations by customer suggest microkernel; reactions to business events suggest event-driven; a few coarse areas suggest service-based (Module 09's table).
  4. What can the team build and run? Team size, skills, budget and deadline are constraints, not afterthoughts. A five-person team running forty microservices is a risk in itself.
  5. Record it. The choice, the alternatives and the trade-offs in a decision record (Module 27).

All the ratings in one place

Usually one deployment

CharacteristicLayeredModular monolithMicrokernelPipeline
Partitioningtechnicaldomaindomain and technicaltechnical
Quanta1111
Cost★★★★★★★★★★★★★★★★★★★★
Simplicity★★★★★★★★★★★★★★★★★★★★
Scalability★★★★★★★★★★★★★★★★★★★★
Elasticity★★★★★★★★★★★★★★★★★★★★
Fault tolerance★★★★★★★★★★★★★★★★★★★★
Evolvability★★★★★★★★★★★★★★★★★★★★
Deployability★★★★★★★★★★★★★★★★★★★★
Testability★★★★★★★★★★★★★★★★★★★★
Performance★★★★★★★★★★★★★★★★★★★★

Monolithic styles: one quantum, cheap and simple, limited in scale.

Distributed

CharacteristicService-basedEvent-drivenSpace-basedMicroservicesServerlessOrchestrated SOA
Partitioningdomaintechnicaltechnicaldomaindomaintechnical
Quanta1 to many1 to many1 to many1 to many1 to many1
Cost★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Simplicity★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Scalability★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Elasticity★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Fault tolerance★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Evolvability★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Deployability★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Testability★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★
Performance★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★

Our qualitative ratings, 1 to 5 stars, more is better (for cost, more stars = cheaper). They compare styles in general; your context can move any of them.

2. How it works

A hybrid, built one decision at a time

An online auction site. Each part gets the style its characteristics need. Press Play.

Patch or replace?

Architectures age. Watch one system over five years: when do incremental fixes stop being enough?

3. Try it yourself

Style finder

Choose your top three characteristics and any constraints that apply. Styles are ranked from the ratings above, adjusted by the constraints. It's a starting point for a decision, not the decision.

4. Trade-offs

One style vs a hybrid

One style is easier to learn, run and govern. A hybrid gives each part what it needs, at the cost of more kinds of things to build, test and operate. Mix styles only where a characteristic demands it.

Ratings vs context

Star ratings compare styles in general. Your team's experience, existing platform and domain can move any rating by a star or two. Use them to shortlist, then reason about the last two options in context.

Patch vs replace

Incremental change is cheaper and safer, until the architecture's basic shape is the problem. Replacement is expensive and risky, and sometimes the only way to meet new characteristics.

Build to last vs sacrificial

Designing for ten years of growth slows the first release. Sometimes it's right to build a simpler "sacrificial" architecture, deliberately, knowing it will be replaced once the product proves itself.

5. In real projects

Common hybrids: microservices that communicate through events (event-driven microservices); a layered or modular structure inside each service; a microkernel inside the service that handles variations; space-based units for the one hot path that bursts; a service-based core with a few microservices split off where they needed to scale.

Signs it's time to replace, not patch

SignWhat it looks like
Characteristics can't be metThe business now needs elasticity or availability the structure can't provide, and fixes only help at the edges.
The business changed shapeAn acquisition, new markets or a new business model the domain partitioning doesn't fit.
Structural decayCoupling everywhere, every change touches many parts, nobody understands the whole (Module 29 measures it).
Cost of change keeps risingEach release takes longer and breaks more, despite effort to improve it.

Even then, replace incrementally where you can (Module 30): carve off one part at a time, rather than a big-bang rewrite.

Say it in the interview

Two-sentence answers
  • "How do you choose an architecture style?" From the top characteristics, whether parts need different ones, the shape of the domain, and what the team can build and run. Then I record the choice and the alternatives in an ADR.
  • "Can you mix styles?" Yes, most real systems do: for example event-driven microservices, with space-based units for a hot path. Each style added needs a reason, because each adds operational variety.
  • "When would you replace an architecture?" When its basic shape stops it meeting characteristics the business now needs, or the domain has changed shape. Even then, replace incrementally rather than in one rewrite.
Red flags interviewers notice
  • Choosing a style before naming a characteristic.
  • "We'll rewrite it from scratch" as the first answer to decay.
  • A hybrid with a different style for every service and no reason for any of them.

6. Remember it

Memory hook: "Characteristics choose, constraints veto"The top characteristics shortlist the styles; team, budget and domain rule some out.
How this hook works: what "characteristics choose, constraints veto" means

What the slogan means, phrase by phrase

"Characteristics choose"
The top three characteristics rank the styles.
"constraints veto"
A small team, a tight budget or a transactional domain can rule out an otherwise good fit.

Why this picture fits: it puts the two inputs in the right order and stops the most common mistake: choosing the style the team wants to learn.

The story → the concept

Town planningArchitecture
Each building suits its useEach part gets the style its characteristics need
Roads and utilitiesEvents, APIs and contracts
A small town can't run everythingTeam and budget constraints
Regeneration, street by streetIncremental replacement

The trap it saves you from

Résumé-driven architecture: the style chosen because it's interesting, not because it fits.

7. Common mistakes

Style first, characteristics laterDeciding on microservices, then looking for reasons. Work from characteristics to style, never the reverse.
Ignoring team capacityThe best style the team can't operate is worse than a simpler one they can.
The big-bang rewriteReplacing everything at once takes longer than planned, while the old system keeps changing. Replace part by part.
Unexplained hybridsEvery extra style is more to learn and run. Each one needs a characteristic that justifies it.

8. Design exercise (30 minutes)

  1. Choose for three products (15 min). A payroll system for one company, a global ticketing site, and a tax product sold in 20 countries. Use the style finder for each, then argue with its answer.
  2. Draw one hybrid (10 min). For the ticketing site, assign a style to each major part and name the characteristic behind each choice.
  3. Replace or patch (5 min). For a system you know, check the four replacement signs. How many apply?

9. Self-check quiz

What should drive the choice of architecture style?

Characteristics choose; constraints veto.

When does a hybrid architecture make sense?

Different characteristics need different quanta, and often different styles.

What is a sacrificial architecture?

Speed to market now, with a plan to rebuild once the product proves itself.

Which is the strongest sign an architecture should be replaced?

Age and fashion aren't reasons; an unmeetable requirement is.

Top characteristics: cost, simplicity, testability. Small team. Which style family?

Monolithic styles rate highest on cost and simplicity, and suit small teams.

10. Go deeper

ResourceTimeWhy
Sacrificial Architecture (Martin Fowler)10 minBuilding to replace, deliberately, with real examples.
Fundamentals of Software Architecture, 2nd edition (Richards and Ford)bookThe chapter on choosing the appropriate architecture style.
Software Architecture Patterns, 2nd edition (Mark Richards)short bookEvery style side by side, with ratings.