Chapter 19 Flashcards — Choosing the Appropriate Architecture Style
flashcards fsa choosing-architecture-style
What is the fundamental principle behind choosing an architecture style?
?
There is no universally “best” architecture style. The right choice depends on context — the architect’s job is to match the trade-off profile of a style to the specific constraints and goals of the system, not to follow trends or replicate what worked elsewhere.
What are the 8 key decision criteria for selecting an architecture style?
?
- Domain vs. technical partitioning preference
- Number of quanta needed (deployable units)
- Deployment granularity (coarse vs. fine)
- Workflow patterns (orchestration vs. choreography)
- Key architectural characteristics required (scale, agility, reliability)
- Team size and distribution
- Budget constraints
- Migration vs. greenfield context
Why is following architectural fashion dangerous?
?
Each architecture style emerged to solve specific problems of its era. Adopting a style without having those problems incurs all the costs while delivering none of the benefits. Example: adopting microservices for a 5-person team building an internal tool imposes distributed systems complexity with zero gain from independent deployability.
What diagnostic question should replace “what is best practice?”
?
“What problems does this style solve, and do we have those problems?” Best practice implies context-independence, which is almost never valid in architecture. The correct framing is always: what are my constraints, and which style’s trade-offs fit them best?
What is an architecture quantum and how does the number of quanta influence style selection?
?
An architecture quantum is the smallest independently deployable unit with high functional cohesion and its own architectural characteristics. If a system naturally decomposes into 1 quantum, monolithic styles are appropriate. Multiple quanta (each needing independent deployability or different characteristics) point toward distributed styles like microservices or service-based.
What team size constraint applies to microservices?
?
Microservices are only appropriate for large teams (typically 50+ engineers across multiple teams). The operational overhead — container orchestration, service discovery, distributed tracing, independent CI/CD pipelines — exceeds the management capacity of small teams. Conway’s Law ensures that teams and systems converge in structure anyway.
What is the Silicon Sandwiches case study scenario?
?
Silicon Sandwiches is a local sandwich chain building an online ordering system. Key constraints: small team (< 10 engineers), limited budget, complex configurable menu (toppings, bread, sauces), loyalty program, third-party delivery integration, low-to-moderate expected traffic (regional only, not internet-scale).
What are the key required characteristics for Silicon Sandwiches?
?
| Characteristic | Priority |
|---|---|
| Extensibility/Customizability | High — complex menu config, frequent changes |
| Simplicity | High — small team |
| Cost | High — small business |
| Testability | Medium |
| Scalability | Low — regional only |
Why does layered architecture fail for Silicon Sandwiches?
?
Layered architecture uses technical partitioning, spreading menu logic across presentation, domain, and data layers. Adding a new menu customization or discount type requires changes in every layer. This fails the extensibility requirement and creates tight cross-layer coupling — it is the cheapest to build but the worst structural fit for the domain.
What architecture wins for Silicon Sandwiches and why?
?
Microkernel or Modular Monolith wins. Microkernel is ideal if extensibility is the primary driver — each menu customization, discount rule, or delivery partner integration becomes a plugin. Modular Monolith wins if domain organization and team structure matter most. Both are single-deployment units (low operational cost) with strong testability and good extensibility.
Why would microservices be wrong for Silicon Sandwiches?
?
Microservices require independent deployability, internet-scale traffic, and a large multi-team organization to justify their costs. Silicon Sandwiches has none of these: traffic is regional and modest, the team is small, and the budget is constrained. Adopting microservices would impose Kubernetes, distributed tracing, and multiple CI/CD pipelines on a system that gains nothing from them.
What is the Going, Going, Gone case study scenario?
?
Going, Going, Gone is an internet-scale online auction platform. Key characteristics: millions of concurrent users during popular auctions, real-time bid processing (stale data = wrong auction outcome), high availability (downtime = financial/legal liability), elastic traffic (spikes at auction close), large engineering organization, complex multi-domain workflows.
What are the critical architectural characteristics for Going, Going, Gone?
?
| Characteristic | Priority |
|---|---|
| Scalability | Critical — internet-scale concurrent bidding |
| Elasticity | Critical — traffic spikes at auction close |
| Availability | Critical — downtime during live auction is catastrophic |
| Real-time responsiveness | High — bids must be near-instantaneous |
| Fault tolerance | High — partial failure must not collapse auctions |
| Agility | High |
What architecture wins for Going, Going, Gone and why?
?
Event-Driven Architecture combined with Microservices. The real-time bidding hot path maps naturally to event-driven processing (bids as events, elastic consumers, Kafka-partitioned by auction). Domain services (Listings, Payments, Users) operate as microservices with synchronous APIs for non-real-time operations. This combination captures elasticity on the hot path and domain isolation across the system.
Why are monolithic styles eliminated for Going, Going, Gone?
?
Scalability and elasticity requirements eliminate all monolithic styles. A monolith cannot elastically scale individual hot components (bid processing) independently of cold components (user management). Single-deployment units also create availability risk — a deployment or crash affects the entire system. Service-based architecture is eliminated because the real-time event processing requirements exceed what synchronous inter-service calls can deliver.
What is the trade-off between simplicity and scalability in architecture selection?
?
Simplicity and scalability are inversely correlated in most styles. Layered monoliths are the simplest and cheapest to build but cannot scale individual components. Microservices are the most scalable but the most complex and expensive to operate. Architects should choose the simplest style that satisfies the scalability requirement — not the most scalable style available.
When is a monolith actually better than microservices?
?
A monolith is better when: (1) the team is small (< 10–20 engineers); (2) the budget is constrained; (3) scalability requirements are modest; (4) all domains deploy together naturally; (5) operational simplicity is a first-class requirement. Microservices add cost and complexity that only pays off when independent deployability and large-team coordination are genuine problems.
What is the role of budget as an architectural characteristic?
?
Cost is a legitimate, first-class architectural characteristic that constrains style selection. Space-based and microservices architectures require significant investment in infrastructure (container orchestration, service mesh, distributed observability). When budget is limited, these styles must be eliminated from consideration even if they theoretically fit the technical requirements.
How should a migration from a legacy monolith be approached?
?
Use the modular monolith as an intermediate step: decompose the big ball of mud into clearly bounded modules first, while keeping a single deployment unit. This reduces risk (no distributed systems overhead), improves testability, and makes boundaries explicit. Once modules are stable, individual services can be extracted if independently deployability becomes necessary.
How does Conway’s Law affect architecture style selection?
?
Conway’s Law states that systems mirror the communication structures of the teams that build them. A single tightly coupled team will naturally produce a monolith; siloed functional teams produce layered architectures; cross-functional domain teams produce domain-partitioned systems. Architects must either design for their current team structure or deliberately restructure teams (Inverse Conway Maneuver) to match the desired architecture.
What is the difference between agility and scalability as architectural characteristics, and which styles serve each?
?
Agility is the ability to respond quickly to change — adding features, changing behavior, deploying independently. Scalability is the ability to handle increased load. High-agility styles: microservices, modular monolith (easy to change bounded domains). High-scalability styles: microservices, event-driven, space-based. Layered architecture scores poorly on both; modular monolith scores high on agility but moderate on scalability.
What is the stepped decision process for narrowing architecture style candidates?
?
- Count quanta: 1 → monolithic; multiple → distributed
- Identify primary driver: simplicity → layered/pipeline; extensibility → microkernel; domain isolation + single deploy → modular monolith; independent deploy → service-based/microservices; real-time events → event-driven
- Apply team size: < 10 → avoid distributed; < 50 → service-based ceiling; 50+ → microservices viable
- Apply budget: low → eliminate microservices/space-based
- Consider migration: brownfield → modular monolith first
Why did SOA fall out of favor and how did microservices address its problems?
?
SOA’s central ESB (Enterprise Service Bus) became a bottleneck and single point of failure. Business logic migrated into the ESB itself, making it a smart pipe that violated the separation of concerns. Microservices replaced the ESB with dumb pipes (lightweight messaging or REST), pushing all logic into the services — enabling true independence and eliminating the centralized coupling SOA created.
What caused the modular monolith to re-emerge as a recommended style in the 2020s?
?
The over-application of microservices — teams adopting microservices for systems that did not need independent deployability or extreme scale — created unnecessary operational complexity. The modular monolith re-emerged as a correction: it provides domain isolation and good testability within a single deployable unit, eliminating distributed systems overhead for the majority of systems that do not genuinely need it.