10. Distributed, Parallel and Cloud Databases

Introduction and Context

Traditional database systems were originally designed for a relatively self-contained computer with a central processor, storage subsystem, and controlled user population. Modern data-intensive organizations operate under very different conditions. Applications serve users across regions, generate high-volume streams, require continuous availability, and must scale without excessive capital investment. Analytical workloads may scan terabytes of data, while transactional systems must process many small operations with low latency. No single machine is always able to provide the required capacity, performance, resilience, and geographical reach.

Distributed, parallel, and cloud databases address these demands through different but related strategies. A distributed database stores or processes data across multiple networked computers while presenting some degree of unified access. A parallel database divides computation among processors or nodes to reduce execution time. A cloud database uses virtualized or managed infrastructure, often with elastic capacity and consumption-based pricing. These approaches create opportunities, but they also introduce network latency, partial failures, consistency problems, operational complexity, and governance concerns.

The central design question is not simply whether data should be distributed. It is how data placement, replication, transaction processing, computation, availability, security, and cost should be coordinated to satisfy business requirements. This chapter develops that decision-making perspective.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the architecture and objectives of distributed, parallel, and cloud databases.

2. Distinguish fragmentation, replication, partitioning, and sharding.

3. Evaluate consistency, availability, partition tolerance, and transaction guarantees.

4. Describe distributed transactions, two-phase commit, consensus, and quorum methods.

5. Compare shared-memory, shared-disk, and shared-nothing parallel database architectures.

6. Assess managed cloud databases, serverless databases, and cloud migration strategies.

7. Identify operational, security, governance, cost, and performance risks.

8. Select an appropriate architecture for realistic organizational scenarios.

1. The Distributed Database Problem

A distributed database is a logically integrated database whose data or processing is located at multiple networked sites. Distribution may be transparent to users: an application can issue a query without knowing which node stores the required records. Transparency is desirable, but it is never absolute. Network communication is slower and less reliable than local memory access, and a distributed system can fail in many partial ways. One node may be unavailable while others continue operating; messages may be delayed, duplicated, or lost; and two sites may temporarily be unable to communicate.

A distributed database management system therefore has to coordinate two dimensions of correctness. First, it must preserve database semantics such as integrity constraints and transaction isolation. Second, it must manage placement and communication across sites. The principal objectives are locality of access, improved performance, fault tolerance, scalability, and organizational autonomy. These objectives may conflict. Replication can improve read availability but increase update coordination. Strong consistency can simplify application reasoning but increase latency. Geographic distribution can reduce user latency but make transactions more difficult.

Important terminology

A node is a computer or database instance participating in the system. A site is a physical or logical location containing one or more nodes. A fragment is a portion of a relation or dataset. Partitioning is the division of data into partitions, usually according to a key. Sharding is a form of horizontal partitioning in which shards are distributed across independent database servers. A replica is a copy of data maintained for availability, performance, or disaster recovery. A coordinator manages a distributed operation, while participants execute its parts.

A shared-nothing architecture gives each node its own processor, memory, and storage. Nodes communicate over a network and generally own particular partitions. Data locality means that computation is performed near the data, reducing network transfer. Skew occurs when data or work is unevenly distributed, causing some nodes to become bottlenecks. Hotspotting is a related problem in which a frequently accessed key or partition receives disproportionate traffic.

2. Fragmentation, Replication, and Sharding

Fragmentation and partitioning

Fragmentation divides a relation into smaller logical units. Horizontal fragmentation divides rows, for example by region, customer segment, or time period. Vertical fragmentation divides columns, usually retaining the primary key in each fragment so that the original relation can be reconstructed. Hybrid fragmentation combines both methods.

A sound fragmentation scheme should satisfy three classical properties. Completeness requires that every original data item appears in at least one fragment. Reconstruction requires that the original relation can be rebuilt using union for horizontal fragments or join for vertical fragments. Disjointness, where appropriate, prevents unnecessary duplication of data; it is normally expected for horizontal fragments but may not apply to vertical fragmentation because key columns are repeated.

Fragmentation improves locality and can reduce query cost. However, a poor scheme creates excessive distributed joins, uneven storage, or difficult administration. A time-partitioned transaction table, for example, supports efficient archival and recent-data queries. A customer table fragmented by region may reduce latency for regional applications, but a global customer analysis may require communication across all sites.

Replication strategies

Replication may be full, where each site stores the entire dataset, or partial, where only selected tables or fragments are copied. It may also be synchronous or asynchronous. Synchronous replication confirms an update only after required replicas acknowledge it; this supports strong coordination but increases write latency. Asynchronous replication allows the primary operation to complete before all replicas receive the update; it improves responsiveness but permits temporary stale reads and possible data loss during failure.

Common arrangements include primary-replica replication, multi-primary replication, and quorum-based replication. In primary-replica systems, one node accepts writes and replicas serve reads or failover. Multi-primary systems accept writes at multiple locations but must resolve conflicts. In quorum systems, an operation contacts a selected number of replicas. If a write quorum and read quorum overlap, a read can observe at least one replica containing the latest acknowledged write, subject to the system's precise protocol and failure model.

Replication is not a substitute for backup. Replicas often reproduce accidental deletion, corruption, or malicious changes. Backups provide historical recovery points and should be tested through restoration exercises.

Sharding and shard-key design

Sharding distributes horizontal partitions across nodes. The shard key is therefore a major architectural decision. Range sharding places values in ordered intervals and supports range queries, but adjacent new values may create a hotspot. Hash sharding spreads values more evenly, but range queries become expensive because many shards may need to be consulted. Composite or directory-based schemes can balance these effects.

A useful shard key has high cardinality, distributes load evenly, supports important access patterns, and does not change frequently. Designers should also consider tenant isolation, regulatory location, transaction boundaries, and future growth. Resharding is operationally difficult because data must be moved while applications continue to operate. Consistent hashing and virtual shards can reduce movement during node changes, but they do not eliminate migration cost or application-level coordination.

3. Consistency, Availability, and Distributed Transactions

The CAP perspective

The CAP theorem concerns a system that experiences a network partition. It states that a distributed data service cannot simultaneously guarantee strong consistency, availability for every request, and partition tolerance under that condition. Partition tolerance is generally necessary in a networked system; consequently, designers must decide how the service behaves during partition: reject or delay some operations to preserve consistency, or continue serving operations with weaker or potentially divergent results.

CAP is not a simple permanent label such as “this database is CP” or “that database is AP.” Real systems may offer different consistency modes for different operations, and normal operation may provide both high availability and strong consistency when no partition exists. The theorem is a guide to failure-time trade-offs, not a complete performance model.

Consistency also has several meanings. Linearizability makes each operation appear to occur instantaneously at a point between invocation and response. Sequential consistency preserves a single order consistent with each client's program order but may not preserve real-time ordering. Eventual consistency guarantees that replicas converge if updates stop, without requiring every read to see the latest write immediately. Session guarantees such as read-your-writes can provide useful application behavior without global linearizability.

Distributed transactions

A distributed transaction updates data at multiple nodes as one logical unit. It must address atomicity, consistency, isolation, and durability across sites. The classic two-phase commit (2PC) protocol contains a prepare phase and a commit phase. The coordinator asks participants whether they can commit. If all vote positively, the coordinator records and announces commit; otherwise it announces abort.

Two-phase commit provides atomic commitment under its assumptions, but it is a blocking protocol. If the coordinator fails after participants have prepared, participants may retain locks or uncertain state while waiting for a decision. Network delays, log recovery, and cross-region communication can therefore reduce availability and performance. Three-phase commit can reduce some blocking conditions under stronger assumptions, but it is not a universal solution to distributed failure.

Modern systems often avoid broad distributed transactions by designing bounded transaction scopes, co-locating related records, using idempotent operations, or applying the saga pattern. A saga decomposes a business transaction into local transactions, each associated with a compensating action. For example, an order workflow may reserve inventory, authorize payment, and arrange shipment; if shipment fails, earlier actions are reversed or marked for human resolution. Sagas improve availability and scalability but do not provide the same atomicity as a single ACID transaction.

Consensus and quorum

Consensus protocols enable nodes to agree on a value or sequence of commands despite specified failures. Leader-based protocols such as Raft use replicated logs, leader election, terms, and majority agreement. A committed log entry is durable when the required quorum has acknowledged it. Consensus is useful for metadata, leader election, configuration, and strongly consistent replicated state.

Consensus does not make a system automatically fast or globally available. A majority quorum may be unavailable if too many nodes fail or if a region is isolated. Cross-region consensus also incurs network latency. Engineers must specify the failure model, quorum placement, recovery process, and behavior when a leader is unreachable.

4. Parallel Database Processing

Distributed databases distribute data and control across sites; parallel databases primarily distribute computation to reduce elapsed time or increase throughput. The distinction is practical rather than absolute, because modern systems often use parallel processing within and across cloud nodes.

A shared-memory architecture gives processors access to common memory and often common storage. It offers simple communication but has scalability limits caused by memory contention and hardware size. A shared-disk architecture gives nodes independent memory but access to common storage. It can support flexible workload movement, though coordination and storage contention may become significant. A shared-nothing architecture gives each node private memory and storage. It scales effectively by adding nodes, but performance depends heavily on partitioning and data movement.

Parallel query execution decomposes a relational operation into tasks. A scan can be divided among partitions; selections and projections can be performed locally; aggregations can use local partial results followed by a final merge. Joins may be implemented through broadcast, repartition, or colocated strategies. In a broadcast join, a small relation is copied to all workers. In a repartition join, both relations are redistributed according to the join key. A colocated join avoids redistribution when matching partitions already reside together.

The potential speedup of parallel execution is limited by serial work, coordination, communication, and imbalance. Amdahl's law expresses this intuition: if fraction s of a workload is serial, the maximum speedup with p processors approaches 1/(s + (1-s)/p). In database systems, skew can make one worker determine the completion time even when many others are idle. Query optimizers therefore estimate cardinalities, select join orders, choose data movement strategies, and use statistics to reduce unnecessary work.

Massively parallel processing systems commonly separate storage and compute conceptually. Columnar storage, compression, vectorized execution, predicate pushdown, and materialized views are especially effective for analytical workloads. These techniques should not be assumed to improve small, highly concurrent OLTP transactions, which often require indexed point access and strict transaction semantics.

5. Cloud Database Architectures

Cloud databases range from infrastructure that an organization administers itself to fully managed services operated by a provider. In an infrastructure-as-a-service model, the customer controls virtual machines, database software, patching, and much of the architecture. A managed database service automates tasks such as provisioning, backups, monitoring, patching, failover, and read replicas, although the customer remains responsible for schemas, access policies, data quality, and workload design. A serverless database abstracts capacity management further and may scale automatically or charge according to requests, storage, or execution resources.

“Serverless” does not mean that servers do not exist. It means that the customer does not directly manage the underlying server fleet. Serverless designs are attractive for irregular workloads and rapid development, but cold starts, concurrency limits, unpredictable cost, vendor-specific interfaces, and connection management must be considered. A database proxy or connection pool may be needed because creating large numbers of direct connections can overwhelm a database.

Cloud databases may separate storage and compute, support automated snapshots, use geographically distributed replicas, and expose elastic scaling. Elasticity is the ability to acquire and release resources as workload changes. Vertical scaling increases the size of a node; horizontal scaling adds nodes or partitions. Autoscaling policies should include stabilization periods, maximum limits, and cost controls. Scaling capacity does not automatically solve contention caused by a poor query, hot key, lock conflict, or inefficient schema.

A useful comparison considers more than feature lists. Managed relational services usually provide familiar SQL and ACID transactions, but may constrain extensions or topology. Cloud-native distributed SQL systems offer horizontal scaling and strong consistency across nodes, often at greater latency and cost. Key-value or document services provide flexible schemas and high throughput for access patterns designed around keys, but complex joins and ad hoc relational analysis may be limited. Cloud data warehouses are optimized for analytical scans and aggregation rather than transaction processing. The appropriate choice follows workload requirements, not marketing categories.

6. Cloud Migration and Operating Models

Migration begins with workload discovery rather than product selection. Organizations should inventory data stores, dependencies, data volumes, peak and average load, recovery objectives, compliance obligations, integration interfaces, and licensing constraints. Two essential recovery measures are the recovery point objective (RPO), the maximum acceptable amount of data loss measured in time, and the recovery time objective (RTO), the maximum acceptable time to restore service.

Common migration strategies are often summarized as:

• Rehost: move the existing system with minimal code change. This is rapid but may preserve inefficiencies.
• Replatform: adopt managed storage, replicas, or compatible services while making limited changes.
• Refactor or rearchitect: redesign schemas, services, and workflows to exploit cloud elasticity and distribution.
• Repurchase: replace the existing system with a cloud service or packaged product.
• Retain: keep workloads where they are when migration value is low or constraints are significant.
• Retire: remove systems that are obsolete or redundant.

A controlled migration normally includes assessment, target architecture, data transfer, validation, rehearsal, cutover, and rollback. Techniques such as change-data capture can keep a target synchronized during a transition. Validation should compare row counts, checksums, business totals, referential integrity, query results, latency, and security controls. A successful technical copy is not sufficient if applications interpret timestamps, nulls, character sets, or transaction boundaries differently.

Hybrid and multi-cloud approaches may improve resilience or negotiation power, but they create duplicated skills, networking complexity, inconsistent observability, and difficult data movement. Egress charges and proprietary features can create vendor lock-in. Portability should be evaluated realistically: SQL syntax may be portable while operational behavior, identity integration, replication, and performance are not.

7. Professional and Governance Considerations

Distributed and cloud databases expand the security boundary. Encryption in transit and at rest, centralized identity, least privilege, short-lived credentials, network segmentation, secret management, audit logs, and continuous vulnerability management are baseline controls. Tenant data should be isolated through appropriate keys, authorization policies, and testing. Administrative access must be monitored because a managed service does not remove insider or credential risk.

Data location may have legal and contractual significance. Organizations should know where primary data, replicas, backups, logs, and support-access copies are stored. Retention and deletion policies must apply to replicas and snapshots, not merely the primary table. Regulatory requirements may influence shard location, encryption-key ownership, auditability, and cross-border transfer.

Operational governance should define ownership, service-level objectives, incident procedures, schema-change controls, backup testing, capacity budgets, and cost accountability. Observability should cover query latency, error rates, replication lag, lock waits, transaction aborts, storage growth, partition skew, cache behavior, and cloud spending. A dashboard showing only CPU utilization is inadequate for a distributed database.

Ethically, designers should consider unequal service quality across regions, privacy-preserving analytics, and the consequences of automated decisions based on stale or incomplete replicated data. Data minimization and purpose limitation reduce both privacy risk and distribution cost.

8. Illustrative Case Study: A Global Retail Platform

Background

A fictional retailer, Meridian Market, operates online stores in three geographic regions. Its original single relational database supports orders, inventory, customers, and payments. As sales grow, users in distant regions experience high latency, seasonal promotions overload the database, and a regional network outage interrupts all ordering.

Situation and problem

The retailer wants lower regional latency, continuous ordering during a regional failure, and the ability to scale during promotions. However, inventory must not be oversold, payment records require strong protection, and the finance department needs global reporting. A simplistic solution of placing a complete writable copy in every region would create conflicting inventory updates and difficult reconciliation.

Analysis

The workload contains distinct patterns. Product browsing is read-heavy and can tolerate brief staleness. Inventory reservation and payment authorization require strong transactional controls. Orders are naturally associated with a region and customer account, while global reporting is analytical and need not compete with the transactional database. The architecture should therefore avoid treating all tables and operations identically.

Approach and strategy

Meridian adopts regional partitions for orders and browsing data, using a carefully selected tenant-and-region strategy. Product catalogs are replicated asynchronously to regional read stores. Inventory for a product is assigned to an authoritative region or inventory pool, so reservation operations have a clear ownership point. Payment data remains in a strongly controlled relational service with tokenized payment references rather than raw card details.

The order workflow uses a local transaction for order creation and reservation, followed by an event-driven saga for payment confirmation and fulfillment. Each operation has an idempotency key so that retries do not create duplicate orders. A change-data-capture pipeline sends committed events to a cloud warehouse for global reporting. During a regional failure, browsing continues from replicas, while operations requiring the unavailable inventory authority are queued or routed according to explicit business rules rather than silently accepting inconsistent reservations.

The migration is performed in stages. The team first creates a replicated target, validates totals and sample business transactions, performs load and failure tests, and then uses a controlled cutover. Monitoring includes replication lag, reservation conflicts, queue age, p95 and p99 latency, failed transactions, and cost per order.

Outcome

The design improves regional responsiveness and isolates analytical workloads from order processing. It does not promise that every operation remains available during every failure. Instead, availability is defined by business function: catalog browsing remains broadly available, while inventory decisions preserve correctness. The organization also gains a tested recovery procedure rather than relying on the existence of replicas.

Learning points

The case demonstrates that distribution should follow workload and business semantics. Strong consistency is reserved for operations that need it; asynchronous replication is used where stale reads are acceptable; and a saga is selected because the process spans services that cannot efficiently share one global transaction. Most importantly, architecture, governance, testing, and business policy must be designed together.

9. Challenges, Limitations, and Best Practices

The most common mistake is assuming that adding nodes automatically produces linear scalability. Network traffic, coordination, skew, locks, metadata bottlenecks, and serial portions of queries frequently limit improvement. Another mistake is selecting a shard key based only on current data rather than future growth and access patterns. Global secondary indexes, cross-shard joins, and transactions that span many partitions can erase the benefits of sharding.

Teams also underestimate failure testing. A system that works during a complete shutdown may fail during delayed messages, partial packet loss, replica lag, clock errors, exhausted connection pools, or a partition that isolates a leader from a majority. Recovery procedures should be rehearsed, including restoration from backups and promotion of replicas.

Best practice is to begin with explicit service objectives: required consistency, RPO, RTO, latency percentiles, throughput, growth rate, geographic requirements, and budget. Keep transaction boundaries close to partition boundaries. Make retries safe through idempotency. Prefer immutable events or audit records where reconciliation matters. Use schema evolution practices that support rolling deployment. Monitor business outcomes as well as infrastructure metrics. Finally, document which guarantees are provided and which are deliberately traded away.

Current Developments and Emerging Directions

Cloud database platforms increasingly separate storage, compute, and control planes, allowing independent scaling and automated placement. Distributed SQL systems continue to combine relational schemas and transactions with horizontal distribution. Workload-aware placement, adaptive query execution, tiered storage, and serverless analytical engines are reducing the need for manual capacity planning.

AI-assisted administration is being applied to anomaly detection, index recommendations, workload forecasting, and query optimization. Such tools should remain advisory or governed by tested policies because an automatically created index, scaling action, or query rewrite can increase cost or affect write performance. Lakehouse architectures are also integrating data-lake flexibility with warehouse governance and transactional table formats, although their consistency, catalog, and interoperability properties must be evaluated for each use case.

The enduring trend is toward systems that combine multiple models: transactional databases, event streams, caches, object storage, and analytical engines. This increases capability but also creates a greater need for contracts, lineage, observability, and disciplined data governance.

Chapter Summary

Distributed databases place data or processing across networked nodes to improve locality, scale, resilience, and geographic reach. Fragmentation divides data, replication creates copies, and sharding distributes partitions according to a key. These techniques introduce trade-offs involving consistency, latency, coordination, skew, and recovery. CAP frames behavior during network partitions, while two-phase commit, consensus, quorum methods, and sagas provide different mechanisms for coordination and transaction management.

Parallel databases accelerate execution through shared-memory, shared-disk, or shared-nothing architectures and techniques such as repartitioned joins, vectorized execution, and data locality. Cloud databases add managed operations, elasticity, serverless execution, and consumption-based infrastructure, but also create concerns about cost, portability, security, compliance, and vendor dependence. Effective architecture begins with workload and business requirements, uses explicit RPO and RTO targets, tests failures and restoration, and assigns strong consistency only where its value justifies its cost.

Key Terms

Node: A computer or database instance participating in a distributed system.

Fragmentation: Division of a relation into logical subsets for storage or processing.

Horizontal fragmentation: Division of a relation by rows.

Vertical fragmentation: Division of a relation by columns, normally retaining a key.

Replication: Maintenance of multiple copies of data.

Sharding: Distribution of horizontal partitions across independent nodes.

Shard key: Attribute or set of attributes used to assign records to shards.

Data locality: Execution of computation close to the data it uses.

Skew: Uneven distribution of data or work across processing nodes.

CAP theorem: The result that partition tolerance, strong consistency, and universal availability cannot all be guaranteed during a network partition.

Linearizability: Consistency in which operations appear to occur atomically in real-time order.

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

Two-phase commit: A coordinator-based protocol for atomic distributed commitment.

Consensus: Agreement among distributed nodes on a value or ordered command sequence.

Quorum: Required subset of replicas whose participation establishes an operation's acceptance.

Saga: A sequence of local transactions coordinated through compensating actions.

Elasticity: Ability to add and release resources in response to workload changes.

RPO: Maximum acceptable period of data loss after a failure.

RTO: Maximum acceptable time for service restoration.

Serverless database: A database service in which infrastructure capacity is managed largely by the provider and may scale according to demand.

Review Questions

Short Answer Questions

1. Distinguish horizontal fragmentation from vertical fragmentation.

2. Why is a replica not a complete replacement for a backup?

3. What is the purpose of a shard key?

4. State the principal limitation of two-phase commit.

5. Define recovery point objective and recovery time objective.

Long Answer Questions

1. Explain the design trade-offs among synchronous replication, asynchronous replication, and multi-primary replication.

2. Compare shared-memory, shared-disk, and shared-nothing parallel database architectures.

3. Explain how CAP, consistency models, and quorum strategies influence distributed database design.

4. Describe distributed transaction processing using two-phase commit and contrast it with the saga pattern.

5. Evaluate managed cloud databases, serverless databases, and self-managed cloud deployments for different workloads.

Analytical / Application Questions

1. A social application has highly popular users whose records receive most requests. Propose a sharding and replication strategy, and explain how you would control hotspotting and stale reads.

2. An international bank requires strong transaction correctness, low regional latency, and operation during a regional network partition. Analyze the conflict among these objectives and recommend an architecture with explicit trade-offs.

3. Design a migration plan for a legacy relational order system moving to the cloud. Include workload assessment, migration strategy, validation, cutover, rollback, security, and RPO/RTO testing.

22. Multiple Choice Questions with Answers

Question 1

A database relation is divided by rows according to customer region, with each fragment containing complete customer records. Which technique is being used?

A. Vertical fragmentation

B. Horizontal fragmentation

C. Full replication

D. Broadcast joining

Correct Answer: B. Horizontal fragmentation

Question 2

What is the principal risk of asynchronous replication?

A. It prevents all read operations

B. It always requires a global two-phase commit

C. A replica may temporarily return stale data

D. It eliminates the need for backups

Correct Answer: C. A replica may temporarily return stale data

Question 3

A system must continue accepting operations during a network partition, even though replicas may temporarily disagree. Which trade-off does this most directly represent?

A. Choosing availability over strong consistency during the partition

B. Choosing vertical fragmentation over horizontal fragmentation

C. Choosing shared memory over shared nothing

D. Choosing RTO over RPO

Correct Answer: A. Choosing availability over strong consistency during the partition

Question 4

Why can two-phase commit reduce availability?

A. It never writes transaction logs

B. Participants may wait for a failed coordinator after preparing

C. It permits every participant to commit independently

D. It cannot coordinate more than one table

Correct Answer: B. Participants may wait for a failed coordinator after preparing

Question 5

A small table is copied to every worker before a join. Which parallel join strategy is this?

A. Broadcast join

B. Repartition join

C. Colocated join

D. Serial nested transaction

Correct Answer: A. Broadcast join

Question 6

Which shard-key property most directly reduces the risk of uneven load?

A. Low cardinality

B. Frequent mutation

C. Even distribution of records and requests

D. Dependence on a single geographic site

Correct Answer: C. Even distribution of records and requests

Question 7

What does a saga use when a later local transaction fails?

A. A compensating action

B. A mandatory global lock

C. A database snapshot only

D. A new shard key

Correct Answer: A. A compensating action

Question 8

Which statement best describes elasticity in a cloud database?

A. Permanent replacement of all backups

B. Automatic or controlled acquisition and release of resources as demand changes

C. Guarantee of linear speedup for every query

D. Removal of all network latency

Correct Answer: B. Automatic or controlled acquisition and release of resources as demand changes

Question 9

A workload consists mainly of large scans and aggregations over historical data. Which design is generally most appropriate?

A. A single-node OLTP database with no parallel execution

B. A column-oriented, parallel analytical system

C. A multi-primary store with no query statistics

D. A database using only vertical fragmentation

Correct Answer: B. A column-oriented, parallel analytical system

Question 10

During cloud migration, the team keeps the target synchronized with ongoing changes from the source before cutover. Which technique best describes this approach?

A. Change-data capture

B. Cold-start scaling

C. Vertical sharding

D. Leader fencing

Correct Answer: A. Change-data capture