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.
iotclass.org

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: Database Categories Are Shortcuts Relational databases, wide-column stores, document databases, event logs, time-series databases, object stores, and caches can all be configured in ways that change partition behavior.
  • Explain: If a team says a store is available enough, the review asks what users may read while data is stale and how conflicts converge after reconnect.
  • Distinguish consistency-first and availability-first partition behavior
iotclass.org

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.

Key terms

CAP theorem
CAP theorem is a way to reason about distributed storage when communication breaks between nodes that normally coordinate.

Why it matters

A latest-value cache is different again because it is derived and must expose freshness and rebuild rules.

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

Major section

Practitioner: Build A Partition Decision Ledger

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.
  • Step 1, classify the record.: Identify whether the data is telemetry, command, device registry, ownership, firmware state, event, cache, media artifact, or analytical output.
  • Two partitions may grant or revoke different authority for the same device.

Why it matters

Step 3, choose behavior.: Decide whether to reject, queue, accept locally, degrade to read-only, use stale reads, or allow derived answers.

iotclass.org

Major section

Practitioner: Build A Partition Decision Ledger (continued)

Step 2, rank the consequence.: Describe what happens if the value is wrong, stale, missing, duplicated, reordered, or accepted in two places.

  • Step 5, attach evidence.: Keep partition tests, failover tests, replay tests, restore drills, stale-read labels, and owner approval with the release record.
  • Coordinate with a single authority, reject when authority is unavailable, or require explicit recovery workflow.
  • Conflicting targets can push devices into unsafe or hard-to-recover states.
iotclass.org

Major section

Practitioner: Build A Partition Decision Ledger (continued)

Partition test, rollout dry run, rollback test, owner approval, and audit evidence.

  • Samples may arrive late, duplicate, out of order, or with incomplete quality context.
  • Users may see stale derived state while durable history is unavailable or delayed.
  • A release review should therefore treat category claims as hypotheses.
iotclass.org

Major section

Practitioner: Build A Partition Decision Ledger (continued)

Database Categories Are Shortcuts Relational databases, wide-column stores, document databases, event logs, time-series databases, object stores, and caches can all be configured in ways that change partition behavior.

  • If a team says a store is consistent enough, the review asks for the exact write path, read path, failure mode, and test evidence.
  • If a team says a store is available enough, the review asks what users may read while data is stale and how conflicts converge after reconnect.
  • Step 3, choose behavior.: Decide whether to reject, queue, accept locally, degrade to read-only, use stale reads, or allow derived answers.
iotclass.org

Major section

Under The Hood: CAP Claims Depend On Mechanics · Sharding Strategies

CAP is often reduced to labels, but the mechanics decide whether a claim holds.

  • A system that coordinates before accepting a write needs leader election, quorum or consensus behavior, timeout handling, client retry semantics, and clear rejection behavior.
  • Quorum shorthand can help explain the intuition.

Why it matters

If the replay creates 730 records because 10 retries were counted twice, the system was available during the partition but not release-ready for that data class.

iotclass.org

Major section

Overview: Sharding Is A Routing Contract · Practitioner: Build The Shard-Key Ledger

Sharding splits records across storage nodes so one machine is not responsible for every write, read, and byte of growth.

  • The key design choice is the shard key.
  • The useful question is not "is the database sharded?" The useful question is whether the routing contract matches the workload.

Key terms

Retention
Retention is easy, but all live writes hit the newest time bucket.
Sharding strategy decision guide for time, device-hash, and hybrid routing.
Sharding strategy decision guide for time, device-hash, and hybrid routing.
iotclass.org

Major section

Under The Hood: Rebalancing And Hot Keys Decide Production Risk · Keep an Ownership Change out of a Split Replica

A sharded design changes over time.

  • Device fleets grow unevenly, tenants differ in write volume, regions add sites, retention windows change, and backfills compete with live ingestion.
  • The routing contract therefore needs a rebalancing story, not only a first-day shard key.
  • Naive routing can make growth dangerous.
  • Hot keys need the same evidence.

Why it matters

An older ownership update must not win merely because one replica has a fast clock; the authority rule needs stronger justification than arrival order.

iotclass.org

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.

Key terms

CAP analysis
CAP analysis is useful when it names the record class, partition behavior, conflict policy, stale-read rule, and evidence that proves the design under failure.
iotclass.org

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.
  • Step 2, rank the consequence.: Describe what happens if the value is wrong, stale, missing, duplicated, reordered, or accepted in two places.
  • Partition test, rollout dry run, rollback test, owner approval, and audit evidence.
  • Database Categories Are Shortcuts Relational databases, wide-column stores, document databases, event logs, time-series databases, object stores, and caches can all be configured in ways that change partition behavior.
iotclass.org

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 the team ignore partitions because IoT networks are usually reliable enough?
DCan all IoT records use last-write-wins because timestamps exist?
Show answer

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

iotclass.org

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.

iotclass.org

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?

AThe buffered telemetry is automatically correct because it was stored near the device.
BThe availability-first path is not release-ready until replay is defined and tested.
CThe system should silently discard all late data to simplify the database.
DThe only required evidence is that the dashboard loaded once after reconnect.
Show answer

Answer: B 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.

iotclass.org

Retrieval practice

Recall check 4 of 6

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

Q4A team shards IoT telemetry only by the current month. Retention is easy, but all live writes hit the newest time bucket. What is the strongest design concern?

AThe monthly boundary should make the write workload easier to distribute.
BMonth-based routing should reduce shard fan-out for recent fleet summaries.
CThe shard key may create a hot current partition.
DRetention should be removed because sharded systems cannot delete old data.
Show answer

Answer: C A shard key must balance live writes while preserving the queries and lifecycle rules the service needs.

iotclass.org

Retrieval practice

Recall check 5 of 6

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

Q5A 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 by a device-oriented key and keep bounded time buckets inside that route.
BRoute rows randomly across shards to spread ingestion, then merge the results for device-history queries.
CRoute by firmware version and month so rollout cohorts stay together during historical analysis.
DRoute by device alone and use row-by-row deletion for the monthly retention job.
Show answer

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

iotclass.org

Retrieval practice

Recall check 6 of 6

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

Q6A 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?

AThe formula is always safe because modulo arithmetic is simple.
BRebalancing evidence is unnecessary if the dashboard is visually clear.
CAdding more nodes can never affect routing, regardless of the formula.
DChanging the node count may move many keys at once.
Show answer

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

iotclass.org

Print reference

Answers 1 of 2

Answer key.

  1. A · CAP becomes useful when the review names the record class, partition behavior, and release evidence.
  2. C · Different IoT data classes have different consequences, so a single database-category label is not enough.
  3. B · 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.
  4. C · A shard key must balance live writes while preserving the queries and lifecycle rules the service needs.
iotclass.org

Print reference

Answers 2 of 2

Answer key.

  1. A · A strong shard-key design preserves the common query path while keeping lifecycle operations bounded and testable.
  2. D · A production sharding design must prove how ownership changes without corrupting reads, writes, and recovery.
iotclass.org