Data Storage · Study deck

CAP Theorem and Database Categories

A storage link between two sites fails while an operator transfers a gateway to a new customer.

Data Dora is your guide for this deck.

theoremsharding

Data Dora, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: Classification identifies the fact, consequence sets the risk, chosen behavior defines the partition response, reconciliation explains convergence, and attached tests prove the design behaves that way under an actual link failure.
Explain: The theorem applies to the guarantees being promised, so an append-only measurement queue can have a different contract from the record that authorizes account access.
Explain: The theorem is not contradicted by useful degraded operation: the designer has bounded the promise instead of providing both incompatible guarantees for the same authoritative operation.
Explain: Sharding is easiest to understand from the user's query.

Major section

Start With the Broken Link · Overview: Review Partition Behavior By Record Class

Room readings keep arriving at the edge, while two managers try to change the named owner of a door device from different places.

The data owner must decide which work may continue and which must wait for one agreed answer.
Separate the records by consequence.

CAP evidence timeline for a 12-minute edge-to-cloud outage.

Major section

Practitioner: Build A Partition Decision Ledger · Under The Hood: CAP Claims Depend On Mechanics

Each role needs its own partition decision.

Classification identifies the fact, consequence sets the risk, chosen behavior defines the partition response, reconciliation explains convergence, and attached tests prove the design behaves that way under an actual link failure.
A release review should therefore treat category claims as hypotheses.

Major section

Sharding Strategies · Overview: Sharding Is A Routing Contract

Sharding is easiest to understand from the user's query.

A support page wants one device's recent history now, while an operations report may need a whole fleet summary later.
A good shard key makes the common path predictable and gives the expensive path a controlled plan instead of a surprise fan-out.

Sharding strategy decision guide for time, device-hash, and hybrid routing.

Major section

Practitioner: Build The Shard-Key Ledger · Under The Hood: Rebalancing And Hot Keys Decide Production Risk

A sharded design changes over time.

It should list each required query, the fields available in that query, the expected write distribution, and the evidence that proves routing under realistic load.
Sharding assigns records to different ownership groups or nodes.
Naive routing can make growth dangerous.

Major section

Keep an Ownership Change out of a Split Replica

The theorem's consistency requirement means that a successful authoritative read cannot present the old ownership as if it followed the completed change.

If the isolated site must always return a successful answer from its local copy, that answer can disagree with the latest completed ownership change.
A consistency-first design instead delays or refuses an answer when it cannot establish the required authority.
The theorem explains why this response gives up availability for that operation during the partition, even though the local database process is still running.

Major section

Keep an Ownership Change out of a Split Replica (continued)

The theorem applies to the guarantees being promised, so an append-only measurement queue can have a different contract from the record that authorizes account access.

It accumulates 120 divided by 5 = 24 records; at an illustrative 80 bytes each, those records occupy 1,920 bytes before storage overhead.
The theorem is not contradicted by useful degraded operation: the designer has bounded the promise instead of providing both incompatible guarantees for the same authoritative operation.
Also predict whether the 24 buffered records made the live dashboard current throughout the outage.

Major section

Keep an Ownership Change out of a Split Replica (continued)

They repair history later; they could not provide timely remote observations while the link was absent.

The theorem does not prescribe a conflict-resolution algorithm; choosing how ownership disputes are settled after reconnection remains a separate design task.
Under the theorem's consistency requirement, synchronized clocks alone cannot reveal a completed write that the isolated replica has never received.
The theorem also leaves capacity engineering open: additional shards can distribute queries, but they cannot carry coordination traffic across an unavailable link.

Major section

Summary · Key Takeaway

CAP is a partition-behavior review for distributed storage, not a database popularity label.

Consistency-first behavior coordinates, rejects, queues, or degrades when authority is unavailable.
Availability-first behavior can be defensible for some append-only or derived data only when replay, conflict, freshness, and audit evidence are explicit.
Database categories are useful shortcuts, but release evidence depends on configuration, client behavior, topology, operations, and tested failure modes.

Deck summary

Key takeaways

Room readings keep arriving at the edge, while two managers try to change the named owner of a door device from different places.

Each role needs its own partition decision.
Sharding is easiest to understand from the user's query.
A sharded design changes over time.
The theorem's consistency requirement means that a successful authoritative read cannot present the old ownership as if it followed the completed change.

Retrieval practice

Recall check 1 of 6

Data Dora says: answer from memory, then check your reasoning.

Q1What is the best first question when reviewing CAP behavior for an IoT storage design?

AWhat should each record class do during a network partition, and what evidence proves that behavior?

BWhich database logo appears most often in reference architectures?

CCan partition behavior be deferred until the IoT network fails in the field?

DCan timestamped last-write-wins settle partition conflicts across telemetry and command records?

Show answer

Answer: A CAP becomes useful when the review names the record class, partition behavior, and release evidence.

Retrieval practice

Recall check 2 of 6

Data Dora says: answer from memory, then check your reasoning.

Q2A design says the database is AP, so firmware manifests, telemetry, latest dashboard values, and device ownership can all keep accepting writes during a cloud partition. What should the review require?

AApproval based on keeping writes available during disconnection.

BOnly a dashboard screenshot taken during normal connectivity.

CA separate partition decision for each record class.

DA database conflict policy instead of application idempotency keys.

Show answer

Answer: C Different IoT data classes have different consequences, so a single database-category label is not enough.

Retrieval practice

Recall check 3 of 6

Data Dora says: answer from memory, then check your reasoning.

Q3A gateway buffers telemetry during an outage and replays it after reconnect, but the design has no idempotency key, timestamp-source rule, or duplicate policy. What is the strongest technical finding?

ATreat local buffering as sufficient proof of replay correctness.

BDiscard late records silently to simplify replay.

CUse a successful dashboard load as the replay acceptance test.

DBlock release until replay behavior is defined and tested.

Show answer

Answer: D Local acceptance can be useful, but convergence mechanics and evidence make it trustworthy: replay, duplicate handling, timestamp policy, quality propagation, and audit evidence must all be defined and tested.

Retrieval practice

Recall check 4 of 6

Data Dora says: answer from memory, then check your reasoning.

Q4A fleet dashboard usually reads one device's recent history, but a monthly retention job also needs to remove old raw data. Which design is usually the safest starting point?

ARoute rows randomly across shards to spread ingestion, then merge the results for device-history queries.

BRoute by firmware version and month so rollout cohorts stay together during historical analysis.

CRoute by device alone and use row-by-row deletion for the monthly retention job.

DRoute by a device-oriented key and keep bounded time buckets inside that route.

Show answer

Answer: D A strong shard-key design preserves the common query path while keeping lifecycle operations bounded and testable.

Retrieval practice

Recall check 5 of 6

Data Dora says: answer from memory, then check your reasoning.

Q5A design routes records with hash(key) modulo the number of storage nodes. The team plans to add nodes as the fleet grows but has no rebalance test. What is the strongest technical concern?

AKeep modulo routing and assume adding nodes preserves most ownership.

BRebalancing evidence is unnecessary if the dashboard is visually clear.

CChanging the node count may move many keys at once.

DAdd nodes because the cluster redistributes ownership automatically with little movement cost.

Show answer

Answer: C A production sharding design must prove how ownership changes without corrupting reads, writes, and recovery.

Retrieval practice

Recall check 6 of 6

Data Dora says: answer from memory, then check your reasoning.

Q6After a network split, two sites disagree about a device owner. Which repair rule is defensible?

AAccept the latest local timestamp without resolving owner conflict.

BTreat the two owner values as duplicate telemetry and keep both active.

CUse named authority and review conflicting writes before assigning owner.

DIgnore the conflict because the sites can reconnect now.

Show answer

Answer: C Ownership needs an authority rule and conflict evidence, not clock luck.

Print reference

Answers 1 of 2

Answer key.

A · CAP becomes useful when the review names the record class, partition behavior, and release evidence.
C · Different IoT data classes have different consequences, so a single database-category label is not enough.
D · Local acceptance can be useful, but convergence mechanics and evidence make it trustworthy: replay, duplicate handling, timestamp policy, quality propagation, and audit evidence must all be defined and tested.
D · A strong shard-key design preserves the common query path while keeping lifecycle operations bounded and testable.

Print reference

Answers 2 of 2

Answer key.

C · A production sharding design must prove how ownership changes without corrupting reads, writes, and recovery.
C · Ownership needs an authority rule and conflict evidence, not clock luck.