Cloud Architecture Principles and Distributed Systems

Introduction and Context

Cloud computing is not simply the relocation of servers to a remote data centre. It is an architectural approach in which computing resources, data, software services and operational capabilities are delivered through programmable, shared and elastic infrastructure. Cloud applications must therefore be designed for changing demand, partial failure, geographic distribution, automation and continuously evolving operational conditions.

Distributed systems provide the conceptual and technical foundation of cloud computing. A distributed system consists of independent computing entities that communicate through a network but cooperate to provide a unified service. Unlike a single computer, a distributed system must address network delay, message loss, inconsistent views of data, concurrent updates, machine failure and security boundaries.

Cloud architecture principles are consequently concerned with both structure and behaviour. Structure describes components, interfaces, deployment zones and dependencies. Behaviour describes how the system responds to increasing demand, failure, recovery, data conflicts and operational change. A successful design balances quality attributes rather than maximising one attribute in isolation. For example, stronger consistency may increase latency, while extensive replication may improve availability but increase cost and coordination complexity.

Learning Objectives

After completing this chapter, students should be able to:

1. Explain scalability, elasticity, loose coupling and statelessness in cloud systems.
2. Select appropriate caching, partitioning and replication strategies.
3. Compare strong, eventual and causal consistency models.
4. Design systems that tolerate component, network and regional failures.
5. Apply architectural frameworks and quality-attribute reasoning to cloud decisions.
6. Evaluate trade-offs among performance, reliability, security, cost and maintainability.
7. Analyse a realistic cloud architecture and justify its design choices.

1. Distributed-System Foundations

1.1 Characteristics of distributed systems

A distributed system has several defining characteristics:

• Concurrency: multiple operations execute at the same time.
• Independent failure: one component can fail while others remain operational.
• Network dependence: communication occurs through links with non-zero and variable latency.
• Partial knowledge: no component has a perfectly current view of the whole system.
• Coordination: components must agree on ownership, ordering, state or responsibility.
• Heterogeneity: machines, operating systems, networks and services may differ.

The network is especially important. In a local function call, failure and timing are usually predictable. In a distributed call, the receiver may be unavailable, the response may be delayed, or the response may be lost even though the operation succeeded. A timeout therefore does not prove that an operation did not occur. This is why payment, provisioning and message-processing operations should be designed to be idempotent.

An operation is idempotent when repeating it produces the same intended result as performing it once. Setting a resource state to “disabled” is naturally idempotent; “increment balance by 10” is not unless it is protected by a unique transaction identifier or equivalent mechanism.

1.2 Fallacies of distributed computing

Designers frequently make assumptions known as the fallacies of distributed computing: the network is reliable, latency is zero, bandwidth is infinite, the network is secure, topology does not change, there is one administrator, transport cost is zero and the network is homogeneous. These assumptions are unsafe in cloud environments. Sound architecture treats network calls as expensive and fallible, authenticates every trust boundary, observes latency and errors, and plans for topology and capacity changes.

1.3 Failure models

A crash failure occurs when a component stops responding. An omission failure occurs when a message is lost or not delivered. A timing failure occurs when a response is outside an acceptable time interval. A Byzantine failure occurs when a component behaves arbitrarily or maliciously, including sending contradictory information. Most enterprise cloud applications are designed primarily for crash, omission and timing failures, while systems with untrusted participants may require Byzantine fault-tolerant protocols.

2. Architectural Quality Attributes

Architecture is a set of significant design decisions and the rationale behind them. These decisions should be evaluated using quality attributes, also called non-functional requirements.

Quality attributes are often in tension. Replication can improve availability but increase storage and synchronisation cost. A cache can reduce latency but create stale data. Microservices can enable independent deployment but introduce network and operational complexity. Architecture therefore requires explicit trade-off analysis.

A useful method is the quality-attribute scenario. It specifies a stimulus, environment, response and measurable response criterion. For example: “When request volume rises from 2,000 to 10,000 requests per second during a sale, the system shall maintain a 95th-percentile response time below 300 milliseconds and shall recover normal capacity within 15 minutes after demand falls.” Such scenarios convert vague requirements into testable architectural objectives.

3. Scalability and Elasticity

3.1 Vertical and horizontal scaling

Vertical scaling increases the capacity of an individual machine by adding CPU, memory or storage performance. It is simple but limited by hardware ceilings and may require downtime. Horizontal scaling adds more instances and distributes work among them. It generally provides better cloud scalability but requires load balancing, coordination and distributed state management.

A system is scalable if it can handle increased workload by adding resources while maintaining acceptable quality. It may scale vertically, horizontally or through a combination of both. A system is elastic if it can provision and release resources in response to workload changes. Scalability is a capability; elasticity is dynamic adaptation.

A basic capacity estimate is:

Here, λ is the incoming request rate in requests per second, μ is the sustainable service rate per instance in requests per second, and N is the minimum number of instances under an idealised model. The ceiling function ensures a whole number of instances. This estimate assumes similar instances, balanced traffic and no coordination overhead. Production designs add headroom for bursts, failures and degradation of performance at high utilisation.

For example, if each instance sustains 250 requests per second and demand is 1,000 requests per second, the ideal minimum is N = ⌈1000/250⌉ = 4. If one instance must be unavailable without exceeding nominal capacity, at least five instances are required, subject to load-balancer and dependency limits.

3.2 Bottlenecks and scaling limits

Adding application instances does not solve a database, network, lock or external API bottleneck. Amdahl’s law expresses the limit imposed by a non-parallelisable fraction:

Here, S(p) is the speedup using p processing units, s is the fraction of work that remains serial, and 1 − s is the parallelisable fraction. The equation assumes fixed workload and ideal scheduling. If 10% of work is serial, even infinitely many processors have a maximum speedup of 10. This illustrates why a central lock, single database writer or sequential workflow can limit a supposedly scalable architecture.

3.3 Autoscaling

Autoscaling policies may use CPU utilisation, request rate, queue depth, latency or business indicators. CPU is useful for compute-heavy services but may be misleading for I/O-bound services. Queue depth is often more directly related to backlog. Effective autoscaling requires:

• minimum and maximum capacity;
• cooldown or stabilisation periods;
• health-aware instance registration;
• protection against oscillation;
• capacity for dependency services;
• load tests and failure tests;
• graceful connection draining during scale-in.

Autoscaling is not a substitute for capacity planning. A service may scale too slowly for a sudden burst, or its database may reach a limit before application instances scale.

4. Loose Coupling and Statelessness

4.1 Loose coupling

Loose coupling minimises assumptions between components. A loosely coupled service depends on a stable contract rather than on another service’s internal database schema, deployment schedule or implementation language. Interfaces should define data formats, authentication, error semantics, versioning and idempotency expectations.

Synchronous HTTP or gRPC calls are appropriate when an immediate response is required. Asynchronous messaging is more suitable when work can be deferred, when producers and consumers scale independently, or when temporary unavailability must be absorbed. Queues also provide a form of load levelling: producers can continue at a controlled rate while consumers process accumulated work.

Loose coupling does not mean eliminating all dependencies. Dependencies should instead be explicit, bounded and observable. Excessive service decomposition can produce a distributed monolith in which one user request requires many tightly coordinated network calls.

4.2 Stateless services

A stateless service does not retain client-specific session state in the memory of one instance between requests. Requests can therefore be routed to any healthy instance. Session information may be held by the client in a secure token, or in a shared durable store such as a session database or cache.

Statelessness improves horizontal scaling and failover, but it does not mean that the overall system has no state. Business state must be stored durably and consistently according to its importance. Tokens must be short-lived where appropriate, protected against replay and prevented from containing sensitive information unnecessarily.

4.3 Resilience patterns

Important resilience patterns include:

• Timeouts: prevent indefinite resource occupation.
• Retries: useful for transient failures, but should use bounded attempts and exponential backoff with jitter.
• Circuit breakers: stop calls to a failing dependency temporarily.
• Bulkheads: isolate resource pools so one failure does not exhaust all capacity.
• Rate limiting: protects services from overload.
• Dead-letter queues: retain messages that repeatedly fail processing.
• Fallbacks: provide a degraded but useful response when possible.
• Idempotency keys: prevent duplicate effects when clients retry.

Retries can amplify an incident. A service receiving 100 failed requests per second from ten clients may receive substantially more load if every caller retries immediately. Retry budgets and jitter are therefore essential.

5. Caching and Performance

A cache stores data closer to its consumer or in a faster medium. Common layers include browser caches, content-delivery networks, application-process caches, distributed key-value caches and database buffer caches.

Caching can reduce latency, backend load and cost. However, it introduces questions of freshness, invalidation, capacity, eviction and privacy. The familiar principle that cache invalidation is difficult reflects the need to define what happens when the source changes while cached copies remain available.

Common strategies are:

• Cache-aside: the application reads the cache, loads from the source on a miss, then populates the cache.
• Read-through: the cache itself loads missing data from the source.
• Write-through: writes update the cache and source together through a controlled mechanism.
• Write-behind: writes reach the cache first and are propagated later; this improves write latency but risks data loss or reordering.
• Refresh-ahead: frequently used entries are refreshed before expiry.

A time-to-live (TTL) defines how long an entry may remain eligible for use. A shorter TTL improves freshness but increases source load. A longer TTL improves hit ratio but increases staleness risk. Sensitive data requires additional controls: tenant isolation, encryption, access-aware keys and careful eviction.

A cache hit ratio is:

where h is the number of cache hits and m is the number of cache misses during an observation interval. If 900 requests are hits and 100 are misses, H = 900/(900+100) = 0.90, or 90%. Hit ratio alone is insufficient: a small number of misses may be expensive, and a high hit ratio may still serve unacceptable stale data.

6. Partitioning and Replication

6.1 Partitioning

Partitioning, or sharding, divides data or workload across multiple nodes. A partition key should distribute load evenly, support common access patterns and avoid concentrating traffic on one partition. Poor keys create hot partitions. For example, using a timestamp as a key can direct all current writes to one shard.

Strategies include:

• Range partitioning: records are divided into ordered ranges; useful for range queries but vulnerable to uneven growth.
• Hash partitioning: a hash of the key determines placement; usually distributes writes well but makes range queries harder.
• Directory partitioning: a lookup table maps tenants or entities to partitions; flexible but introduces directory dependence.
• Geographic partitioning: data is placed near users or within regulatory boundaries; it can reduce latency but complicates global consistency.

Partitioning often requires routing, rebalancing, cross-partition queries and transaction management. These costs should be included in design evaluation.

6.2 Replication

Replication maintains multiple copies of data or service instances. It can improve availability, read capacity and disaster recovery. Replicas may be synchronous or asynchronous. Synchronous replication generally provides stronger write durability or consistency but increases write latency and depends on replica availability. Asynchronous replication reduces write latency but creates a replication lag window.

Replication topologies include primary–replica, multi-primary and leaderless designs. Primary–replica systems simplify ordering but can create a failover decision. Multi-primary systems support regional writes but require conflict resolution. Leaderless designs can remain available under some failures but commonly use quorum-style reasoning and application-level conflict handling.

7. Consistency Models and Coordination

Consistency describes what values a read is permitted to return after concurrent or prior writes. It is distinct from durability, which concerns whether acknowledged data survives failure, and availability, which concerns whether requests receive a response.

• Strong consistency: a read reflects the most recent completed write according to a defined ordering.
• Eventual consistency: if updates stop and communication continues, replicas converge eventually; intermediate reads may be stale.
• Causal consistency: causally related operations are observed in an order that preserves their cause-and-effect relationship, while concurrent operations may be seen in different orders.
• Read-your-writes consistency: a client sees its own successful updates in subsequent reads.
• Monotonic reads: once a client has observed a value, later reads do not move backward to an older value.

The CAP theorem states that when a network partition occurs, a distributed data system cannot simultaneously guarantee both strong consistency and availability for all requests. The theorem concerns a partition-tolerant distributed system and should not be simplified into “choose only two of three” under normal operation. During a partition, designers choose whether some operations reject or delay requests to preserve consistency, or accept operations that may temporarily diverge to preserve availability.

The PACELC perspective adds that, when there is no partition, a system commonly trades latency against consistency. This is especially relevant in geo-distributed systems: synchronous cross-region coordination may provide stronger guarantees but increase response time.

Transactions across partitions are expensive because they require coordination. Two-phase commit can provide atomic commitment under stated assumptions, but it may block while a coordinator is unavailable and increases latency. Alternatives include sagas, in which a business transaction is divided into local transactions with compensating actions. Sagas are appropriate when temporary intermediate states are acceptable and compensation is possible; they are not equivalent to atomic rollback.

8. Fault-Tolerant Design

Fault tolerance is the ability to continue delivering an acceptable service despite specified faults. It is not the claim that failure is impossible.

8.1 Redundancy and failure domains

Redundancy should cross meaningful failure domains: processes, virtual machines, availability zones, regions, power systems or providers. Three copies on one host do not protect against host failure. Likewise, three zones may not protect against a regional disaster.

A simple independent-availability model for parallel components is:

where A_i is the availability of component i, and the product applies to components arranged so that any one can serve the request. The independence assumption is often unrealistic because common dependencies, correlated outages and configuration errors affect multiple components simultaneously.

For serial dependencies, where every component must work, the idealised availability is:

These equations are planning approximations, not guarantees. They demonstrate why adding dependencies can reduce availability and why correlated failure must be analysed explicitly.

8.2 Recovery objectives

The Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time. An RPO of 15 minutes means that, after a disaster, the organisation accepts losing up to 15 minutes of committed data under the recovery design. The Recovery Time Objective (RTO) is the maximum acceptable time to restore service. Backup frequency, replication mode, recovery automation and testing should be selected to meet these objectives.

A backup is not a recovery strategy until restoration has been tested. Professional practice includes immutable or protected backups, geographic separation, encryption, access control, documented runbooks and regular recovery exercises.

8.3 Observability

Observability enables operators to infer internal system behaviour from outputs. It combines metrics, logs and distributed traces, supported by correlation identifiers and meaningful service-level indicators. Useful measurements include error rate, latency percentiles, saturation, queue age, cache hit ratio, replication lag and failed-over request count.

Average latency can hide severe tail behaviour. The 95th percentile means that 95% of observations are at or below that value, while 5% are higher. Tail latency is particularly important when a request fans out to many services, because the slowest dependency can determine the overall response time.

9. Architectural Evaluation and Trade-offs

The ISO/IEC/IEEE 42010 perspective treats architecture as involving stakeholders, concerns, viewpoints and views. In practice, architects should identify stakeholders such as users, developers, security officers, operations teams, regulators and finance managers. Each stakeholder evaluates different concerns.

The C4 model provides a practical communication structure: system context, containers, components and code. It does not replace detailed deployment, data-flow or threat diagrams, but it helps maintain a consistent level of abstraction.

A useful evaluation sequence is:

1. Define business capabilities and quality-attribute scenarios.
2. Identify trust boundaries, data classifications and regulatory constraints.
3. Map services, data stores, queues, caches and external dependencies.
4. Identify failure domains and single points of failure.
5. Estimate capacity, latency, storage growth and cost.
6. Compare alternatives using weighted criteria.
7. Validate through prototypes, load tests, security tests and recovery exercises.
8. Record decisions and revisit them when assumptions change.

A weighted decision matrix can compare alternatives, but numerical scores do not create objective truth. Weights should be agreed with stakeholders, evidence should support scores, and sensitivity analysis should determine whether a small change in assumptions reverses the decision.

10. Security, Governance and Ethical Considerations

Cloud architecture must implement defence in depth. Important controls include identity-based access, least privilege, short-lived credentials, encryption in transit and at rest, key rotation, network segmentation, secure software supply chains, vulnerability management and centralised audit logging.

Multi-tenant systems require isolation of data, compute, caches, logs and administrative privileges. A cache key that omits tenant identity can cause cross-tenant disclosure. Logs should avoid unnecessary personal or secret data, and retention should align with legal, operational and privacy requirements.

Data location and replication may be constrained by data-protection law, contractual commitments and sector regulation. Architectural decisions should document where data is stored, who can administer it, how deletion requests propagate to replicas and backups, and how evidence is preserved for audit.

Automation and AI-based operations introduce additional concerns. An automated scaling or remediation policy may amplify an incident if its signals are wrong. AI systems may process sensitive data, produce unjustified decisions or obscure accountability. Human approval, policy limits, explainable alerts and rollback mechanisms are appropriate for high-impact actions.

11. Illustrative Case: A Multi-Region Online Learning Platform

Background

Consider an illustrative postgraduate learning platform serving students in several regions. It provides course content, assessments, discussion forums and payment for optional certifications. Demand peaks during examination periods and enrolment deadlines.

Problem

The initial system uses a single application server, a relational database and local session memory. During peaks, response time becomes unacceptable. A server failure logs users out, and a database outage prevents access to course content. The organisation requires an RTO of 30 minutes and an RPO of 5 minutes for assessment submissions. Student profile data is subject to privacy and regional-storage requirements.

Analysis

Course content is read-heavy and changes infrequently, whereas assessment submissions are transactional and must not be silently lost. Discussion posts can tolerate short periods of eventual consistency, but payment status requires strong transactional guarantees. The architecture therefore should not apply one consistency model to every data type.

The single server is a failure point. Session state prevents simple horizontal scaling. The database is both a capacity bottleneck and a regional dependency. A content-delivery network can serve static course assets, while dynamic assessment operations require authenticated services and durable storage.

Approach and solution

The redesigned architecture uses:

• stateless application instances behind a load balancer;
• an identity service issuing short-lived access tokens;
• a managed relational store for enrolment, payment and assessment records;
• read replicas for suitable read workloads;
• a distributed cache for course metadata and non-sensitive session-related data;
• object storage and a content-delivery network for course media;
• a queue for email, certificate generation and analytics;
• idempotency keys for assessment submission and payment callbacks;
• regional deployment with data residency rules;
• encrypted, immutable backups and tested restoration;
• metrics, logs and traces correlated by request identifier.

Assessment submissions use a transactional write and synchronous durability appropriate to the stated RPO. Discussion posts use asynchronous replication and display a clear “processing” state when necessary. Cache entries for course metadata have a controlled TTL and are invalidated when instructors publish a new version. A circuit breaker prevents a failing recommendation service from affecting course access.

Outcome

The architecture supports horizontal application scaling and isolates static-content traffic from transactional traffic. A zone failure can be handled by routing requests to healthy zones. Regional recovery is slower but is tested against the 30-minute RTO. The design costs more than the original system, but the additional cost is justified by reduced outage risk, improved peak performance and regulatory compliance.

Learning points

1. Statelessness improves scaling only when durable state is designed separately.
2. Different data domains may require different consistency models.
3. Queues decouple work but require monitoring, retries and duplicate handling.
4. Replication does not remove the need for backup and recovery testing.
5. Security and data residency are architectural constraints, not operational afterthoughts.
6. Quality attributes must be translated into measurable scenarios before technology selection.

Challenges and Limitations

Cloud architecture cannot eliminate fundamental distributed-system problems. Network partitions, correlated failures, clock uncertainty and conflicting updates remain possible. Managed services reduce operational effort but can introduce provider dependence, opaque limits and changing pricing. Microservices may improve organisational autonomy while increasing deployment, testing and observability demands.

Architectural models are also simplifications. Availability calculations often assume independence; capacity calculations may ignore nonlinear queueing effects; consistency descriptions may differ between vendors; and benchmark results may not represent production workloads. Therefore, claims should be validated through representative experiments, fault injection, security assessment and operational rehearsal.

Best-Practice Checklist

• Define measurable quality-attribute scenarios.
• Prefer horizontal scaling for suitable stateless workloads.
• Keep synchronous call chains short and bounded.
• Use timeouts, bounded retries and jitter.
• Make externally retried operations idempotent.
• Choose partition keys based on access patterns and load distribution.
• Document consistency requirements per data domain.
• Replicate across genuine failure domains.
• Monitor tail latency, saturation, lag and queue age.
• Test backup restoration, failover and regional recovery.
• Protect tenant boundaries in data, caches and logs.
• Record architecture decisions, assumptions and trade-offs.
• Re-evaluate designs as workload, regulation and business priorities change.

Chapter Summary

Cloud architecture is the disciplined design of distributed services, data and infrastructure under changing demand and partial failure. Scalability concerns the ability to handle more workload; elasticity concerns automatic resource adaptation. Loose coupling reduces dependency propagation, while stateless services enable flexible routing and horizontal scale.

Caching improves performance but introduces freshness and invalidation concerns. Partitioning distributes data and workload but requires careful key selection and routing. Replication improves availability and read capacity while creating synchronisation and conflict-management obligations. Consistency models range from strong to eventual and causal, and should be selected according to business consequences rather than applied uniformly.

Fault-tolerant architecture uses redundancy, failure-domain analysis, timeouts, circuit breakers, queues, idempotency, observability and tested recovery procedures. Architectural evaluation should connect stakeholder concerns to measurable quality scenarios and make trade-offs among performance, reliability, security, cost and maintainability explicit. Security, privacy, governance and data residency must be incorporated into the design from the beginning.

Key Terms

Distributed system: A collection of independent components that cooperate through communication networks to provide a service.

Scalability: The ability to handle increased workload by adding or improving resources.

Elasticity: The ability to add and release resources dynamically as demand changes.

Loose coupling: Design in which components depend on stable contracts rather than internal implementation details.

Statelessness: A service property in which client-specific request state is not retained in one service instance between requests.

Idempotency: The property that repeating an operation produces the same intended result as performing it once.

Cache: A temporary, faster copy of data used to reduce latency or backend load.

Partitioning: Dividing data or workload across multiple nodes or shards.

Replication: Maintaining multiple copies of data or service instances.

Consistency model: Rules defining which values reads may return relative to writes and concurrent operations.

Eventual consistency: A model in which replicas converge if updates cease and communication continues.

Strong consistency: A model in which reads reflect the most recent completed write under a defined ordering.

Availability: The probability or proportion of time that a service is usable when requested.

Reliability: The ability to perform correctly and continuously over a specified period.

Fault domain: A set of components likely to fail together because of a shared dependency.

RPO: Recovery Point Objective; the maximum acceptable amount of data loss measured in time.

RTO: Recovery Time Objective; the maximum acceptable time to restore service.

Circuit breaker: A resilience mechanism that temporarily stops calls to an unhealthy dependency.

Observability: The ability to infer internal system state from outputs such as metrics, logs and traces.

Quality-attribute scenario: A measurable statement describing a stimulus, environment, response and response criterion.

Review Questions

Short Answer Questions

1. Distinguish scalability from elasticity.
2. Why can a timeout not prove that a distributed operation failed?
3. What problem does partitioning solve, and what new problems can it introduce?
4. Explain the difference between RPO and RTO.
5. Why is idempotency important when retries are used?

Long Answer Questions

1. Explain how loose coupling, asynchronous messaging and statelessness support cloud scalability. Discuss their limitations.
2. Compare cache-aside, write-through and write-behind caching, including appropriate use cases and risks.
3. Explain strong, eventual and causal consistency and relate each to a suitable business scenario.
4. Discuss how redundancy, failure domains, observability and recovery testing contribute to fault tolerance.
5. Describe a systematic method for evaluating a cloud architecture using quality-attribute scenarios and trade-off analysis.

Analytical / Application Questions

1. A service receives 2,400 requests per second, and one instance sustains 300 requests per second. Calculate the ideal minimum instance count. Then explain why a production architecture may require additional instances.
2. Design a data architecture for an international retail platform in which product browsing may be eventually consistent but payment completion must be strongly consistent. Justify partitioning, replication and caching decisions.
3. Analyse a microservices system in which every request synchronously calls six downstream services. Identify likely failure and performance risks and propose a more resilient alternative.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes elasticity from scalability?

A. Elasticity concerns dynamic resource adjustment, whereas scalability concerns handling increased workload.

B. Elasticity means strong consistency, whereas scalability means eventual consistency.

C. Elasticity applies only to storage, whereas scalability applies only to networks.

D. Elasticity eliminates the need for capacity planning.

Correct Answer: A. Elasticity concerns dynamic resource adjustment, whereas scalability concerns handling increased workload.

Question 2

A service instance sustains 250 requests per second and demand is 1,000 requests per second. What is the ideal minimum number of instances under the simple capacity model?

A. 2

B. 3

C. 4

D. 5

Correct Answer: C. 4

Question 3

Which operation is naturally idempotent?

A. Increment an account balance by 10 units.

B. Append a new message without a unique identifier.

C. Set a resource state to disabled.

D. Charge a payment card.

Correct Answer: C. Set a resource state to disabled.

Question 4

What is a primary risk of using a very long cache TTL?

A. Excessive source-database writes caused by every read.

B. Increased probability of serving stale data.

C. Guaranteed loss of encryption keys.

D. Elimination of horizontal scalability.

Correct Answer: B. Increased probability of serving stale data.

Question 5

Which partitioning strategy generally distributes point writes well but makes range queries more difficult?

A. Hash partitioning

B. Range partitioning

C. Manual backup partitioning

D. Serial partitioning

Correct Answer: A. Hash partitioning

Question 6

Under the CAP perspective, what is the central trade-off during a network partition?

A. Choosing between encryption and compression

B. Choosing between consistency and availability

C. Choosing between caching and partitioning

D. Choosing between logging and tracing

Correct Answer: B. Choosing between consistency and availability

Question 7

What is the main purpose of a circuit breaker?

A. To encrypt traffic between services

B. To increase database storage capacity

C. To stop repeated calls to a failing dependency temporarily

D. To guarantee zero data loss

Correct Answer: C. To stop repeated calls to a failing dependency temporarily

Question 8

If 900 cache requests are hits and 100 are misses, what is the cache hit ratio?

A. 9%

B. 10%

C. 90%

D. 99%

Correct Answer: C. 90%

Question 9

What does an RPO of five minutes specify?

A. The maximum acceptable service restoration time is five minutes.

B. The maximum acceptable data loss is approximately five minutes of data.

C. Every request must complete within five minutes.

D. Backups must be retained for five minutes.

Correct Answer: B. The maximum acceptable data loss is approximately five minutes of data.

Question 10

Which statement about availability calculations is most accurate?

A. They always predict production availability exactly.

B. They assume all failures are correlated.

C. They can be useful planning approximations but depend on assumptions such as independence.

D. They apply only to single-server systems.

Correct Answer: C. They can be useful planning approximations but depend on assumptions such as independence.