Chapter 26 Flashcards — Architectural Intersections
flashcards fsa architectural-intersections generative-ai
Q: What is “structural integrity” in the context of architecture and implementation?
A: The principle that code structure must reflect architectural structure — component boundaries, dependency directions, and communication patterns must match the intended architecture. When they diverge, architectural drift occurs.
Q: What causes architectural drift?
A: (1) Delivery pressure leading to shortcuts across component boundaries, (2) developers not understanding the architectural intent, (3) absence of automated enforcement (no fitness functions), (4) new team members unaware of constraints.
Q: How do fitness functions enforce architectural constraints?
A: Automated tools (e.g., ArchUnit, Structure101) that run in CI pipelines and fail the build when architectural boundaries are violated — such as illegal imports, package dependency cycles, or service contract violations. They make constraints machine-enforceable rather than relying on human discipline.
Q: What is the “operational cost” principle for architects?
A: Every architectural decision creates operational burdens (deployment pipelines, monitoring, incident response). Architects must calculate and communicate this cost as part of trade-off analysis — not leave it for ops teams to discover. “If you design it, you own the operational complexity it creates.”
Q: Why is microservices architecture paired with container orchestration like Kubernetes?
A: Microservices require independent deployment, scaling, and health management per service. Container orchestration automates these concerns at scale; without it, the operational burden of managing dozens of services manually is prohibitive.
Q: What is the feedback loop between architecture and infrastructure?
A: Architecture drives infrastructure requirements, but infrastructure maturity also constrains realistic architectural choices. An organization lacking Kubernetes expertise cannot realistically operate microservices well; available managed cloud services also shape which architectural patterns are practical.
Q: What is the database topology for a monolith vs. microservices vs. event-driven architecture?
A: Monolith → single shared relational database. Microservices → per-service database (database-per-service pattern). Event-driven → event store (append-only log) as primary source of truth, with projections as read models.
Q: What is polyglot persistence?
A: Using different database technologies for different services, each optimized for its specific access patterns. A catalog service might use a document store; a recommendation service a graph database; a transaction service a relational database. Enabled by microservices and event-driven architectures.
Q: State the CAP theorem and its architectural implication.
A: In a distributed system, during a network partition you can guarantee either Consistency (all reads return the most recent write) or Availability (system remains operational) — but not both. Architects must make this choice explicitly per data domain, not globally for the entire system.
Q: What architectural pattern addresses systems with significantly divergent read and write patterns?
A: CQRS (Command Query Responsibility Segregation) — separates the write model (optimized for consistency and business rules) from the read model (optimized for query performance). Cost: synchronization complexity between the two models.
Q: What architectural decisions are required for read-heavy systems?
A: Caching layers (Redis, CDN), read replicas, CQRS read-optimized projections, denormalization of read models. Goal: reduce load on the write store and minimize read latency.
Q: What architectural decisions are required for write-heavy systems?
A: Write-optimized data stores (LSM-tree based like Cassandra), append-only event log patterns, async write paths to avoid blocking, horizontal partitioning (sharding) to distribute write load.
Q: What engineering practice is a prerequisite for microservices, and what happens without it?
A: Automated CI/CD per service. Without it: deployment becomes a bottleneck, services fall out of sync with each other, and teams lose the deployment independence that justifies the microservices complexity — “death by a thousand deployments.”
Q: Why does trunk-based development align with monolith architecture?
A: A monolith’s integration surface is large — all code integrates into a single deployable artifact. Integrating frequently (trunk-based) keeps that surface manageable. Long-lived feature branches compound merge conflicts exponentially in a monolith.
Q: What is the principle for matching architecture to engineering practices?
A: Don’t adopt an architectural style without also adopting the engineering practices it requires. This is an organizational and cultural commitment, not just a technical choice. The practices are prerequisites, not enhancements.
Q: State Conway’s Law.
A: “Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations.” (Mel Conway, 1967) Team boundaries become architectural boundaries.
Q: What is the inverse Conway maneuver?
A: Deliberately designing team topology to produce the desired architecture. If you want a microservices architecture with clean service boundaries, organize teams so each team owns one or a few services with minimal cross-team dependencies — the team communication structure then reinforces the architectural structure.
Q: Name the four team types from Team Topologies and their architectural roles.
A: (1) Stream-aligned team: owns services/components end-to-end for a user segment. (2) Enabling team: spreads architectural patterns and practices. (3) Platform team: owns infrastructure services as self-service capabilities. (4) Complicated-subsystem team: owns technically complex specialist components (ML, cryptography, real-time).
Q: What is “cognitive load” in Team Topologies, and why does it matter architecturally?
A: The total mental effort required for a team to understand and operate their system. Team topologies should be designed so each team’s cognitive load is manageable. Overly complex components assigned to a stream-aligned team create bottlenecks; extracting them to a complicated-subsystem team removes that load.
Q: What are the trade-offs of point-to-point integration?
A: Simple to implement; becomes fragile at scale because the number of integration paths grows as O(N²) — 10 services produce up to 90 directional integrations. Creates tight coupling between services; a change to one service may break multiple others.
Q: What are the trade-offs of event-driven (message bus) integration?
A: High decoupling between services; resilient to individual service failures; naturally supports async processing. Costs: events are contracts (schema changes break consumers), ordering is not guaranteed across partitions, tracing a business transaction across async hops requires purpose-built tooling.
Q: What is the role of an ESB (Enterprise Service Bus) in hub-and-spoke integration, and why did it fall out of favor?
A: The ESB acts as a central broker mediating all integration, providing centralized governance and transformation. It fell out of favor because it became a single point of failure, an operational bottleneck, and a “change magnet” — all integration changes required ESB team involvement.
Q: How should an architect approach Enterprise Architecture constraints?
A: Treat EA constraints like any other architectural constraint: understand the rationale, design within the constraint, and surface conflicts with clear trade-off documentation. Push back with data showing the EA constraint materially harms quality attributes — not based on preference.
Q: What are the key architectural layers in an LLM-augmented system?
A: Prompt engineering layer (prompt construction, templating, versioning), context management (what fits in context vs. retrieval), RAG layer (vector DB, embeddings, retrieval), model selection (capability/latency/cost/privacy), latency management (async/streaming), cost management (token cost, prompt caching), and observability (logging prompts and completions).
Q: What is RAG (Retrieval-Augmented Generation) and what architectural decisions does it involve?
A: A pattern for incorporating organizational knowledge into LLM systems without fine-tuning: retrieve relevant documents at query time and include them in the prompt context. Architectural decisions: embedding model selection, vector store selection (Pinecone, Weaviate, pgvector), chunking strategy, retrieval ranking, and re-ranking — each with latency/accuracy/cost trade-offs.
Q: Why is LLM latency a first-class architectural concern?
A: LLM inference latency is orders of magnitude higher than traditional API calls (hundreds of milliseconds to multiple seconds). Systems that call LLMs in synchronous request paths will have unacceptable user-facing latency. Architects must design for async responses, streaming, or pre-computation.
Q: What can generative AI tools do for architects, and what can they not do?
A: Can do: draft ADRs, explore trade-off spaces, generate documentation, review for common antipatterns. Cannot do: understand the organization’s specific constraints, team topology, and political context; make trade-off decisions involving organizational values or risk tolerance; replace judgment about which quality attributes matter most in a specific context.
Q: What data structure considerations influence architectural decisions for large objects (blobs)?
A: Large objects (video, images, documents) require object storage (S3-style), streaming APIs, and CDN consideration. They cannot be passed through standard event buses without size-limit workarounds. Services handling large objects need different API design (presigned URLs, chunked uploads) than services handling small records.
Q: What is the “practice mismatch” antipattern?
A: Adopting an architectural style without adopting the engineering practices it requires. Examples: microservices without CI/CD; event-driven without schema governance; distributed systems without distributed tracing. The result: the complexity costs of the style without the benefits.
Total Cards: 29
Estimated Review Time: ~25 minutes
Priority: HIGH
Last Updated: 2026-05-29