Distributed Storage, Databases and Transactions

Introduction

Distributed applications rarely store all information on one machine. Data must be divided across servers, replicated for availability, placed near users for performance, and coordinated when one logical operation affects several components. These requirements make distributed storage and transactions fundamentally different from their centralized counterparts.

A distributed storage system must answer several questions: How is data partitioned? How are replicas kept consistent? What happens when a machine or network link fails? Which guarantees are provided to applications? A distributed database must additionally manage indexes, queries, concurrency, recovery, and schema evolution across nodes. Transaction processing introduces a further tension: strong consistency and isolation simplify application reasoning, whereas weak coordination often provides better scalability and availability.

This chapter examines partitioning and sharding, distributed file systems, object stores, NoSQL and NewSQL databases, and transaction models ranging from ACID transactions to sagas. It also considers design trade-offs, operational practices, governance, and a detailed applied scenario.

Learning Objectives

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

1. Explain partitioning, replication, sharding, and distributed storage architectures.

2. Compare distributed file systems, block storage, and object stores.

3. Distinguish key-value, document, column-family, graph, and NewSQL databases.

4. Apply ACID properties and isolation-level concepts to distributed transactions.

5. Explain concurrency-control methods, two-phase commit, sagas, and compensating transactions.

6. Select an appropriate storage and transaction strategy for a distributed application.

7. Evaluate performance, consistency, availability, security, governance, and operational risks.

1. The Distributed Data Problem

In a centralized database, a single system commonly controls storage, locking, logging, and transaction commit. In a distributed database, data and computation are spread across nodes connected by a network. The network introduces latency, partial failure, message loss, duplication, reordering, and temporary disconnection. A node may be functioning correctly while being unable to communicate with another node.

Three properties are especially important:

• Scalability: the system should handle growing data volume, request rate, and number of users.
• Availability: it should continue responding despite selected failures.
• Consistency: clients should observe data according to a defined correctness model.

These properties are not simply three independent switches. Strong consistency may require coordination, and coordination is affected by latency and failures. Consequently, distributed database design is an exercise in specifying which guarantees are essential and which can be relaxed.

Important terminology

A node is a participating server or process. A partition is a logical subset of data; the same word also describes a communication failure in discussions of fault tolerance, so context matters. Replication stores multiple copies of data. A leader or primary coordinates writes for a replicated group, while followers or replicas maintain additional copies. A quorum is a sufficient subset of replicas required for an operation. Consistency describes the visibility and ordering of updates, whereas durability concerns survival of committed data after failures.

2. Partitioning, Sharding and Replication

2.1 Partitioning strategies

Partitioning divides a dataset into subsets called shards or partitions. The objective is to distribute storage and workload while preserving efficient access.

Range partitioning assigns contiguous key ranges to partitions. For example, customer identifiers 1–1,000,000 may be placed in one range and larger identifiers in another. Range partitioning supports range scans, but monotonically increasing keys can concentrate new writes in the final partition. Rebalancing is required when partitions become uneven.

Hash partitioning applies a deterministic hash function to a key and maps the result to a partition. It generally distributes point lookups and writes more evenly, but range queries become expensive because relevant records may be scattered across many partitions.

List partitioning assigns explicitly defined values, such as country or business unit, to partitions. It is useful when business boundaries are stable, but a single value can become disproportionately large.

Consistent hashing places both keys and nodes on a logical ring. When a node is added or removed, only a subset of keys normally moves. Virtual nodes can improve balance. Consistent hashing reduces, but does not eliminate, rebalancing complexity.

2.2 Choosing a shard key

A good shard key has high cardinality, distributes load evenly, supports common access patterns, and avoids hotspots. A key should also be stable: changing it may require moving a record between partitions. Designers must analyze both storage distribution and request distribution. A field can be statistically balanced yet operationally poor if most requests target a small subset of values.

Cross-shard operations are costly because they require network communication and often coordination. A schema should therefore place frequently accessed related data together where this does not create unacceptable imbalance. This technique is sometimes called data locality or co-partitioning.

2.3 Replication

Replication improves availability, read capacity, and fault tolerance. In synchronous replication, a write is acknowledged only after specified replicas confirm it. This can provide stronger durability but increases write latency. In asynchronous replication, the primary acknowledges before all replicas receive the update; performance improves, but replicas may lag and recent acknowledged data may be lost if failures occur before propagation.

Replication may be:

• Leader-based, with one replica ordering writes;
• Leaderless, with clients or coordinators communicating with several replicas; or
• Multi-leader, with multiple sites accepting writes and resolving conflicts.

Replication factor alone does not define durability or consistency. Placement matters: three replicas on one physical host are not equivalent to three replicas distributed across failure domains. Professional designs consider racks, availability zones, regions, power domains, and independent network paths.

For a simple replicated group of size N, a quorum design may require a read quorum R and write quorum W such that R + W > N for read and write sets to intersect. This intersection supports certain consistency techniques, but it is not by itself a complete guarantee of linearizability. Correctness also depends on versioning, conflict resolution, failure handling, and the protocol used to order operations.

2.4 Rebalancing and hotspots

Adding capacity requires moving partitions without interrupting service. Rebalancing consumes network and disk bandwidth and can compete with application traffic. Systems commonly throttle migration, use temporary replicas, and monitor skew. Hotspots may arise from sequential identifiers, popular products, large tenants, or uneven geographic demand. Remedies include salting keys, splitting hot partitions, caching, workload isolation, and adaptive partitioning.

3. Distributed Storage Systems

3.1 Distributed file systems

A distributed file system presents files and directories across multiple machines. It is appropriate for large files, sequential processing, shared datasets, and analytical workloads. A typical architecture separates metadata management from data blocks. Files are divided into blocks, replicated, and processed near the nodes holding the data where possible.

Important design concerns include block size, replication, metadata scalability, repair after failure, and consistency semantics. Large blocks reduce metadata overhead but may waste space for small files. A centralized metadata service simplifies namespace management but can become a bottleneck unless it is replicated or partitioned. Distributed file systems are generally less suitable for billions of tiny, latency-sensitive objects unless specialized support is provided.

3.2 Object storage

Object stores organize data as objects identified by keys within namespaces such as buckets or containers. An object includes payload data, metadata, and an identifier. Object storage offers high durability, elastic capacity, and a simple HTTP-based interface. It is widely used for backups, media, datasets, logs, archives, and data lakes.

Unlike a traditional file system, object storage normally does not provide arbitrary in-place updates or general-purpose directory semantics. Applications commonly write a new object and replace or version the old one. Object stores may provide strong read-after-write behavior for some operations, but semantics must be checked for the particular service and operation. They are excellent for immutable or append-oriented data, but poorly suited to workloads requiring many small transactional updates.

3.3 Block storage

Block storage exposes virtual disks or blocks to a host, allowing a conventional file system or database to manage them. It supports low-level random access and is therefore useful for database data files. However, the database and storage service must coordinate carefully regarding caching, durability, snapshots, and failure recovery.

The choice among file, object, and block storage should follow access patterns rather than product popularity. Large sequential analytics favor distributed files or objects; transactional databases commonly favor block-like storage; static content and archival data favor objects.

4. Database Families

4.1 Relational databases and distributed SQL

Relational databases represent data in tables with schemas, constraints, joins, and declarative SQL. Their mature transaction models and integrity constraints make them appropriate for financial, operational, and highly relational workloads.

A distributed relational database, often called a NewSQL system, attempts to retain SQL and strong transactional semantics while distributing storage and execution horizontally. It may use consensus replication, distributed timestamps, range or hash partitioning, and a distributed query planner. NewSQL is attractive when applications require joins and ACID transactions but cannot rely on one machine.

The costs include coordination latency, cross-partition transactions, complex query planning, and operational demands. SQL syntax does not guarantee identical behavior across products; isolation, schema changes, indexes, and failure semantics must be verified experimentally and in documentation.

4.2 NoSQL databases

NoSQL is a broad family rather than one uniform technology.

• Key-value stores map keys to opaque values and provide very fast point access.
• Document databases store semi-structured documents, often supporting indexes and queries over fields.
• Column-family or wide-column stores organize data by partition keys and clustered columns, supporting high write volume and predictable access paths.
• Graph databases represent vertices and edges and optimize relationship traversal.

NoSQL systems often encourage denormalization and query-driven modeling. Instead of designing tables independently of queries, the developer identifies access patterns and stores data in forms that make those patterns efficient. The same business fact may appear in several documents or partitions, creating an application responsibility to maintain copies consistently.

NoSQL does not mean “no consistency” or “no transactions.” Many systems provide atomic operations within a key or partition, conditional updates, and sometimes multi-record transactions. The exact scope must be understood rather than inferred from the product category.

4.3 Polyglot persistence

A service may use several storage technologies: a relational database for orders, an object store for documents, a search engine for indexing, and a cache for low-latency reads. This is polyglot persistence. It can match technologies to workloads, but it creates multiple sources of failure, data duplication, security policies, backup procedures, and synchronization processes. Each additional store should have a justified responsibility and an explicit consistency strategy.

5. ACID and Distributed Transaction Semantics

A transaction is a logical unit of work that moves data from one valid state to another.

• Atomicity: all transaction effects occur, or none become visible.
• Consistency: committed results preserve declared integrity rules and application invariants. This is not the same as a particular replication guarantee.
• Isolation: concurrent transactions do not observe prohibited intermediate or conflicting effects.
• Durability: committed effects survive specified failures.

In distributed systems, ACID is not a single universal service level. Atomicity across two partitions is more demanding than atomicity within one partition. Durability depends on stable storage and replica acknowledgment. Consistency depends on constraints, ordering, and visibility rules. Transaction documentation must therefore specify scope, failure assumptions, and isolation level.

5.1 Isolation levels

Read uncommitted may allow dirty reads and is rarely appropriate for correctness-critical operations.

Read committed prevents reading data committed by no transaction, but repeated reads may return different values and a query may see rows inserted by another transaction.

Repeatable read generally ensures that rows read by a transaction remain stable under the system’s defined model, although implementations differ regarding phantom rows and predicate locking.

Serializable provides behavior equivalent to some serial order of committed transactions. It offers the strongest conventional isolation but may reduce concurrency through locks, validation failures, or transaction retries.

Some distributed systems provide snapshot isolation, in which a transaction reads from a consistent snapshot and writes are checked for conflicts. Snapshot isolation prevents many anomalies but is not universally equivalent to serializability; write-skew anomalies can occur when two transactions read overlapping facts and update different records.

5.2 Concurrency control

Two-phase locking (2PL) obtains locks during a growing phase and releases them during a shrinking phase. Strict 2PL holds write locks until commit or abort, helping prevent cascading effects. Distributed locking introduces lock-manager failures, network delays, and deadlocks spanning nodes. Deadlock detection, timeouts, and transaction aborts are necessary safeguards.

Optimistic concurrency control (OCC) allows transactions to execute without long-held locks, then validates whether conflicting changes occurred before commit. It performs well when conflicts are uncommon but causes retries under contention.

Multi-version concurrency control (MVCC) stores multiple committed versions so readers can proceed without blocking writers. Old versions require garbage collection, and long-running readers can delay reclamation. Distributed MVCC additionally requires compatible timestamps or ordering mechanisms.

A transaction retry is not automatically safe. The application must ensure that external effects, such as sending an email or charging a card, are not repeated incorrectly. Idempotency keys, durable outbox records, and deduplication are common solutions.

6. Distributed Commit Protocols

6.1 Two-phase commit

Two-phase commit (2PC) coordinates an atomic decision among a coordinator and participants.

Phase 1—prepare: the coordinator asks each participant whether it can commit. Each participant validates the transaction, records sufficient recovery information, and replies “prepared” or “abort.” A participant that reports prepared must be able to commit later.

Phase 2—decision: if every participant prepared successfully, the coordinator records and broadcasts commit; otherwise it records and broadcasts abort. Participants then make the decision durable and acknowledge completion.

2PC provides atomic commitment under its protocol assumptions, but it is a blocking protocol. If the coordinator fails after participants prepare and before they learn the final decision, participants may retain locks and remain uncertain. Logging, coordinator recovery, replication, and timeouts reduce risk but do not remove the fundamental coordination cost. 2PC also increases latency because it requires multiple network rounds and durable logging.

Three-phase commit attempts to reduce blocking by adding an intermediate phase, but it depends on stronger timing and failure assumptions and is not a universal replacement. Consensus-based commit protocols can improve fault tolerance, yet they still incur coordination and should not be described as free or automatically non-blocking.

6.2 Sagas and compensating transactions

A saga divides a long business transaction into a sequence of local transactions. Each local transaction commits independently. If a later step fails, compensating actions semantically undo earlier effects. For example, a travel booking saga may reserve a flight, reserve a hotel, and authorize payment. If hotel reservation fails, the system cancels the flight reservation and reverses the payment authorization.

A compensation is not necessarily the mathematical inverse of the original action. A shipped item cannot literally be “unshipped”; compensation may create a return request or refund. Sagas therefore require explicit business semantics, durable workflow state, idempotent steps, retry policies, and reconciliation for permanently failed actions.

A saga can be orchestrated by a central workflow coordinator or choreographed through events. Orchestration provides visibility and centralized control; choreography reduces a central dependency but can make behavior and ownership difficult to understand. Sagas provide availability and avoid holding distributed locks, but intermediate states become visible and temporary inconsistency is expected.

7. Worked Example: Choosing a Transaction Strategy

Consider an online marketplace order involving inventory, payment, and shipping. Inventory is stored in a distributed SQL database, payment is an external provider, and shipping is a separate service.

A single 2PC transaction across all three systems is usually impractical because the payment and shipping providers may not support the protocol, and holding locks while waiting for external services would reduce availability. A saga is more appropriate:

1. Create the order with status `PENDING`.

2. Reserve inventory using an idempotency key.

3. Authorize payment using the same order reference.

4. Create a shipment.

5. Mark the order `CONFIRMED`.

If step 3 fails, release inventory. If step 4 fails, void the payment authorization and release inventory. Each operation records a durable status transition. A retry of “reserve inventory” must return the original result rather than reserving twice. A background reconciler checks orders stuck in intermediate states.

The order status is not merely a display field; it is part of the workflow state machine. Valid transitions should be constrained, such as `PENDING → RESERVED → PAID → SHIPPED`, with explicit failure and compensation transitions. This design accepts temporary inconsistency between services while preserving business invariants such as “a shipped order has an authorized payment” to the extent defined by the workflow.

8. Illustrative Case: Regional Learning Platform

Background

This illustrative case concerns a fictional university learning platform serving students across three regions. It stores course videos, assignments, submissions, grades, and access-control information. Enrollment peaks at the beginning of semesters, and users expect video playback to remain available during regional failures.

Problem

The original system stored videos and submissions on one database server. Large media files consumed database capacity, enrollment queries created hotspots, and a failure interrupted access. The university also needed auditability for grade changes and compliance with retention and privacy policies.

Analysis

Video objects are large, mostly immutable, and read frequently, so they do not belong in the transactional database. Submission metadata and grades require indexed queries and transactional updates. Student records must be protected by role-based access controls. Enrollment writes are less frequent than video reads but must preserve constraints such as one valid enrollment per student-course pair.

Approach

The platform adopted object storage for videos and submission attachments, with versioning and lifecycle policies. A distributed relational database stored students, courses, enrollments, submissions, and grades. Enrollment data was partitioned by course identifier, while high-volume submission records were partitioned using a course-and-term strategy designed to avoid a single semester hotspot. Replicas were placed across availability zones.

A database transaction created an enrollment and its audit record together. Video publication used an outbox record: the database transaction recorded that a video should be published, and a worker uploaded the object and updated publication status. The worker used an idempotency key so retries did not create conflicting logical publications. Grade release used a saga across the grade database, notification service, and analytics index. If notification failed, the grade remained valid and notification was retried rather than rolling back the academic result.

Access was enforced through least privilege, encryption in transit and at rest, separate administrative roles, and immutable audit logs. Personal data retention and deletion rules were mapped to institutional policy and applicable privacy law. Backups were tested through restoration exercises rather than merely configured.

Outcome

The architecture separated high-volume media delivery from transactional data, reduced database storage pressure, and allowed regional failover. The system accepted that analytics and notifications could lag slightly, while grades and enrollment remained strongly protected. Operational dashboards tracked replication lag, object publication failures, transaction retries, partition skew, and unresolved saga states.

Learning points

The case demonstrates that storage selection should follow access patterns, not a desire to use one technology everywhere. It also shows that strong consistency should be reserved for invariants that require it, while asynchronous workflows can improve resilience when their intermediate states and compensations are explicitly designed.

9. Design, Governance and Operational Practice

Performance and cost

Distributed systems pay for network hops, serialization, coordination, replication, and background repair. Measure p50, p95, and p99 latency rather than averages alone. Monitor throughput, error rate, hot partitions, storage growth, replica lag, lock waits, transaction aborts, and cross-region traffic. Capacity planning should include failure scenarios because a surviving node may need to serve the workload of failed peers.

Security and governance

Data should be classified before selecting storage. Sensitive data requires access control, encryption, key management, auditability, and retention policies. Replicas and backups may cross legal jurisdictions, creating residency and transfer obligations. Deletion requests are complicated by immutable logs, snapshots, caches, and replicas. Tokenization or field-level encryption may reduce exposure, but encrypted fields can limit indexing and query functionality.

Least privilege should apply to applications, operators, replication agents, and backup services. Administrative access must be logged and reviewed. Integrity controls should protect audit records from unauthorized modification.

Reliability practices

Use explicit schemas and versioned migrations. Test node, zone, region, coordinator, storage, and network failures. Verify backup restoration and point-in-time recovery. Use timeouts carefully: a timeout means uncertainty, not proof that an operation failed. Idempotency keys and deduplication protect against retries. Reconciliation jobs detect divergence between stores. Operational runbooks should define when to pause traffic, fail over, repair replicas, or compensate a workflow.

Contemporary developments

Cloud-native databases increasingly separate compute and storage, use elastic serverless capacity, and support distributed SQL with consensus replication. Data lakes and lakehouses combine object storage with table formats, catalogs, schema evolution, and analytical query engines. Streaming systems increasingly act as durable event backbones, but an event log is not automatically a transactional database. AI systems also depend on distributed vector indexes, feature stores, and object-based training data; these introduce familiar concerns of partitioning, freshness, access control, lineage, and deletion. AI-generated data or automated decisions must be governed for provenance, privacy, bias, and reproducibility.

Challenges and Limitations

No architecture eliminates trade-offs. Strong distributed transactions may increase latency and reduce availability during partitions. Eventual consistency can produce stale reads and confusing user experiences. Denormalization improves reads but multiplies update paths. Automatic rebalancing can consume resources at the worst possible time. Distributed queries may suffer from data transfer amplification. Sagas require business-specific compensations and do not provide instantaneous atomic visibility. Object stores are durable but do not replace a query-optimized transactional database. Finally, operational complexity often becomes the dominant cost: monitoring, upgrades, incident response, compliance, and recovery require skilled personnel and sustained investment.

Best-Practice Decision Framework

A practical design sequence is:

1. Identify business invariants and classify which operations require atomicity.

2. Document access patterns, data size, growth, latency, and locality requirements.

3. Select storage primitives according to data shape and update behavior.

4. Choose partition keys and model likely hotspots and rebalancing.

5. Define consistency, durability, and failure guarantees in observable terms.

6. Minimize cross-partition transactions; use 2PC only when its guarantees justify its cost.

7. Use sagas for long-running or externally integrated workflows, with explicit compensation.

8. Make retries safe through idempotency and durable workflow state.

9. Test failures, restoration, security controls, and data-governance processes.

10. Reassess the design using production measurements rather than assumptions.

Chapter Summary

Distributed storage divides data and responsibility across nodes, creating opportunities for scale and availability while introducing network latency, partial failure, rebalancing, and consistency challenges. Range, hash, list, and consistent-hash partitioning serve different access patterns, and shard-key selection is central to avoiding hotspots. Replication improves resilience but must be evaluated by acknowledgment policy and failure-domain placement.

Distributed file systems suit large shared files and analytical processing; object stores suit durable, immutable or append-oriented objects; block storage supports low-level database access. Relational, NoSQL, and NewSQL systems differ in schema, query, transaction, and scalability models. ACID properties must be interpreted in terms of transaction scope and failure assumptions. Isolation levels and concurrency-control techniques determine which anomalies are possible.

Two-phase commit provides atomic commitment but incurs coordination and blocking risks. Sagas divide long workflows into local transactions and use compensating actions, requiring idempotency, durable state, and reconciliation. Effective designs align storage technology and consistency guarantees with business invariants, while also addressing security, privacy, compliance, observability, recovery, and operational cost.

Key Terms

Partitioning: Dividing a dataset into logical subsets.

Sharding: Distributing partitions across independent storage nodes.

Replication: Maintaining multiple copies of data.

Shard key: Attribute used to determine a record’s partition.

Hotspot: Partition or node receiving disproportionate workload.

Quorum: Required subset of replicas participating in an operation.

Distributed file system: File system whose data and metadata span multiple nodes.

Object storage: Storage of identified objects containing data and metadata.

NoSQL: Broad family of nontraditional, often horizontally scalable databases.

NewSQL: Distributed relational database technology retaining SQL and strong transactions.

Atomicity: All-or-nothing visibility of a transaction’s effects.

Isolation: Control over interactions among concurrent transactions.

MVCC: Concurrency control using multiple committed data versions.

Two-phase commit: Prepare-and-commit protocol for atomic distributed commitment.

Saga: Sequence of local transactions coordinated as a business workflow.

Compensating transaction: Action that semantically offsets an earlier operation.

Idempotency: Property that repetition has the same intended effect as one execution.

Eventual consistency: Model in which replicas may temporarily differ but converge under stated conditions.

Polyglot persistence: Use of multiple storage technologies in one system.

Review Questions

Short Answer Questions

1. What is the difference between partitioning and replication?

2. Why can hash partitioning make range queries more expensive?

3. State the four ACID properties.

4. What problem does an idempotency key address?

5. Why is two-phase commit considered a blocking protocol?

Long Answer Questions

1. Compare distributed file systems, object stores, and block storage for transactional and analytical workloads.

2. Explain how shard-key selection affects performance, scalability, and rebalancing.

3. Compare 2PL, optimistic concurrency control, and MVCC.

4. Explain the benefits and limitations of NewSQL compared with NoSQL databases.

5. Describe saga orchestration, choreography, and compensating transactions using a suitable business workflow.

Analytical / Application Questions

1. Design a storage architecture for a global video platform. Justify your partitioning, replication, object-storage, metadata, and consistency choices.

2. An order workflow reserves inventory, charges a payment provider, and schedules delivery. Determine which steps should be local transactions and design compensation and retry behavior for each failure point.

3. A distributed database shows increasing p99 latency, uneven partition sizes, and replica lag after a new customer becomes extremely popular. Diagnose likely causes and propose a staged remediation plan.

Multiple Choice Questions with Answers

Question 1

Which partitioning strategy is generally most suitable for distributing point lookups evenly when the key has a good hash distribution?

A. Hash partitioning

B. Range partitioning

C. List partitioning

D. Single-node partitioning

Correct Answer: A. Hash partitioning

Question 2

Which storage type is usually most appropriate for large, immutable media objects?

A. Object storage

B. Lock table storage

C. In-memory register storage

D. Relational index pages only

Correct Answer: A. Object storage

Question 3

What does atomicity require in a transaction?

A. All transaction effects occur or none become visible

B. Every read returns the newest global value

C. All replicas use identical hardware

D. Transactions never wait

Correct Answer: A. All transaction effects occur or none become visible

Question 4

Which isolation level provides behavior equivalent to some serial order of committed transactions?

A. Read uncommitted

B. Read committed

C. Serializable

D. Eventual consistency

Correct Answer: C. Serializable

Question 5

What is a major limitation of two-phase commit?

A. It cannot coordinate more than one participant

B. Prepared participants may block while awaiting the coordinator’s decision

C. It prevents durable logging

D. It eliminates all network communication

Correct Answer: B. Prepared participants may block while awaiting the coordinator’s decision

Question 6

In a saga, what normally happens when a later local transaction fails?

A. All earlier databases are physically erased

B. Compensating actions are executed for relevant earlier steps

C. The network is disconnected

D. The failure is always ignored

Correct Answer: B. Compensating actions are executed for relevant earlier steps

Question 7

Which technique allows readers to use committed versions without necessarily blocking writers?

A. MVCC

B. Static partitioning

C. Object version naming only

D. DNS round-robin

Correct Answer: A. MVCC

Question 8

Why are monotonically increasing keys potentially problematic in a range-partitioned database?

A. They can concentrate new writes in the final range

B. They prevent any record from being stored

C. They automatically encrypt all values

D. They eliminate the need for indexes

Correct Answer: A. They can concentrate new writes in the final range

Question 9

Which statement best describes NewSQL systems?

A. They provide only unstructured object storage

B. They seek distributed scale while retaining SQL and transactional semantics

C. They cannot use replication

D. They are exclusively graph databases

Correct Answer: B. They seek distributed scale while retaining SQL and transactional semantics

Question 10

What is the principal purpose of an idempotency key in a retried distributed operation?

A. To ensure a retry does not unintentionally create a duplicate effect

B. To increase partition skew

C. To remove all authorization checks

D. To force every operation into read uncommitted isolation

Correct Answer: A. To ensure a retry does not unintentionally create a duplicate effect