3. Architectural Models, Patterns, and Decision Frameworks

Introduction and Context

Cloud and edge systems are not defined merely by the use of virtual machines, containers, or remote data centres. Their effectiveness depends on architectural decisions: how responsibilities are divided, how services communicate, where computation is placed, how failure is contained, and how the system evolves under changing workloads. Architecture therefore provides the reasoning structure through which technical components become an operational system.

In cloud and edge computing, architectural choices are particularly consequential. Cloud platforms offer elastic capacity, managed services, global reach, and programmable infrastructure. Edge environments introduce proximity to users and devices, but also distribution, intermittent connectivity, limited resources, physical exposure, and operational heterogeneity. A design that is appropriate for a centralized cloud may be unsuitable at the edge, while a design optimized for low latency may increase cost, complexity, and governance risk.

This chapter examines major architectural models and patterns used in cloud and edge systems. It then develops a decision framework based on quality attributes, domain-driven design, trade-off analysis, and architecture decision records. The emphasis is not on selecting a fashionable style, but on justifying an architecture in relation to a system’s domain, constraints, risks, and expected evolution.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the structure and purpose of layered, service-oriented, microservices, event-driven, serverless, multi-tier, federated, mesh, and reference architectures.

2. Distinguish architectural styles from patterns, deployment models, and implementation technologies.

3. Evaluate architectures using quality-attribute scenarios and explicit trade-off analysis.

4. Apply domain-driven design to identify bounded contexts and service boundaries.

5. Select suitable architectural combinations for cloud and edge workloads.

6. Construct architecture decision records that document alternatives, assumptions, consequences, and governance implications.

7. Critically assess operational, security, ethical, and organizational risks associated with distributed architectures.

Architecture as a Set of Explicit Decisions

An architectural model is an abstract representation of how a system is organized. It identifies major elements, their responsibilities, relationships, constraints, and mechanisms for interaction. An architectural style is a recurring way of structuring these relationships, such as layered architecture or event-driven architecture. An architectural pattern is a reusable solution to a recurring design problem within a particular context, such as an API gateway, circuit breaker, sidecar, or strangler migration. A reference architecture is a generalized blueprint that organizes recommended capabilities for a class of systems without prescribing every implementation detail.

These distinctions matter because architecture is often discussed imprecisely. “Microservices architecture,” for example, describes a decomposition and deployment approach, whereas Kubernetes is an orchestration platform and a service mesh is a communication infrastructure pattern. A system may use all three, but they are not equivalent concepts. Similarly, “serverless” does not mean that servers do not exist; it means that infrastructure provisioning and much operational management are delegated to a platform, normally with event-driven or usage-based execution.

Architecture operates at several levels. Enterprise architecture connects business capabilities, information, applications, technology, and governance. Solution architecture describes a particular system or product. Software architecture focuses on modules, services, interfaces, and runtime behavior. Deployment architecture maps logical components to cloud regions, edge nodes, networks, and devices. A defensible design maintains traceability across these levels.

A useful architectural description answers five questions:

• What responsibilities exist, and where are they located?
• How do components communicate and coordinate?
• Which quality attributes are prioritized?
• How are failures, change, security, and governance handled?
• What assumptions make the design valid?

The Architectural Landscape

Layered and Multi-Tier Architectures

Layered architecture organizes functionality into levels with defined dependency directions. A common arrangement contains presentation, application, domain, and infrastructure layers. Each layer exposes services to the layer above and depends on selected services below. The principal benefit is separation of concerns: user-interface changes need not alter domain rules, and infrastructure mechanisms can be replaced behind stable abstractions.

A multi-tier architecture is related but emphasizes physical or deployment separation. A three-tier web system may place presentation components, application logic, and databases on distinct tiers. Layering is primarily a logical organization; tiering is primarily a deployment organization. The two can coincide, but they need not. A layered application can be deployed as one process, while a multi-tier system may contain poorly separated logic.

Layered and multi-tier designs remain effective for transactional systems, administrative applications, and systems where strong consistency and centralized governance are more important than independent service scaling. Their weaknesses arise when dependencies cross layers excessively, when a shared database becomes a bottleneck, or when all components must be released together. In edge computing, a tiered design may place device functions at the far edge, filtering and control at an intermediate edge, and historical analytics in the cloud. The critical issue is deciding which data and decisions must remain local.

Service-Oriented Architecture

Service-oriented architecture (SOA) structures capabilities as relatively autonomous services that communicate through explicit contracts. Services may be coarse-grained and aligned with organizational or business capabilities. SOA traditionally emphasizes enterprise integration, reusable services, governance, canonical data models, and mediation through enterprise service buses or similar integration mechanisms.

SOA is valuable where heterogeneous systems must interoperate, particularly in large organizations with legacy applications, regulatory controls, and shared business processes. Its risks include excessive central governance, complex mediation layers, shared schemas, and service contracts that evolve slowly. In cloud settings, SOA can provide a transitional structure for modernizing legacy systems, but its integration mechanisms should not become a single point of failure or a bottleneck for autonomous teams.

Microservices Architecture

Microservices decompose an application into independently deployable services, usually organized around business capabilities. Each service owns a well-defined responsibility and ideally controls its data. Services communicate through lightweight synchronous APIs, asynchronous messages, or both. Independent deployment permits teams to release, scale, and replace services separately.

The central design problem is not creating small services; it is establishing boundaries that preserve meaningful autonomy. Excessive decomposition produces distributed monoliths: systems with many deployable units but strong runtime and release coupling. Symptoms include chains of synchronous calls, shared databases, duplicated business rules, and coordinated releases.

Microservices can improve organizational scalability and fault isolation, but they impose costs in observability, testing, data consistency, network reliability, security, and platform operations. At the edge, microservices may be useful for modular gateways or local analytics, but deploying a large number of services to resource-constrained nodes can create unacceptable overhead. A practical design often uses fewer, coarser-grained services at the edge and more specialized services in regional or central cloud environments.

Event-Driven Architecture

Event-driven architecture uses events to communicate that something has happened, such as “temperature threshold exceeded” or “payment authorized.” Producers publish events without necessarily knowing all consumers. Consumers react independently, allowing temporal decoupling and scalable fan-out. Event streams can support real-time analytics, audit histories, workflow initiation, and integration between bounded contexts.

Events differ from commands. A command requests an action from a specific recipient; an event records a fact that may interest multiple recipients. Confusing these concepts can produce unclear ownership and accidental coupling. Event-driven systems also require decisions about delivery semantics, ordering, replay, retention, schema evolution, idempotency, and dead-letter handling.

Event-driven architecture is especially suitable for edge telemetry, industrial monitoring, logistics, and systems in which producers and consumers operate intermittently. Local edge nodes can buffer events during network disruption and forward them when connectivity returns. However, event-driven designs do not eliminate consistency problems. They replace immediate coordination with eventual convergence and require compensating actions when workflows fail.

Serverless Architecture

Serverless architecture uses managed execution environments in which developers provide functions, containers, or application logic while the platform manages much of the runtime infrastructure. Functions are commonly triggered by HTTP requests, messages, schedules, file uploads, or database changes. Managed databases, queues, identity services, and workflow engines are often combined with functions.

Serverless can reduce operational work, support rapid experimentation, and align cost with invocation or resource consumption. It is attractive for sporadic workloads, event transformation, automation, and integration. Constraints include startup latency, execution limits, provider-specific interfaces, debugging complexity, concurrency controls, and potential cost unpredictability at high volume. A serverless system may also suffer from fragmented observability when a business transaction crosses many managed services.

Serverless at the edge is developing through distributed function runtimes and edge-compute platforms. The benefits include low-latency personalization, content transformation, and local policy enforcement. Yet edge serverless execution must address restricted runtime capabilities, data residency, limited local state, and inconsistent platform support. Serverless is therefore a deployment and operating model, not a universal replacement for services or databases.

Federated Architectures

A federated architecture coordinates multiple independently governed domains, platforms, organizations, or cloud providers. Each member retains significant autonomy while agreeing on interfaces, identity mechanisms, data-sharing rules, and governance principles. Federated cloud and edge systems may connect regional clouds, institutional platforms, telecommunications networks, and private infrastructure.

Federation is valuable when centralized ownership is impossible or undesirable. It can improve sovereignty, resilience, geographic reach, and compliance flexibility. It also introduces trust negotiation, inconsistent capabilities, policy conflicts, identity federation, and complex incident response. Federation should therefore specify which concerns are standardized globally and which remain locally controlled. A useful principle is “federate interfaces and policies where necessary, but avoid centralizing every implementation decision.”

Service Mesh Architecture

A service mesh provides a dedicated infrastructure layer for service-to-service communication. Sidecar proxies or node-level components commonly handle traffic routing, mutual TLS, retries, timeouts, authorization policies, telemetry, and traffic shaping. This can remove communication concerns from application code and support consistent controls across services.

The mesh is most beneficial when a system has many services, multiple deployment environments, and demanding communication-policy requirements. It can enable canary releases, circuit breaking, and identity-aware access. However, it adds control-plane and data-plane complexity, resource consumption, debugging challenges, and another operational dependency. A mesh should not be adopted simply because an organization uses containers. At constrained edge locations, a full mesh may be excessive; selective proxies or simpler gateway patterns may be more appropriate.

Reference Architectures

A reference architecture identifies recurring capabilities, relationships, and controls for a class of systems. A cloud-and-edge reference architecture might include device management, secure ingestion, local processing, regional aggregation, central analytics, identity, policy management, observability, and lifecycle automation. It is not a concrete design. Its value lies in accelerating analysis, exposing omissions, and providing a common vocabulary.

Reference architectures must be adapted rather than copied. A healthcare monitoring platform, an autonomous vehicle system, and a retail recommendation service may all use edge processing, but they differ radically in safety, privacy, latency, and assurance requirements. Treating a reference architecture as a compliance checklist can conceal rather than resolve architectural risk.

Quality Attributes and Scenario-Based Evaluation

Functional requirements describe what a system does; quality attributes describe how well it does it under specified conditions. Important attributes for cloud and edge architectures include availability, latency, throughput, scalability, resilience, modifiability, interoperability, security, privacy, observability, portability, cost efficiency, and sustainability.

Quality attributes become analytically useful when expressed as scenarios. A quality-attribute scenario normally specifies:

1. Source: the actor or condition initiating an event.

2. Stimulus: the event or demand placed on the system.

3. Environment: the operating circumstances.

4. Artifact: the component or system affected.

5. Response: the behavior expected.

6. Response measure: the criterion used to evaluate success.

For example: “When connectivity between an agricultural edge gateway and the regional cloud is lost, the gateway shall continue local irrigation decisions for up to four hours and synchronize records within ten minutes of reconnection.” This scenario makes resilience, autonomy, data durability, and synchronization measurable. It also exposes design questions that a vague requirement such as “the system must be reliable” would hide.

Quality attributes frequently conflict. Strong encryption and detailed inspection may increase latency. Replication may improve availability but raise cost and consistency complexity. Data minimization may reduce privacy risk but limit analytics. Edge processing can reduce network delay and bandwidth consumption while increasing fleet-management burden. Architecture is therefore a process of reasoned compromise, not the maximization of every desirable property.

Trade-Off Analysis and Architectural Reasoning

Trade-off analysis begins by identifying decision drivers: the few quality attributes and constraints that most strongly shape the design. A system requiring sub-second control responses, for example, should not depend on a distant cloud transaction for every decision. A system subject to strict data residency rules may require local storage even if centralized analytics would be simpler.

One useful method is to compare candidate architectures against weighted criteria. Scores should not be treated as objective measurements unless supported by experiments; they are structured judgments. More rigorous analysis uses prototypes, load tests, failure injection, cost models, and threat assessments. The analysis should distinguish reversible from difficult-to-reverse decisions. Choosing an API framework is usually more reversible than selecting a data ownership model or committing to a proprietary event platform.

Architects should examine at least four forms of coupling:

• Temporal coupling: components must be available simultaneously.
• Spatial coupling: components depend on a particular location or network path.
• Semantic coupling: components depend on shared meanings, schemas, or business rules.
• Operational coupling: components require coordinated deployment, monitoring, or recovery.

Cloud and edge designs should deliberately reduce unnecessary coupling, but not all coupling is harmful. Strong transactional coupling may be justified in financial accounting; local coupling may be necessary for safety-critical control. The question is whether the coupling is visible, justified, and governed.

Domain-Driven Design and Service Boundaries

Domain-driven design (DDD) provides a way to align software structure with the problem domain. It distinguishes the domain model—the concepts and rules that express business meaning—from technical infrastructure. Strategic DDD identifies bounded contexts: explicit boundaries within which terms, models, and invariants have consistent meanings.

Bounded contexts are valuable in microservices and event-driven systems because they prevent a single universal model from becoming a source of organizational and technical coupling. The term “customer,” for instance, may mean an account holder in billing, a device owner in telemetry, and a service recipient in support. Each context may require a different model and should exchange only the information needed at its boundary.

A service boundary should be tested against several questions: Does the service own a coherent business capability? Can its data and rules evolve together? Can a team understand and operate it? Does it have a clear consistency boundary? Is its interface meaningful to consumers? Boundaries based only on nouns, database tables, or organizational reporting lines are often weak.

DDD also supports tactical patterns such as aggregates, repositories, domain events, and anti-corruption layers. An aggregate defines a consistency boundary; an anti-corruption layer protects one model from the assumptions of another. In a federated edge environment, such layers are important when local platforms use different device, identity, or asset models.

Architecture Decision Records

An architecture decision record (ADR) is a concise, durable record of a significant architectural decision. A strong ADR normally includes the title, status, context, decision, alternatives considered, rationale, consequences, assumptions, and review conditions. The purpose is not bureaucracy. It is to preserve reasoning so that future engineers can understand why a decision was made and when it should be revisited.

For example:

Decision: Use local event buffering at edge gateways rather than synchronous forwarding for telemetry.

Context: Connectivity is intermittent, and control decisions must continue during outages.

Alternatives: Require continuous connectivity; store only in device memory; use a regional intermediary.

Rationale: Durable local buffering supports autonomy and eventual synchronization while avoiding data loss during short outages.

Consequences: The system must manage local storage limits, duplicate events, ordering gaps, encryption, and reconciliation.

Review trigger: Reassess when outage duration, telemetry volume, or regulatory retention requirements change.

ADRs should record rejected alternatives, not merely the selected option. They should also identify assumptions that can be tested. A decision based on an assumed network latency, event volume, or provider feature becomes a candidate for validation. In doctoral research and advanced professional practice, ADRs can serve as evidence of design reasoning and as instruments for longitudinal architectural evaluation.

Applied Case: Distributed Cold-Chain Monitoring

Background

The following is an illustrative case. A logistics organization transports temperature-sensitive medicines through warehouses, trucks, and regional distribution centres. Each shipment contains sensors that report temperature, humidity, location, and battery status. Regulatory and contractual obligations require an auditable record of excursions and timely intervention.

Situation and Problem

The existing system sends every sensor reading to a central cloud service. Cellular connectivity is unreliable in some routes, and the central service occasionally receives bursts of delayed data. Drivers and warehouse operators need immediate warnings, while compliance officers require complete historical records. The organization is considering a microservices redesign with cloud analytics and edge gateways.

Analysis

The dominant quality attributes are local response time, data integrity, resilience, security, and auditability. A cloud-only synchronous design is unsuitable because an intervention cannot depend on continuous connectivity. A fully autonomous device design would be difficult to govern and maintain. The architecture must therefore distribute responsibility.

DDD analysis identifies bounded contexts for shipment management, sensor telemetry, alerting, fleet operations, and compliance reporting. Shipment management owns shipment status and custody transitions. Telemetry owns measurements and quality metadata. Alerting consumes telemetry events but does not own shipment definitions. Compliance reporting requires immutable or controlled records and traceable transformations.

Approach and Solution

A gateway at each warehouse and selected vehicle aggregates sensor data, performs validation, detects threshold violations, and stores encrypted events locally. It publishes local alerts immediately. When connectivity exists, the gateway forwards events to a regional ingestion service, which distributes them to cloud consumers through an event backbone.

Cloud services use separate bounded contexts and independently scalable storage. An event schema includes sensor identity, measurement time, gateway receipt time, sequence information, provenance, and integrity metadata. Consumers are idempotent because retransmission is expected. A reconciliation process identifies missing sequences and conflicting timestamps.

A service mesh is used only in the regional and central cloud clusters, where service density and policy requirements justify it. Edge gateways use a simpler secure communication layer to reduce resource consumption. Serverless functions transform selected events and trigger notifications, while long-running services manage reconciliation and compliance workflows.

An ADR records the decision to treat the gateway as an autonomous operational boundary. Another records the decision to separate telemetry ownership from shipment ownership. Quality-attribute scenarios define measurable targets for alert generation during disconnection, synchronization after reconnection, and preservation of audit records.

Outcome

The proposed architecture improves local responsiveness and tolerates temporary network failure. It also introduces new responsibilities: gateway provisioning, certificate rotation, local storage management, software update safety, event deduplication, and monitoring of disconnected nodes. The architecture is therefore not judged successful solely because it uses edge computing; it is successful if the distributed responsibilities remain controllable and the quality scenarios are satisfied.

Learning Points

The case illustrates that architectural styles are combined selectively. Event-driven communication supports buffering and fan-out; DDD defines ownership; edge deployment supports local autonomy; cloud services support aggregation and analytics; and ADRs preserve the reasoning. No single style solves all concerns. The design succeeds through explicit boundaries and managed trade-offs.

Risks, Limitations, and Common Mistakes

A common mistake is adopting microservices before establishing domain boundaries. This creates network calls where function calls would have been sufficient and multiplies operational work. Another is treating asynchronous communication as automatically scalable or reliable without addressing ordering, retries, duplicate delivery, and replay.

Architectures also fail when non-functional requirements are left until implementation. Latency, recovery objectives, data residency, and cost limits should influence placement and communication choices from the beginning. Edge projects frequently underestimate fleet operations: secure enrollment, remote updates, hardware variation, clock synchronization, physical tampering, and observability during disconnection.

Vendor lock-in is another concern. Managed services can accelerate delivery but may embed proprietary data models, identity mechanisms, or event semantics. Portability should be defined carefully; duplicating every capability across providers may cost more than the risk it reduces. Likewise, service meshes and orchestration platforms can produce a sophisticated control plane that the organization lacks the skills to operate.

Architecture diagrams may also mislead when they show components but not runtime behavior. Effective evaluation includes failure paths, degraded modes, data flows, trust boundaries, and recovery procedures. Resilience is not demonstrated by drawing redundant boxes; it is demonstrated through tests and measurable recovery behavior.

Governance, Ethics, and Professional Responsibility

Distributed architectures expand the governance surface. Data may cross jurisdictions, pass through third-party platforms, or remain on physically exposed edge devices. Architects must establish data classification, retention, access control, encryption, key management, auditability, and deletion procedures. Privacy-by-design principles require collecting only necessary data, limiting secondary use, and making processing understandable to affected individuals.

Architectural decisions can also create social consequences. Automated edge decisions in healthcare, employment, transport, or public services may affect people without immediate human review. Designers should identify accountability, error-handling, contestability, and bias risks. Security controls must protect not only cloud APIs but also devices, supply chains, update mechanisms, identities, and local caches.

Professional responsibility includes communicating uncertainty. An ADR should not present an estimate as a fact or conceal operational costs behind an attractive performance claim. Governance should include architecture review, threat modeling, privacy assessment, disaster-recovery exercises, and periodic reassessment of assumptions.

Emerging Directions

Several developments are shaping architectural practice. Confidential computing and hardware-backed trust may allow sensitive processing closer to data sources. Distributed digital twins combine telemetry, simulation, and operational models across edge and cloud environments. Policy-as-code is increasingly used to automate security, compliance, and deployment constraints. Platform engineering seeks to provide reusable internal capabilities so application teams can adopt distributed patterns without independently rebuilding infrastructure.

AI workloads are also encouraging heterogeneous placement. Inference may occur at the edge for latency or privacy, while model training and fleet-wide analysis occur in centralized environments. This creates challenges in model versioning, drift detection, provenance, energy use, and safe rollback. Autonomous operations may assist with capacity management and anomaly detection, but automated remediation requires bounded authority and human oversight.

The continuing trend is not toward one dominant architecture. It is toward composable architectures in which centralized, regional, edge, event-driven, and managed components are combined according to explicit decision criteria.

Best Practices for Architectural Decision-Making

Effective practice can be summarized as follows:

1. Begin with business capabilities, operating constraints, and quality-attribute scenarios rather than technology preferences.

2. Separate logical architecture from deployment architecture, then map the two deliberately.

3. Establish bounded contexts and ownership before splitting services.

4. Use asynchronous communication where temporal decoupling has clear value, and document consistency consequences.

5. Place computation and data according to latency, resilience, privacy, cost, and governance requirements.

6. Treat edge nodes as a managed fleet with identity, update, observability, and recovery capabilities.

7. Use platforms and service meshes selectively; complexity must be justified by measurable needs.

8. Record significant decisions, alternatives, assumptions, and review triggers in ADRs.

9. Validate architectural claims with prototypes, load tests, security analysis, and failure exercises.

10. Revisit architecture when domain boundaries, workloads, regulations, or organizational capabilities change.

Chapter Summary

Architectural models provide alternative ways to organize responsibilities, communication, deployment, and governance in cloud and edge systems. Layered and multi-tier architectures emphasize separation; SOA emphasizes enterprise integration; microservices emphasize independently deployable business capabilities; event-driven architecture emphasizes temporal decoupling and scalable reaction; serverless emphasizes managed execution; federation preserves autonomy across domains; service meshes govern service communication; and reference architectures provide adaptable blueprints.

No model is universally superior. Architectural evaluation requires quality-attribute scenarios, identification of trade-offs, and attention to temporal, spatial, semantic, and operational coupling. Domain-driven design helps establish meaningful bounded contexts and ownership boundaries. Architecture decision records preserve rationale, alternatives, assumptions, consequences, and conditions for review. In cloud and edge environments, successful architecture depends as much on operations, security, governance, and lifecycle management as on component structure.

Key Terms

Architectural style: A recurring organization of components and relationships in a system.

Architectural pattern: A reusable solution to a recurring design problem in a defined context.

Reference architecture: A generalized blueprint for systems within a particular domain or class.

Layered architecture: A logical organization into levels with defined responsibilities and dependencies.

Multi-tier architecture: A deployment organization that separates system functions across physical or logical tiers.

Service-oriented architecture: An architecture organized around interoperable, relatively autonomous services.

Microservices: Independently deployable services aligned with cohesive business capabilities.

Event-driven architecture: An architecture in which components communicate through events and reactions.

Serverless: A managed execution model in which infrastructure operation is largely delegated to a platform.

Federated architecture: A structure coordinating independently governed domains or platforms.

Service mesh: An infrastructure layer managing service-to-service communication and policy.

Quality attribute: A non-functional property such as latency, availability, security, or modifiability.

Quality-attribute scenario: A measurable description of a stimulus, context, response, and response criterion.

Bounded context: A domain boundary within which terms, models, and rules have consistent meaning.

Domain-driven design: An approach that aligns software structure with domain concepts and business capabilities.

Temporal coupling: Dependence on components being available at the same time.

Architecture decision record: A durable document explaining a significant architectural choice and its consequences.

Eventual consistency: A consistency model in which replicas converge after updates propagate.

Anti-corruption layer: A boundary that prevents one domain model from being polluted by another.

Distributed monolith: A technically distributed system whose components remain strongly coupled in operation or release.

Review Questions

Short Answer Questions

1. Distinguish an architectural style from an architectural pattern.

2. Why is a quality-attribute scenario more useful than the statement “the system must be reliable”?

3. What is a bounded context in domain-driven design?

4. Identify two operational challenges introduced by edge computing.

5. What information should an architecture decision record preserve?

Long Answer Questions

1. Compare layered, service-oriented, and microservices architectures in relation to coupling, deployment, governance, and organizational structure.

2. Explain how event-driven architecture supports disconnected or intermittently connected edge environments, including its consistency challenges.

3. Discuss the benefits and limitations of serverless architecture for cloud and edge workloads.

4. Explain how quality-attribute scenarios and trade-off analysis support defensible architectural decisions.

5. Critically evaluate the role of reference architectures in federated cloud and edge environments.

Analytical / Application Questions

1. Design a quality-attribute scenario and recommend an architectural model for an emergency-response system whose local decisions must continue during a network outage.

2. A proposed microservices system has twelve services sharing one database and requiring coordinated releases. Diagnose the architectural problem and propose a migration approach.

3. Using the cold-chain case, identify three ADRs that should be created and explain the alternatives and consequences that each should document.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a layered architecture from a multi-tier architecture?

A. Layered architecture concerns logical responsibilities, while multi-tier architecture emphasizes deployment separation.

B. Layered architecture requires containers, while multi-tier architecture requires virtual machines.

C. Layered architecture is event-driven, while multi-tier architecture is always synchronous.

D. Layered architecture is used only at the edge, while multi-tier architecture is used only in the cloud.

Correct Answer: A. Layered architecture concerns logical responsibilities, while multi-tier architecture emphasizes deployment separation.

Question 2

A system continues making local control decisions during network disconnection and synchronizes records after reconnection. Which architectural concern is most directly demonstrated?

A. Compile-time polymorphism

B. Edge autonomy and eventual synchronization

C. Centralized transaction locking

D. User-interface abstraction

Correct Answer: B. Edge autonomy and eventual synchronization

Question 3

Which condition most strongly indicates a distributed monolith rather than effective microservices?

A. Services have independently owned data and deployment pipelines.

B. Services communicate through well-defined asynchronous events.

C. Services require coordinated releases and depend on long synchronous call chains.

D. Services are aligned with bounded contexts.

Correct Answer: C. Services require coordinated releases and depend on long synchronous call chains.

Question 4

What is the primary purpose of a bounded context in domain-driven design?

A. To ensure every department uses one universal data model

B. To define a boundary within which domain terms and rules have consistent meaning

C. To eliminate the need for integration testing

D. To determine the physical location of every database

Correct Answer: B. To define a boundary within which domain terms and rules have consistent meaning

Question 5

Which item is NOT one of the standard elements of a quality-attribute scenario?

A. Stimulus

B. Environment

C. Response measure

D. Programming language preference

Correct Answer: D. Programming language preference

Question 6

Why might a service mesh be inappropriate for a highly constrained edge node?

A. It cannot support authentication.

B. It may add resource and operational overhead disproportionate to the node’s capacity.

C. It prevents all forms of asynchronous communication.

D. It requires that services use a single database.

Correct Answer: B. It may add resource and operational overhead disproportionate to the node’s capacity.

Question 7

Which statement correctly distinguishes an event from a command?

A. An event requests a specific recipient to perform an action, while a command records a past fact.

B. An event records that something happened, while a command requests an action.

C. Events are always synchronous, while commands are always asynchronous.

D. Events cannot be stored or replayed.

Correct Answer: B. An event records that something happened, while a command requests an action.

Question 8

Which decision is most appropriately documented in an architecture decision record?

A. The variable name used inside a private function

B. The decision to use local event buffering at edge gateways

C. The formatting of a developer’s personal editor

D. The color of an internal dashboard icon

Correct Answer: B. The decision to use local event buffering at edge gateways

Question 9

In the illustrative cold-chain case, why was telemetry separated from shipment management?

A. To ensure both contexts used identical models

B. To eliminate the need for audit records

C. To establish clearer ownership and allow each domain model to evolve independently

D. To prevent any event from being consumed by more than one service

Correct Answer: C. To establish clearer ownership and allow each domain model to evolve independently

Question 10

Which is the most appropriate response to a trade-off between edge processing and centralized processing?

A. Always move all processing to the edge.

B. Always move all processing to the central cloud.

C. Evaluate latency, resilience, privacy, cost, governance, and operational capability together.

D. Choose the architecture with the greatest number of services.

Correct Answer: C. Evaluate latency, resilience, privacy, cost, governance, and operational capability together.