Chapter 09 Flashcards — Architecture Styles Foundations
flashcards fsa architecture-styles-foundations
What is the difference between an architecture style and an architecture pattern?
?
An architecture style defines the named, recognized structure of a whole system (e.g., layered, microservices). An architecture pattern is a reusable solution to a recurring local design problem within a component (e.g., CQRS, Circuit Breaker). Styles answer “what does the whole system look like?”; patterns answer “how do I solve this specific structural problem here?”
What is the Big Ball of Mud?
?
The Big Ball of Mud is an anti-style where a system has no discernible architecture — components couple to each other arbitrarily, structure has eroded, and change anywhere causes unpredictable ripples everywhere. It is the most common real-world architecture, arising by default in the absence of active governance, not by deliberate choice.
Why is the Big Ball of Mud so common despite being harmful?
?
It forms because teams prioritize short-term velocity over structure: shortcuts become permanent, tribal knowledge is lost through turnover, no fitness functions enforce boundaries, and technical debt accumulates invisibly. It feels fast to build initially but becomes catastrophically expensive to change later.
What is technical partitioning?
?
Technical partitioning organizes components by their technical role — all UI code together, all business logic together, all persistence code together — creating horizontal layers. It is the defining feature of layered architecture, aligns naturally with skill-based teams (frontend/backend/DBA), but means any cross-cutting feature change touches every layer.
What is domain partitioning?
?
Domain partitioning organizes components by business capability — all code for “Orders” (UI + logic + data) lives together, all code for “Inventory” lives together. It maximizes cohesion within a domain, enables independent team ownership, and contains feature changes within a single domain — at the cost of higher initial complexity and potential code duplication.
What is the key trade-off between technical and domain partitioning?
?
Technical partitioning is simpler initially and suits skill-based teams, but cross-cutting features require changes in every layer, limiting long-term agility. Domain partitioning is more complex initially but contains changes within a domain, enabling independent team evolution — making it preferable for growing systems with distinct business capabilities.
What is Conway’s Law?
?
Conway’s Law (Melvin Conway, 1968) states: “Organizations which design systems are constrained to produce designs which are a copy of the communication structures of those organizations.” In practice, team boundaries become architectural boundaries — siloed technical teams produce layered architectures; cross-functional domain teams produce domain-partitioned architectures.
What is the Inverse Conway Maneuver?
?
The Inverse Conway Maneuver deliberately restructures teams to match the desired architecture, rather than letting existing team structure dictate architecture. If you want domain-aligned microservices, create cross-functional teams per domain first — the architecture follows the team structure.
What is an architecture quantum?
?
An architecture quantum is the smallest independently deployable artifact that has high functional cohesion and high static coupling. A monolith has a quantum of 1 (one deployment unit). A microservices system has a quantum equal to the number of services. The quantum defines the granularity of independent operability and deployment.
What is the first fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 1: The Network Is Reliable. In practice, networks drop packets, routers fail, and cables are cut. Any network call can fail. Distributed systems must implement retries with backoff, circuit breakers, timeouts, and graceful degradation — never assuming calls will succeed.
What is the second fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 2: Latency Is Zero. In practice, a network round-trip takes microseconds to milliseconds — orders of magnitude slower than in-process calls. Architects must measure p95/p99 latency and avoid chatty communication patterns. Prefer coarse-grained, batch-friendly APIs in distributed contexts.
What is the third fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 3: Bandwidth Is Infinite. In practice, bandwidth is finite and shared. Large payloads, high-frequency polling, and naive replication can saturate links. Architects must consider payload size, compression, pagination, and delta-based event patterns.
What is the fourth fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 4: The Network Is Secure. In practice, data in transit can be intercepted or tampered with. Distributed systems require TLS/mTLS for service-to-service communication, proper secret management, zero-trust network design, and proactive threat modeling of all network surfaces.
What is the fifth fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 5: The Topology Never Changes. In practice, cloud environments are ephemeral — VMs are replaced, IPs change, services scale in and out. Hardcoding IPs or assuming fixed topology creates brittle systems. Solutions include service discovery, DNS-based resolution, and service meshes.
What is the sixth fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 6: There Is Only One Administrator. In practice, different teams own different infrastructure layers (network, cloud, DBA, security, application). Distributed systems span organizational boundaries. Architects must account for multi-team ownership and clear operational contracts between services.
What is the seventh fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 7: Transport Cost Is Zero. In practice, transport has two costs: (1) the financial cost of bandwidth (especially cloud egress fees), and (2) the computational cost of serialization/deserialization. At scale, these are non-trivial — architects must choose serialization formats (JSON vs. Protobuf vs. Avro) with payload size and processing overhead in mind.
What is the eighth fallacy of distributed computing, and what does it mean in practice?
?
Fallacy 8: The Network Is Homogeneous. In practice, modern systems span multiple clouds, on-premise infrastructure, legacy systems, third-party APIs, IoT, and mobile — each potentially using different protocols and encodings. Architects must design for interoperability via API gateways, protocol translation, and schema registries.
Who originally articulated the 8 Fallacies of Distributed Computing?
?
Originally articulated by Peter Deutsch at Sun Microsystems (the first 7), later extended to 8 by James Gosling. They remain foundational warnings for any distributed systems architect.
What are the key advantages of a monolithic architecture over a distributed one?
?
Monolithic architectures offer: simple deployment (one unit), no network latency for internal calls, easy ACID transactions without distributed coordination, straightforward debugging (single process), and lower operational complexity. Architecture quantum = 1.
What are the key advantages of distributed architecture over a monolithic one?
?
Distributed architectures offer: independent scaling of components, independent deployment (update one service without touching others), technology heterogeneity, and fault isolation (one service failure doesn’t cascade). The trade-off is full exposure to the 8 fallacies and high operational complexity.
What is the Silicon Sandwiches Kata, and what partitioning does it recommend?
?
The Silicon Sandwiches Kata designs an online ordering system for a sandwich shop chain. The business has distinct capabilities (Menu, Orders, Payment, Loyalty, Inventory, Delivery). Despite being a small team, domain partitioning is recommended — business capabilities map cleanly to domains, enabling a modular monolith that can later extract services without rewriting.
What is team cognitive load, and why does it matter for architecture?
?
Team cognitive load (from Team Topologies by Skelton & Pais) is the mental effort required for a team to understand and effectively own their system. Architecture partitioning must be sized so each team’s domain fits within their cognitive capacity. Overloading a team with too large or too complex a domain degrades productivity and quality — architects must design boundaries with this in mind.
What is a “Unitary Architecture”?
?
A Unitary Architecture is a single monolithic deployment with no logical separation into tiers or layers — everything runs in one process, one machine. The earliest form of software architecture (e.g., mainframe applications). Appropriate only for very small, embedded, or single-purpose systems. Not to be confused with a layered monolith, which does have logical separation.
What is the Client/Server (2-tier) style, and what are its limitations?
?
The Client/Server (2-tier) style divides a system into a client (handles UI and user interaction) and a server (handles logic and data). Dominant in the 1990s for thick-client desktop apps. Limitations: tight coupling between presentation and data, poor scalability, and difficulty separating business logic from data access — which drove evolution to 3-tier and n-tier architectures.
In the context of Conway’s Law, what team structure produces a layered architecture?
?
Skill-based teams — separate frontend, backend, and DBA teams — naturally produce a technically partitioned (layered) architecture because team communication boundaries become system boundaries. Conway’s Law predicts the team structure will be replicated in the system’s design.
What is the difference between monolithic quantum and distributed quantum architectures?
?
A monolithic quantum (=1) means the entire system is deployed as one unit — no independent deployment, all components share the same process. A distributed quantum (>1) means components are independently deployable units — each can be scaled, deployed, and failed independently, but all network fallacies apply to their communication.
How should architects handle the “Topology Never Changes” fallacy in cloud environments?
?
Use service discovery (Consul, Kubernetes DNS) instead of hardcoded IPs, service mesh (Istio, Linkerd) for dynamic routing and mTLS, infrastructure-as-code to manage topological changes consistently, and health checks + circuit breakers to adapt to topology changes at runtime. Assume IPs and routes will change.
What governance mechanisms prevent a system from becoming a Big Ball of Mud?
?
Fitness functions (automated architectural tests that enforce constraints), architecture decision records (ADRs) to document and ratify decisions, dependency analysis tools (ArchUnit, Dependency Cruiser) to detect forbidden couplings, regular architecture review sessions, and enforced module/package boundaries via build system rules.
Priority: HIGH — foundational concepts for all subsequent architecture style chapters