NoSQL, Multimodel and Specialized Databases

Introduction and Context

Relational database management systems remain essential for transactions, reporting, and structured enterprise data. However, modern applications increasingly process data that is highly connected, rapidly generated, geographically distributed, semi-structured, or too large and variable for an economical relational design. Examples include clickstreams, sensor measurements, social relationships, product catalogs, location traces, fraud networks, and interactive web sessions.

The term NoSQL does not mean “no SQL” in a literal sense. It generally refers to database systems that depart from the relational model in one or more important respects, including schema flexibility, horizontal scaling, specialized access paths, distributed consistency models, or non-tabular data representation. NoSQL systems are not a universal replacement for relational databases. They are design alternatives whose suitability depends on workload, access patterns, consistency requirements, operational skills, and lifecycle costs.

A related development is the multimodel database, which supports more than one data model—such as document, graph, key-value, and relational—within a single platform. Specialized databases focus on a dominant workload, such as time-series analysis, geospatial queries, temporal history, or in-memory processing. Choosing among these systems is therefore a data-engineering and architecture decision rather than a matter of technological fashion.

This chapter develops a comparative framework for selecting these database models. It emphasizes data representation, query behavior, consistency, scalability, maintainability, governance, and practical application.

Learning Objectives

After completing this chapter, a student should be able to:

1. Explain the structures and operational characteristics of key-value, document, wide-column, graph, time-series, spatial, temporal, and in-memory databases.

2. Distinguish data-model flexibility from query flexibility and from scalability.

3. Compare consistency, availability, partition tolerance, performance, and maintainability across database families.

4. Select an appropriate model from workload and access-pattern requirements.

5. Design a polyglot-persistence or multimodel architecture responsibly.

6. Evaluate governance, security, migration, and operational risks in specialized database deployments.

A Selection Framework for Non-Relational Data Platforms

Database selection should begin with the workload rather than the product name. A useful analysis asks the following questions:

• What entities and relationships must be represented?
• Which operations dominate: point lookup, range scan, aggregation, traversal, spatial search, or historical reconstruction?
• Is the data schema stable, evolving, nested, or sparse?
• What are the latency and throughput objectives?
• Must transactions span several records or partitions?
• What consistency guarantees are required?
• How large will the dataset become, and how will it be partitioned?
• What are the retention, archival, and deletion requirements?
• Can the organization operate several database technologies safely?

A central NoSQL principle is access-pattern-oriented modeling. In a relational design, normalization often begins with entities and dependencies, after which queries are written. In many NoSQL systems, the designer begins with known queries and organizes data so that those queries require few distributed operations. This may involve denormalization, embedding, materialized views, or deliberately duplicated data.

The main dimensions of comparison are:

• Data shape: structured, semi-structured, nested, connected, spatial, or temporal.
• Access path: key lookup, indexed field search, ordered scan, graph traversal, or spatial predicate.
• Consistency: strong, causal, session, eventual, or application-managed consistency.
• Scaling: vertical scaling, partitioning, replication, or elastic horizontal scaling.
• Operational complexity: backup, monitoring, repair, schema evolution, and recovery.
• Maintainability: understandability, testing, migration effort, and availability of expertise.

The CAP theorem is relevant when a distributed system experiences a network partition. A system cannot simultaneously guarantee both availability and strong consistency for all operations during such a partition. CAP does not state that a system must permanently choose only two properties, nor does it replace detailed consistency analysis. Real systems often provide tunable consistency, different guarantees for different operations, or stronger behavior within a partition and weaker behavior across regions.

Key-Value Databases

A key-value database stores an opaque value associated with a unique key. The value may be a string, binary object, serialized document, counter, or application-specific structure. Typical operations include `GET`, `PUT`, and `DELETE`.

The model is highly effective when the application already knows the lookup key. Common uses include sessions, shopping carts, feature flags, authentication tokens, caches, user preferences, and idempotency records. Distributed hash partitioning can provide high throughput and horizontal scaling.

The principal advantage is operational simplicity for point access. Many systems also provide expiration times, atomic counters, compare-and-set operations, replication, and transactions limited to a partition or key range. The principal limitation is weak ad hoc query capability. If the application needs to find values by arbitrary attributes, perform joins, or traverse relationships, the key-value model may require secondary indexes or a separate search system.

A key-value design should define key construction carefully. Keys should distribute evenly across partitions, avoid accidental hotspots, and remain stable during schema evolution. A timestamp prefix, for example, may concentrate current writes on one partition; a suitable hashing or bucketing strategy can reduce this risk. However, excessive randomization may make range retrieval difficult. Key design is therefore a compromise between distribution and query locality.

Document Databases

A document database stores records as JSON-like documents, commonly containing nested objects and arrays. Documents represent an aggregate: a group of information commonly read or updated together. A customer document might contain contact information, preferences, and addresses; an order document might contain line items and delivery details.

Document databases support flexible or semi-flexible schemas. This is useful when attributes vary between records or evolve rapidly. Embedding related information can reduce joins and improve read performance. For example, order line items can be embedded in an order when they are normally retrieved with that order.

Embedding is not always appropriate. If an embedded array grows without bound, if its elements are independently queried, or if many documents must reflect the same frequently changing entity, referencing or separate collections may be preferable. Duplication improves read locality but creates update and consistency obligations.

Document systems commonly provide indexes on fields, compound indexes, array elements, and sometimes full-text or geospatial fields. They are suitable for content management, catalogs, profiles, event records, configuration, and mobile or web applications. Their limitations include expensive cross-document joins, possible document-size constraints, index overhead, and the risk that schema flexibility becomes uncontrolled structural inconsistency.

Schema flexibility does not mean the absence of design. Production systems should define validation rules, version documents, document ownership boundaries, migration procedures, and compatibility policies. A schema registry or application-level validation can prevent a collection from becoming an unmanageable mixture of historical formats.

Wide-Column Databases

Wide-column databases organize data into rows identified by a partition key, with columns grouped or stored in a sparse, distributed structure. The term covers systems with differing architectures, so the exact semantics of a particular product must be studied. A common design pattern separates a partition key, which determines data placement, from clustering columns, which determine ordering within a partition.

Wide-column systems are designed for large-scale write and read workloads distributed across many nodes. They are especially effective for known query patterns such as “retrieve all measurements for device X during a time interval” or “retrieve messages for account Y in reverse chronological order.” Data is commonly modeled separately for each important query, and duplication is expected.

The partition key is critical. A partition that is too large harms storage, repair, and query performance; a partition key with low cardinality can create a hotspot. Time bucketing, such as one partition per device per day or month, can bound partition size. The correct bucket depends on ingestion rate, retention, query ranges, and operational limits.

Wide-column systems often favor availability and throughput over multi-row serializable transactions. They may support lightweight conditional updates or limited transactional features, but they are not generally substitutes for relational systems requiring complex joins and broad ACID transactions. Their strengths are predictable access patterns, horizontal scale, and high write rates; their weaknesses include difficult ad hoc querying, denormalized maintenance, and a steep operational learning curve.

Graph Databases

A graph database represents entities as vertices and relationships as edges. Both may have properties. The model is natural when the meaning of the data depends on connections, paths, neighborhoods, or network structure.

Typical applications include social networks, recommendation engines, identity resolution, supply-chain dependencies, fraud analysis, knowledge graphs, and network topology. Queries such as “find friends of friends,” “identify suspicious cycles,” or “find all suppliers connected to a restricted organization within three steps” are graph-oriented.

Graph databases generally support either property graphs, RDF triples, or both. Property-graph query languages commonly express pattern matching and traversals, whereas RDF systems emphasize triples, ontologies, and semantic-web standards. These approaches overlap but are not identical.

Graphs avoid the repeated join chains that can make highly connected relational queries complex and expensive. Their performance depends on traversal depth, branching factor, indexing, graph locality, and workload concurrency. A graph database is not automatically superior for every relationship. A small, stable relationship set may be efficiently represented relationally. Graph technology is most compelling when relationships are first-class data and traversal is central to the workload.

Graph designs must address identity, duplicate entities, relationship validity, directionality, temporal changes, and authorization. A fraud graph, for example, should distinguish a confirmed relationship from a merely inferred one and should preserve the evidence and time interval supporting the inference.

Time-Series Databases

A time-series database is optimized for observations associated with timestamps. Examples include temperature, CPU utilization, financial prices, industrial telemetry, application metrics, and energy consumption. Such systems commonly optimize append-heavy ingestion, time-window retrieval, compression, downsampling, retention, and aggregations.

A measurement usually has a timestamp, one or more values, and dimensions or tags such as device, region, or service. Tags identify series, while values represent observations. The distinction matters because high-cardinality tags—such as a unique identifier for every request—can increase index and memory costs.

Time-series systems often support retention policies, continuous aggregates, late-arriving data handling, and functions such as moving averages or rate calculations. Time bucketing is central to both storage and query design. A query for the last hour should not require scanning years of raw data.

Time is not always simple. Systems must define timestamp precision, clock source, time zones, daylight-saving behavior, out-of-order events, duplicate observations, and correction policies. Event time—the time an event occurred—may differ from ingestion time. Analytics based on event time should handle delayed arrival explicitly.

Time-series databases are excellent for operational monitoring and telemetry but may not be ideal for complex entity transactions or arbitrary relational queries. They are often combined with object storage for inexpensive long-term retention and with stream-processing systems for real-time computation.

Spatial Databases

Spatial databases represent points, lines, polygons, rasters, and other geometric or geographic objects. They support operations such as containment, intersection, distance, nearest-neighbor search, and spatial joins.

A spatial design must distinguish a coordinate reference system from the geometry itself. Latitude and longitude are angular coordinates, not a uniform planar distance system. Distance calculations over a large geographic area may require a geographic or geodesic model rather than treating degrees as equal linear units.

Spatial indexes, including grid, tree-based, and space-partitioning structures, reduce the number of candidate objects examined. Queries frequently use a two-stage process: an index performs a bounding approximation, followed by an exact geometric predicate. The application must also define boundary semantics, such as whether an object touching a polygon boundary is considered inside.

Applications include logistics, urban planning, environmental monitoring, emergency response, real-estate search, telecommunications, and location-based services. Spatial data introduces governance concerns because location can reveal sensitive personal behavior. Collection, precision, retention, and access should be minimized according to purpose.

Temporal Databases

Temporal databases preserve the time dimension of facts. Two important concepts are:

• Valid time: the period during which a fact is true in the modeled world.
• Transaction time: the period during which the database stores or knows the fact.

A system may support one or both dimensions. A price may be valid from 1 January, although the organization records it on 5 January. If the original price is later corrected, transaction time preserves what was recorded and when, while valid time describes the business reality.

Temporal modeling is valuable for auditing, regulatory reporting, historical analysis, slowly changing dimensions, contracts, employment records, and financial data. It supports questions such as “What was believed on a particular date?” and “What price was valid for this customer at the time of purchase?”

Temporal correctness requires explicit interval conventions. Designers must decide whether intervals are closed, open, or half-open, how adjacent intervals are handled, and how overlaps are prevented. A common approach is a half-open interval [start, end), in which the start is included and the end excluded. This avoids ambiguity when one period ends exactly as another begins. Temporal tables can grow rapidly, so partitioning, archival, indexing, and retention policies are important.

In-Memory Databases

In-memory databases keep active data primarily in RAM to reduce access latency. They may be key-value stores, relational systems, data grids, or caches. Many provide persistence through snapshots, logs, replication, or combinations of these mechanisms.

In-memory processing is useful for session state, caching, real-time dashboards, high-frequency counters, gaming, recommendation features, and low-latency transaction components. It can reduce disk latency, but it does not eliminate network latency, serialization cost, lock contention, or application inefficiency.

The major risk is durability. If data exists only in volatile memory, a process or machine failure can cause loss. Persistence configuration must therefore match business requirements. A cache may tolerate loss because the authoritative database can repopulate it; a payment ledger cannot.

Memory cost is another constraint. Eviction policies, object overhead, fragmentation, replication, and working-set size must be considered. An in-memory database should not be selected merely because an application is “fast”; the design should identify the latency objective, data criticality, recovery point objective, and recovery time objective.

Multimodel Databases and Polyglot Persistence

A multimodel database supports multiple representations and query styles in one platform. It may allow a document to be queried relationally, a graph to be traversed, and key-value operations to be performed against the same underlying data. The attraction is reduced data movement, a unified security model, fewer operational platforms, and the possibility of using the best model for each access pattern.

A multimodel platform can also create conceptual and operational complexity. Different models may have different transaction semantics, indexing behavior, optimization quality, and maturity. A product that technically supports five models may provide excellent support for only two. Teams should evaluate query expressiveness, execution plans, backup behavior, monitoring, migration tooling, and vendor dependence.

Polyglot persistence uses multiple purpose-built databases in one architecture. For example, a system may use a relational database for orders, a document store for catalog content, a graph database for recommendations, and a time-series system for telemetry. This can produce better workload fit but introduces data synchronization, distributed tracing, duplicated governance, and additional skills requirements.

The choice between multimodel and polyglot persistence should be explicit. A single platform is not automatically simpler, and many platforms are not automatically more capable. A bounded-context architecture can clarify ownership: each data store has a system of record, defined APIs, synchronization mechanisms, and recovery procedures.

Consistency, Transactions, and Distributed Design

Consistency should be specified at the level of business outcomes. Strong consistency may be essential when two users must not purchase the same unique asset. Eventual consistency may be acceptable for a social-media follower count or a search index that can lag briefly. Causal consistency can preserve the order users expect, such as seeing a comment after the post that created it.

Important mechanisms include:

• Replication: maintaining copies for availability and read scalability.
• Quorum operations: requiring agreement from a selected number of replicas; exact guarantees depend on the system’s protocol and failure model.
• Conflict resolution: using timestamps, versions, application rules, or conflict-free data structures.
• Idempotency: making repeated requests produce the same intended effect, which is essential during retries.
• Sagas: coordinating a business process through local transactions and compensating actions rather than one global transaction.

Denormalization and asynchronous propagation require observability. Systems should expose replication lag, failed events, reconciliation results, and data-quality exceptions. Without these controls, eventual consistency becomes invisible inconsistency.

Modeling and Maintainability Practices

A robust design typically follows these practices:

1. Begin with business operations and measurable service-level objectives.

2. Identify the system of record for every important fact.

3. Model partitions, keys, indexes, and retention before loading production data.

4. Test realistic distributions, including hotspots and skew.

5. Define schema versions and backward-compatible rollout procedures.

6. Minimize unbounded arrays, partitions, indexes, and graph traversals.

7. Separate authoritative data from caches, projections, and analytics copies.

8. Automate backups, restore testing, capacity alerts, and security configuration.

9. Monitor latency percentiles rather than only averages.

10. Document consistency guarantees and failure behavior for application developers.

Maintainability is a technical property. A theoretically fast database that requires rare expertise, complex repairs, or undocumented data pipelines may have a higher total cost than a slower but understandable alternative.

Illustrative Case: A Smart-City Mobility Platform

Background

Consider a fictional metropolitan mobility platform that combines buses, trains, bicycles, and ride-sharing services. It receives vehicle telemetry every few seconds, stores passenger accounts and payments, offers route searches, displays nearby vehicles, and investigates service disruptions.

Problem

A single relational database has become a bottleneck. Telemetry ingestion competes with passenger transactions, route searches require spatial calculations, and investigators need to trace connections among vehicles, accounts, devices, and payment events. Historical analysis also requires retaining several years of observations.

Analysis

The workloads are heterogeneous:

• Payments and account changes require strong transactional guarantees.
• Telemetry is append-heavy and naturally time-oriented.
• Nearby-vehicle searches require spatial indexing.
• Investigation requires relationship traversal.
• Frequently accessed vehicle status requires low-latency reads.

No single data model is optimal for all operations. The organization also has a small operations team, so platform count must be controlled.

Approach

The platform adopts bounded polyglot persistence:

• A relational database remains the system of record for accounts, payments, and settlement.
• A time-series store receives vehicle telemetry, with retention and downsampling policies.
• A spatially indexed service maintains current vehicle locations and supports nearest-vehicle queries.
• A graph projection stores identity and event relationships for investigative analysis. It is explicitly treated as a derived projection, not the authoritative payment ledger.
• An in-memory store caches current vehicle status and short-lived route results.
• An event stream propagates approved changes and records failures for replay.

Each projection has an owner, versioned event contract, rebuild procedure, and freshness objective. Location data is restricted, retained only as long as operationally justified, and access is audited.

Outcome

Payment processing is isolated from telemetry volume, route searches use appropriate spatial indexes, and investigators can explore relationships without imposing traversal workloads on the payment database. The design introduces operational complexity, but this is controlled through automation, observability, disaster-recovery exercises, and explicit source-of-truth rules.

Learning Points

The case demonstrates that model selection should follow workload boundaries. Derived stores can improve performance, but they must not silently become competing sources of truth. Data synchronization, privacy, and recovery are as important as query speed.

Challenges, Governance, and Contemporary Developments

NoSQL and specialized systems create several risks. Denormalization can produce stale copies. Flexible schemas can hide quality problems. Distributed databases can make failure recovery and capacity planning difficult. Vendor-specific query languages can increase migration costs. Managed cloud services reduce infrastructure administration but may create dependence on proprietary features and pricing models.

Security must include authentication, authorization, encryption in transit and at rest, secret management, network segmentation, audit logging, and secure backup handling. Fine-grained authorization is particularly important in graph, spatial, and temporal systems because combining records can reveal sensitive relationships or movements.

Privacy regulations may require purpose limitation, data minimization, retention control, correction, deletion, and auditable processing. Immutable event stores and temporal histories must be designed so that legal obligations can be addressed without destroying necessary integrity evidence. Access to location, identity graphs, and behavioral histories should be risk-assessed.

Contemporary development includes cloud-native distributed databases, serverless data services, vector search, streaming integration, lakehouse architectures, and database support for machine-learning workloads. Vector indexes can support semantic retrieval, but they do not replace authoritative transactional or relational structures. AI-generated data and retrieval systems also require provenance, access control, evaluation for bias, and protection against unauthorized disclosure.

Decision Matrix

| Requirement | Usually suitable model | Main caution |

|---|---|---|

| Exact lookup by known identifier | Key-value | Limited ad hoc querying |

| Nested, evolving application records | Document | Schema drift and duplication |

| Massive predictable distributed workload | Wide-column | Difficult joins and key design |

| Relationship traversal and network analysis | Graph | Traversal explosion and identity quality |

| Timestamped append and window analytics | Time-series | High-cardinality dimensions |

| Location predicates and distance search | Spatial | Coordinate and privacy issues |

| Auditable historical states | Temporal | Storage growth and interval semantics |

| Very low-latency active state | In-memory | Durability and memory cost |

| Several models with shared platform | Multimodel | Uneven feature maturity and lock-in |

The matrix is a starting point, not a final decision. Benchmarking should use representative data volume, skew, concurrency, failure conditions, and recovery operations. A benchmark that measures only ideal reads provides weak evidence.

Chapter Summary

NoSQL databases provide alternative models for workloads that are not well served by a single normalized relational design. Key-value systems optimize known lookups; document databases represent nested and evolving aggregates; wide-column systems support distributed, predictable high-volume access; graph databases make relationships and traversal central; time-series databases optimize timestamped observations; spatial databases support geometric and geographic operations; temporal databases preserve historical truth and knowledge; and in-memory databases reduce latency for active state.

Multimodel databases consolidate several representations, while polyglot persistence combines purpose-built stores. Both approaches require explicit ownership, consistency, synchronization, governance, and recovery policies. The correct selection depends on access patterns, data shape, consistency, scale, latency, retention, operational capability, and maintainability—not on novelty or benchmark claims alone.

A mature architecture separates systems of record from caches and projections, tests realistic workload distributions, documents consistency guarantees, protects sensitive data, and validates disaster recovery. Specialized databases are most valuable when their specialized behavior corresponds directly to a dominant business requirement.

Key Terms

NoSQL: A family of non-relational database approaches emphasizing flexible models, distributed operation, or specialized access patterns.

Key-value database: A database that stores values addressed by unique keys.

Document database: A database storing JSON-like, semi-structured documents.

Wide-column database: A distributed database organized around partitioned rows and sparse or grouped columns.

Graph database: A database representing entities as vertices and relationships as edges.

Time-series database: A database optimized for timestamped observations and time-window analysis.

Spatial database: A database supporting geometric objects and geographic predicates.

Temporal database: A database that models the time dimensions of facts.

Valid time: The period during which a fact is true in the modeled world.

Transaction time: The period during which a fact is stored or known by the database.

In-memory database: A database that keeps active data primarily in RAM.

Multimodel database: A platform supporting multiple data models.

Polyglot persistence: The use of multiple database technologies in one architecture.

Denormalization: Deliberate duplication or restructuring of data to improve access performance.

Partition key: The value used to determine data distribution across nodes or partitions.

Eventual consistency: A guarantee that replicas converge if updates cease and communication continues.

Idempotency: The property that repeating an operation produces the same intended result.

Materialized projection: A derived data representation maintained for a particular query or workload.

Schema evolution: The controlled modification of data structure over time.

Review Questions

Short Answer Questions

1. What is the main access-pattern advantage of a key-value database?

2. Why can embedding be useful in a document database?

3. Distinguish valid time from transaction time.

4. State two common uses of a time-series database.

5. What is polyglot persistence?

Long Answer Questions

1. Compare document and wide-column databases in terms of data modeling, scaling, querying, and maintainability.

2. Explain why graph databases are useful for relationship-intensive workloads, and discuss their limitations.

3. Discuss consistency choices in distributed NoSQL systems, including eventual consistency, idempotency, and sagas.

4. Explain the design issues involved in spatial databases, including coordinate systems, indexing, and privacy.

5. Evaluate the advantages and risks of multimodel databases compared with polyglot persistence.

Analytical / Application Questions

1. A platform must store customer profiles with evolving attributes, retrieve profiles by identifier, and occasionally search by several profile fields. Which database model would you recommend, and what validation and indexing controls would you apply?

2. A utility receives millions of meter readings daily and must answer queries for one meter over selected time windows while retaining monthly summaries for ten years. Design a time-series storage and retention strategy.

3. An organization needs payment integrity, real-time device status, location-based search, and fraud-network analysis. Propose a database architecture, identify each system of record, and explain how synchronization and governance would be managed.

Multiple Choice Questions with Answers

Question 1

Which workload is most naturally suited to a key-value database?

A. Finding all suppliers connected through several relationship paths

B. Retrieving a user session when its unique session key is known

C. Calculating geometric intersections between land parcels

D. Reconstructing all historical versions of a contract

Correct Answer: B. Retrieving a user session when its unique session key is known

Question 2

What is a major reason for embedding data in a document database?

A. To ensure every document has an identical fixed schema

B. To eliminate the need for all indexes

C. To keep information commonly read together in one aggregate

D. To guarantee serializable transactions across all collections

Correct Answer: C. To keep information commonly read together in one aggregate

Question 3

In a wide-column database, what is the primary purpose of a partition key?

A. To determine how data is distributed across partitions or nodes

B. To define the legal retention period of each row

C. To convert relational tables into graph edges

D. To encrypt every column independently

Correct Answer: A. To determine how data is distributed across partitions or nodes

Question 4

Which query is most characteristic of a graph database?

A. Retrieve a document by its primary identifier

B. Compute the average temperature during one hour

C. Find entities connected through paths of up to three relationships

D. Select records whose polygon intersects a boundary

Correct Answer: C. Find entities connected through paths of up to three relationships

Question 5

What distinction is correct in temporal database terminology?

A. Valid time records storage location; transaction time records geographic location

B. Valid time describes when a fact is true; transaction time describes when it is stored or known

C. Valid time applies only to graphs; transaction time applies only to documents

D. Valid time and transaction time always have identical values

Correct Answer: B. Valid time describes when a fact is true; transaction time describes when it is stored or known

Question 6

Which characteristic is especially important when designing time-series dimensions?

A. Avoiding all timestamps

B. Controlling high-cardinality tags

C. Replacing every measurement with a graph edge

D. Using unbounded partitions for convenience

Correct Answer: B. Controlling high-cardinality tags

Question 7

Why should latitude and longitude not automatically be treated as uniform linear coordinates?

A. They are angular coordinates and distance behavior varies geographically

B. They cannot be indexed

C. They can represent only polygons

D. They are valid only in temporal databases

Correct Answer: A. They are angular coordinates and distance behavior varies geographically

Question 8

What is a principal risk of an in-memory database used as the sole store for critical data?

A. It cannot perform point lookups

B. It necessarily prevents replication

C. Volatile memory loss may compromise durability

D. It cannot support expiration policies

Correct Answer: C. Volatile memory loss may compromise durability

Question 9

Which statement best describes polyglot persistence?

A. Using only relational tables with multiple schemas

B. Using multiple database technologies, each selected for a workload or bounded context

C. Storing every data type in one unindexed document

D. Converting all database records into key-value pairs

Correct Answer: B. Using multiple database technologies, each selected for a workload or bounded context

Question 10

In the illustrative mobility case, which store was treated as the system of record for payments?

A. The graph projection

B. The in-memory cache

C. The time-series store

D. The relational database

Correct Answer: D. The relational database