4. Requirements Analysis and Technology SelectionIntroduction and ContextChoosing a NoSQL database is not primarily a matter of selecting the product with the highest benchmark score or the newest feature set. It is a requirements-analysis problem. A database is successful when it supports the organization’s business objectives, user journeys, data characteristics, access patterns, service-level objectives, governance obligations, and financial constraints over its expected life. A technically impressive system may still be a poor choice if it is difficult to operate, incompatible with organizational skills, expensive at production scale, or unable to satisfy compliance requirements. In full stack development, database decisions influence application architecture, API design, deployment models, testing, observability, security, and long-term maintenance. The choice between a document database, key–value store, wide-column database, graph database, search-oriented system, or a relational database with selected NoSQL capabilities should therefore be made systematically. NoSQL is not a universal replacement for relational technology. It is a family of approaches that often provides advantages for flexible schemas, horizontal scaling, high-throughput workloads, geographically distributed applications, or relationship-focused data. This chapter presents a strategic method for translating business language into database requirements and then evaluating candidate technologies. It emphasizes traceable decisions rather than fashionable choices. The central principle is simple: select the technology that offers the best overall fit for the workload and organization, not the technology that appears strongest in isolation. Learning ObjectivesAfter studying this chapter, students should be able to: - translate business goals and user journeys into measurable data requirements;
- identify entities, data characteristics, access patterns, consistency needs, and lifecycle rules;
- distinguish functional requirements from non-functional and operational requirements;
- relate workload requirements to NoSQL data models and architectural patterns;
- define service-level objectives for availability, latency, durability, recovery, and scalability;
- compare database products using fit, maturity, skills, compliance, cost, and vendor-lock-in criteria;
- construct a weighted technology-selection matrix and explain its limitations;
- recognize risks, governance obligations, and common mistakes in database selection; and
- recommend a database strategy with explicit assumptions, trade-offs, and validation steps.
From Business Goals to Data RequirementsRequirements analysis begins with the business outcome rather than the database. A statement such as “build a responsive marketplace” is too broad to guide technology selection. It must be decomposed into capabilities and user journeys. For example, a marketplace may need product discovery, seller catalog management, cart management, payment processing, order tracking, recommendations, and operational reporting. Each capability creates different data behavior. A useful chain of reasoning is: business goal → capability → user journey → data operation → workload requirement → technology implication Suppose the business goal is to increase completed purchases. A relevant user journey may be: a customer searches for a product, views product details, adds an item to a cart, submits an order, and receives confirmation. This journey implies operations such as text or faceted search, low-latency product retrieval, cart updates, inventory validation, order creation, and event publication. These operations have different consistency, latency, and durability requirements. Treating them as one undifferentiated database workload often produces a poor design. Functional and Non-Functional RequirementsFunctional requirements describe what the data system must do. Examples include: - store and retrieve customer profiles;
- retrieve a product by identifier;
- list all orders for a customer in reverse chronological order;
- update a shopping cart;
- identify all devices associated with an account; and
- record an immutable payment event.
Non-functional requirements describe how the system must behave. Important categories include performance, availability, scalability, durability, security, recoverability, operability, portability, and cost. A functional requirement may state that an order must be stored. A non-functional requirement may state that confirmed orders must not be lost, must be readable within two seconds, and must remain available during the loss of one availability zone. Requirements should be written in measurable terms wherever possible. “Fast search” is weak; “95 percent of product-detail reads complete within 150 milliseconds at the expected peak load” is more useful. “Highly available” should be translated into a target such as 99.95 percent monthly availability, together with a definition of which operations are covered. User Journeys and Workload NarrativesUser journeys reveal the sequence and priority of data operations. Analysts should document the actor, trigger, steps, data read or written at each step, expected frequency, failure consequences, and security context. A journey for account recovery differs substantially from one for real-time vehicle tracking. The former may be infrequent but security-sensitive; the latter may involve continuous high-volume writes and time-based retrieval. Workload narratives should include both normal and exceptional behavior. A flash sale, examination-results release, public-service registration deadline, or promotional campaign may create short periods of extreme demand. A database selected using only average traffic can fail during these peaks. Similarly, rare operations such as disaster recovery, legal discovery, data export, or schema migration may have major strategic significance despite low frequency. The Analytical Vocabulary of Database RequirementsSeveral concepts provide a common language for requirements analysis. Data entities and aggregates. An entity is a recognizable business object, such as Customer, Order, Device, or Course. An aggregate is a group of related data treated as a unit for access and update. In a document model, an order and its line items may form one aggregate because they are commonly read together and have a shared lifecycle. Aggregate boundaries influence partitioning, transaction scope, and API design. Access pattern. An access pattern specifies how data is read, written, filtered, sorted, or traversed. Examples include lookup by identifier, range query by timestamp, retrieval of a customer’s recent orders, membership testing, graph traversal, and aggregation by geographic region. NoSQL modeling is frequently access-pattern-driven: the data structure is designed around important queries rather than normalized independently of them. Read/write ratio. A workload may be read-heavy, write-heavy, or balanced. Product catalogs are often read-heavy, whereas telemetry ingestion may be write-heavy. The ratio alone is insufficient; write size, burstiness, concurrency, and query complexity also matter. Cardinality and selectivity. Cardinality describes the number of distinct values in a field or relationship. Selectivity describes how effectively a condition narrows a result set. A query on a unique customer identifier is highly selective, while a query for all records with status “active” may be less selective. These properties affect indexing, partitioning, and query performance. Data velocity, volume, and variety. Volume concerns the amount of stored data; velocity concerns the rate of creation and change; variety concerns differences in structure and representation. These dimensions are useful, but they must be connected to actual workload measurements. “Big data” is not a sufficient justification for NoSQL. Hot key or hot partition. A hot key receives disproportionate traffic, causing one partition or node to become overloaded. Examples include a globally popular livestream, a single promotional product, or a counter updated by every client. Avoiding hot spots may require key design, sharding, caching, or an alternative data model. Consistency. Consistency concerns what values clients can observe and when. Strong consistency generally means that a successful read reflects the latest completed write within the defined scope. Eventual consistency permits temporary divergence while replicas converge. Other models include session consistency, causal consistency, and bounded staleness. Consistency is not simply “good” or “bad”; it is a business decision. Idempotency. An operation is idempotent if repeating it produces the same intended result as performing it once. Idempotent commands are valuable when networks fail and clients retry requests. For example, assigning a payment status using a unique transaction identifier can be safer than blindly incrementing a payment counter. Denormalization. Denormalization stores related or repeated data to optimize particular reads. It can reduce joins and latency but creates duplication and update-propagation responsibilities. Denormalization is appropriate only when the team understands which copy is authoritative and how stale copies are repaired. Partition key and sort key. In distributed stores, a partition key determines data placement, while a sort or clustering key orders records within a partition. A well-designed key distributes load and supports required queries. A key that is unique but unrelated to query behavior may distribute writes well while making retrieval inefficient. Polyglot persistence. Polyglot persistence uses multiple data technologies, each selected for a particular workload. A service may use a document store for catalog data, a key–value store for sessions, a search engine for discovery, and a relational database for financial transactions. This approach can improve fit but increases operational and integration complexity. A Requirements-Analysis WorkflowEstablish the Decision BoundaryBefore comparing products, define what is being selected. The decision may concern one database for an entire system, a database for a single bounded context, a managed cloud service, or a self-hosted platform. The decision boundary should state the applications, data domains, environments, geographic regions, and time horizon involved. A product that is unsuitable for an organization-wide standard may be excellent for one isolated service. Stakeholders should include product owners, developers, data architects, operations engineers, security and compliance specialists, finance representatives, and, where relevant, legal or records-management personnel. Each stakeholder sees different constraints. Excluding operations from selection often results in a system that developers can build but nobody can reliably run. Inventory Data Domains and LifecyclesCreate a domain inventory describing the owner, sensitivity, retention period, source of truth, expected size, growth rate, and consumers of each data domain. Data should be classified according to organizational policy, such as public, internal, confidential, or highly restricted. Personally identifiable information, health information, payment data, educational records, and location data may be subject to additional controls. Lifecycle analysis is equally important. Some data is continuously updated; some is append-only; some expires after a short period; and some must be retained for many years. Time-to-live functions, archival tiers, compaction, deletion guarantees, legal holds, and audit requirements may affect product suitability as much as query performance. Document Access PatternsFor each important operation, record: - the operation type: read, insert, update, delete, scan, aggregation, or traversal;
- the keys and filters used;
- expected result size;
- ordering and pagination requirements;
- read and write frequency;
- peak concurrency and burst behavior;
- freshness and consistency requirements;
- transaction scope; and
- consequences of delay or failure.
A practical technique is to create an access-pattern table. For example, “retrieve the latest 20 orders for a customer” may require a customer identifier, descending time order, cursor-based pagination, and a response within 200 milliseconds. “Generate annual revenue by region” may be better handled by an analytical store or pipeline rather than a transactional NoSQL database. Quantify the WorkloadEstimate current and future data size, average and peak requests per second, payload size, concurrent clients, growth rate, read/write ratio, and geographic distribution. Use ranges rather than false precision. A five-year estimate should state assumptions about users, events per user, retention, and traffic growth. Capacity planning should account for replication, indexes, compaction overhead, backups, temporary migration space, and headroom for peaks. Storage capacity is not equivalent to usable capacity. A system storing three replicas of data and several indexes may require substantially more physical capacity than the logical dataset suggests. Define Service-Level ObjectivesA service-level objective (SLO) is a target for a measurable aspect of service behavior. Common database SLOs include: - availability for reads and writes;
- latency percentiles, especially p95, p99, and p99.9;
- durability and acceptable data-loss exposure;
- recovery time objective (RTO);
- recovery point objective (RPO);
- replication lag or freshness;
- throughput during normal and peak periods; and
- time required to scale, restore, patch, or fail over.
Percentiles are preferable to averages because averages hide tail latency. A system with a 50-millisecond average may still produce unacceptable delays for a significant minority of requests. SLOs should also specify measurement boundaries. “99.9 percent availability” is incomplete unless it identifies whether it covers the database endpoint, a complete transaction, or the entire user journey. RTO is the maximum acceptable time to restore service after a disruption. RPO is the maximum acceptable amount of data, measured in time, that may be lost. A payroll system and a disposable recommendation cache should not have identical RPO requirements. Map Requirements to Data ModelsThe data model should follow dominant access patterns while preserving business invariants. A document model is often appropriate for hierarchical, aggregate-oriented data with variable attributes. A key–value model suits direct lookups, sessions, tokens, and simple state. A wide-column model can support very high-volume distributed writes and predictable key-based queries. A graph model is useful when relationships and traversals are central, such as dependency analysis or fraud networks. Search-oriented technologies support text analysis, relevance ranking, and faceted retrieval, but they should not automatically be treated as the authoritative transactional store. The model must also account for update behavior. Embedding related data can make reads efficient, but large frequently changing embedded structures may create contention or excessive write cost. Referencing data can reduce duplication but may require multiple reads or application-level joins. The correct choice depends on access frequency, consistency needs, aggregate size, and lifecycle coupling. Technology Selection as a Multi-Criteria DecisionTechnology selection is a constrained decision under uncertainty. A useful evaluation framework combines six dimensions: workload fit, product maturity, organizational capability, compliance and governance, total cost, and strategic flexibility. Workload FitWorkload fit asks whether the technology can satisfy required queries, transactions, consistency behavior, scaling pattern, availability topology, and data lifecycle. It should be assessed using representative workloads rather than product demonstrations. A candidate that supports a query syntactically may still perform poorly at realistic cardinality and concurrency. Important questions include: - Can the required access patterns be served without unbounded scans?
- Are atomic operations available at the required aggregate or partition scope?
- Can the system distribute data without hot partitions?
- Does it support the required regions, replicas, backups, and failover behavior?
- Can indexes, secondary queries, and aggregations remain affordable at scale?
- Are schema evolution and migrations practical?
Maturity and EcosystemMaturity includes release history, documentation quality, stability, security response, support channels, driver quality, tooling, upgrade procedures, and the availability of production references. A young technology may offer valuable innovation but carry greater uncertainty. Maturity does not mean that an old product is automatically superior; it means that the organization can assess evidence about operational behavior. Evaluate the product and the service separately. A managed offering may simplify patching, backups, monitoring, and failover, while a self-managed deployment may provide greater control or portability. Managed services still require capacity planning, cost governance, security configuration, and exit planning. Skills and Operating ModelA database must be operated by people with the necessary skills. Assess developer familiarity with the data model, query language, consistency model, indexing, backup and restore, observability, incident response, and performance tuning. Training can reduce a skills gap, but it has a cost and does not eliminate operational risk immediately. Selection should align with the organization’s operating model. A small team may prefer a managed service with integrated automation. A regulated enterprise may require dedicated operational control, formal change management, and specialized support. The question is not merely “Can we build with it?” but “Can we secure, monitor, troubleshoot, upgrade, and recover it at two o’clock in the morning?” Compliance, Security, and GovernanceDatabase selection must support identity integration, least privilege, encryption in transit and at rest, key management, network isolation, audit logging, backup protection, data residency, retention, deletion, and incident investigation. Compliance is not a feature that can be added at the end. The selected architecture must make required controls feasible and auditable. Data sovereignty may restrict where data is stored or processed. A globally distributed service may improve latency while creating cross-border transfer obligations. Similarly, replication can improve availability but increase the number of locations containing sensitive data. Governance must cover both primary data and derived copies such as caches, search indexes, analytics exports, backups, and test datasets. Total Cost of OwnershipTotal cost of ownership (TCO) includes more than the advertised storage or request price. It may include compute, storage, replicas, indexes, network transfer, backups, monitoring, support, licensing, personnel, training, migration, testing, downtime risk, and exit costs. Cost models based on requests can be difficult to predict when access patterns are inefficient or traffic is bursty. A useful analysis compares several workload scenarios: expected, optimistic growth, peak demand, and failure or recovery conditions. Cost should be evaluated over the intended decision horizon, such as three to five years, while recognizing that estimates remain uncertain. A cheap initial deployment may become expensive if it requires extensive custom tooling or specialist operations. Vendor Lock-In and PortabilityVendor lock-in is the difficulty or cost of changing provider, product, or deployment model. Lock-in is not always unacceptable. A proprietary capability may deliver sufficient business value to justify dependence. The strategic requirement is informed lock-in rather than accidental lock-in. Assess portability at several levels: data export, schema and query translation, application drivers, operational procedures, identity integration, observability, and staff skills. Open formats and well-defined domain interfaces can reduce migration effort, but they do not guarantee portability. A database may export data easily while application logic depends heavily on proprietary consistency, indexing, or stream features. A Weighted Decision FrameworkA weighted decision matrix makes assumptions visible. First define criteria and assign weights whose total is 100 percent. For example, workload fit might receive 30 percent, availability and performance 15 percent, security and compliance 15 percent, operational maturity 15 percent, skills and ecosystem 10 percent, TCO 10 percent, and portability 5 percent. The weights must reflect business priorities; they are not universal truths. Each candidate is scored using a defined scale, such as 1 to 5, supported by evidence. The weighted score is calculated as: overall score = sum of (criterion weight × candidate rating) A candidate should also be rejected if it fails a mandatory requirement, even when its weighted score is high. For instance, failure to meet data-residency obligations cannot be compensated for by a low price. Sensitivity analysis should then test whether small changes in weights alter the recommendation. If they do, the decision is fragile and requires more evidence. The matrix is a decision aid, not a substitute for engineering judgment. Ratings can conceal uncertainty, bias, or incomparable evidence. Each rating should therefore include an evidence note: documentation, benchmark, proof of concept, reference architecture, or operational experience. Validation Through Prototyping and BenchmarkingA proof of concept should represent the real workload. It should use realistic data distributions, document sizes, indexes, concurrency, failure behavior, geographic topology, and query sequences. Synthetic tests that use uniform keys and small datasets may miss hot partitions, skewed access, index growth, compaction effects, and tail latency. A credible validation plan includes: 1. representative data generation and retention rules; 2. baseline measurements for throughput, latency percentiles, and resource use; 3. tests for normal, peak, and recovery workloads; 4. failure injection, including node, zone, network, and dependency failures; 5. backup restoration and point-in-time recovery tests; 6. security and audit verification; 7. schema evolution and migration exercises; and 8. cost projection from measured consumption. Benchmark results should be interpreted carefully. An artificial benchmark may answer “Which system is faster for this operation?” but not “Which system is safer and more economical for our complete service?” Performance must be considered alongside correctness, operability, and recovery. Illustrative Case: Selecting a Database for a National Learning PlatformBackgroundThe following is an illustrative case. A national learning platform serves universities and training providers. It offers course catalogs, learner profiles, enrollment, progress tracking, assessments, notifications, and analytics. The platform expects seasonal peaks when examination results and enrollment windows open. Institutions operate in several regions, and the platform must protect personal and academic records. Situation and ProblemThe initial proposal recommends one document database for all data because the development team values flexible schemas and rapid feature delivery. However, requirements analysis reveals several distinct workloads. Course browsing is read-heavy and requires filtering by subject, level, language, and institution. Progress tracking generates frequent updates. Assessment submissions must be durable and auditable. Notifications require temporary state and retry handling. Institutional analytics involves large aggregations that should not interfere with learner-facing transactions. The platform also requires an RPO close to zero for assessment submissions, defined recovery procedures, encryption, role-based access, audit trails, and regional data controls. The team has strong web-development skills but limited experience operating distributed databases. AnalysisThe catalog has variable attributes and is commonly retrieved as a coherent course document, making a document model plausible. Progress events are append-oriented and may be partitioned by learner and course, but the design must prevent one popular course from creating a hot partition. Assessment submissions require stronger transactional guarantees and immutable audit records than a recommendation feed. Notification tokens and delivery attempts are suitable for key–value access with expiration. Analytical workloads should be separated through an event pipeline or analytical store. A single database could reduce operational diversity, but it would force incompatible workloads into one model and create contention. A polyglot design may provide better fit, but only if the organization can operate it reliably. Approach and StrategyThe architecture team defines bounded contexts and selects technologies by workload rather than by organizational fashion. A managed document service supports course and profile aggregates, subject to carefully designed indexes and data-classification controls. A durable transactional store is used for assessment submissions and enrollment invariants. A key–value service manages short-lived notification state. Events are published to an analytical pipeline for institutional reporting. The selection matrix gives high weight to compliance, recovery, and operational simplicity. Before approval, the team conducts a proof of concept using realistic seasonal traffic, skewed course popularity, concurrent progress updates, and restoration tests. It also defines ownership: each service has a source of truth, an API contract, retention rules, and an incident procedure. OutcomeThe final design uses more than one persistence technology but limits that diversity to clearly justified contexts. Learner-facing operations remain isolated from heavy analytics. The team documents consistency expectations: course descriptions may tolerate brief propagation delay, but assessment submission confirmation cannot. Automated monitoring measures latency percentiles, replication lag, failed writes, backup status, and cost indicators. Learning PointsThe case demonstrates that requirements analysis can overturn an attractive single-product assumption. Data modeling should follow access patterns and business invariants. Compliance and recovery requirements can eliminate otherwise capable products. Polyglot persistence is valuable only when bounded by clear ownership, interfaces, and operational competence. Risks, Limitations, and Common MistakesA frequent mistake is selecting technology by popularity, résumé value, or a single benchmark. Another is treating flexible schema as the absence of schema. NoSQL systems still require data contracts, validation, migration processes, and ownership rules. If these are ignored, inconsistency moves from the database into application code and becomes harder to detect. Designers also underestimate secondary indexes, cross-partition queries, and large aggregations. A query may work in development and become expensive when data volume and cardinality increase. Unbounded arrays, oversized documents, monotonically increasing keys, and globally shared counters can create performance or scaling problems. Eventual consistency is sometimes adopted without identifying which user-visible states may be stale. Conversely, teams may demand strong consistency everywhere, increasing latency or reducing availability without business justification. Consistency should be specified per operation or bounded context. Another risk is operational fragmentation. Multiple databases multiply dashboards, alerts, backup policies, patch cycles, access controls, and specialist knowledge. Polyglot persistence must therefore be balanced against the organization’s capacity to operate it. Migration risk is often hidden. Data transformation, dual writes, reconciliation, cutover, rollback, and historical-data validation require substantial effort. A migration plan should identify the authoritative source during transition and define how divergence will be detected. Ethical, Regulatory, and Professional ResponsibilitiesDatabase selection affects people, not merely machines. Poor modeling or governance can expose personal information, produce unfair decisions, or make deletion and correction impossible. Teams should apply data minimization, collect only what is necessary, restrict access by role and purpose, and document retention and deletion rules. Auditable systems must preserve trustworthy records without creating unnecessary surveillance. Logging should record sufficient evidence for security and accountability while avoiding the uncontrolled duplication of sensitive data. Test environments should use masking, tokenization, or synthetic data when production information is not required. Professional responsibility also requires communicating uncertainty. Architects should not present estimated capacity, compliance, or migration cost as certainty. Assumptions, exclusions, evidence quality, and residual risks belong in the decision record. A defensible recommendation includes conditions under which it should be revisited. Technology, Automation, and Emerging DirectionsManaged database services increasingly automate provisioning, patching, backups, scaling, encryption integration, and observability. Automation reduces routine effort but does not remove the need for architectural decisions. Automatic scaling can also create unexpected cost or fail to solve a hot-key problem. Infrastructure as code, policy as code, automated schema validation, workload testing, and continuous backup verification improve repeatability. Observability platforms can correlate database latency with API traces, deployment changes, cache behavior, and queue depth. AI-assisted tools may help generate query suggestions, detect anomalous workload patterns, or summarize operational incidents, but recommendations require human validation. An automated tuning action that changes indexes or partitioning without understanding business access patterns may worsen cost or correctness. Emerging architectures increasingly separate transactional, search, streaming, and analytical concerns while connecting them through events and data contracts. Distributed SQL systems also blur the boundary between relational and NoSQL choices by offering SQL interfaces with horizontal scale and geographic distribution. The implication is not that categories have disappeared, but that selection should focus on workload capabilities rather than labels alone. Best Practices for a Defensible SelectionA sound selection process should: - begin with business capabilities and user journeys;
- document access patterns before choosing a data model;
- separate mandatory requirements from weighted preferences;
- define measurable SLOs, RPO, and RTO;
- model data volume, growth, skew, and peak behavior;
- evaluate security, residency, retention, and deletion early;
- include operations, finance, security, and compliance stakeholders;
- validate candidates with representative proof-of-concept workloads;
- test backup restoration, failover, migration, and schema evolution;
- calculate total cost rather than comparing headline prices;
- record assumptions, evidence, uncertainty, and rejected alternatives; and
- review the decision when workload, regulation, or organizational capability changes.
Chapter SummaryRequirements analysis is the foundation of database technology selection. Business goals must be translated into capabilities, user journeys, access patterns, workload characteristics, and measurable service-level objectives. Important requirements include data volume and velocity, consistency, latency, availability, durability, recovery, security, lifecycle, and operational skill. NoSQL data models are chosen according to workload fit. Documents suit aggregate-oriented and variable structures; key–value stores support direct state access; wide-column systems support distributed high-volume patterns; graph systems support relationship traversal; and search technologies support retrieval and relevance. Polyglot persistence can improve fit but increases operational complexity. Technology selection should evaluate workload fit, maturity, ecosystem, skills, compliance, total cost of ownership, and vendor lock-in. Weighted matrices, proofs of concept, realistic benchmarks, failure tests, and sensitivity analysis make decisions more transparent. The best recommendation is not necessarily the cheapest or most scalable product; it is the option whose technical, organizational, regulatory, and economic properties align with the actual service. Key TermsAccess pattern: The way an application reads, writes, filters, orders, or traverses data. Aggregate: A group of related data treated as a unit for access, update, and consistency. Availability: The proportion of time a service performs its intended function and is accessible. Cardinality: The number of distinct values in a field or relationship. Consistency: The guarantees governing which versions of data clients can observe. Denormalization: Deliberate duplication or restructuring of data to optimize selected operations. Hot partition: A partition receiving disproportionate traffic or storage load. Idempotency: The property that repeating an operation produces the same intended result as performing it once. Polyglot persistence: The use of multiple data technologies for different workload requirements. Proof of concept: A limited implementation used to validate feasibility and performance assumptions. Recovery Point Objective (RPO): The maximum acceptable amount of data loss, expressed in time or data state. Recovery Time Objective (RTO): The maximum acceptable time required to restore service after disruption. Read/write ratio: The relative proportion of read operations to write operations in a workload. Service-Level Objective (SLO): A measurable target for a service characteristic such as latency or availability. Selectivity: The degree to which a query condition narrows the qualifying dataset. Total Cost of Ownership (TCO): The complete cost of acquiring, operating, maintaining, and eventually replacing a technology. Vendor lock-in: Dependence on a provider or technology that makes substitution difficult or costly. Workload fit: The degree to which a technology satisfies the functional and operational demands of a particular workload. Review QuestionsShort Answer Questions1. Why should database selection begin with business goals rather than product features? 2. Distinguish a functional requirement from a non-functional requirement, using one database example of each. 3. What is the difference between RPO and RTO? 4. Why can a unique partition key still produce a poor database design? 5. Define total cost of ownership in the context of database selection. Long Answer Questions1. Explain how a user journey can be transformed into access patterns and measurable database requirements. 2. Discuss the major criteria used to evaluate a NoSQL product beyond workload performance. 3. Compare document, key–value, wide-column, graph, and search-oriented models in relation to their typical access patterns. 4. Explain how a weighted decision matrix should be constructed and identify its limitations. 5. Discuss the governance, security, and compliance issues that must be considered when selecting a database for sensitive data. Analytical / Application Questions1. A ticketing platform experiences brief but extreme demand when popular events open for sale. Propose the requirements-analysis questions and data-model concerns that should be addressed before selecting a database. 2. An organization is considering a low-cost managed NoSQL service that has limited export tools and few engineers with relevant experience. Analyze the decision using maturity, skills, TCO, and vendor-lock-in criteria. 3. Design a high-level persistence strategy for an IoT platform that ingests frequent device readings, supports recent-device queries, retains historical data for analysis, and must protect device identifiers. Justify the separation or combination of technologies you propose. 22. Multiple Choice Questions with AnswersQuestion 1Which sequence best represents the requirements-analysis chain described in the chapter? A. Product feature → benchmark → database schema → business goal B. Business goal → capability → user journey → access pattern → technology implication C. Data type → programming language → user interface → business goal D. Vendor reputation → price → query → compliance requirement Correct Answer: B. Business goal → capability → user journey → access pattern → technology implication Question 2Which requirement is stated in the most measurable form? A. The database must be modern. B. Product searches must be very fast. C. The system should scale well. D. 95 percent of product-detail reads must complete within 150 milliseconds at expected peak load. Correct Answer: D. 95 percent of product-detail reads must complete within 150 milliseconds at expected peak load. Question 3A system must restore service within 30 minutes after a regional outage. Which requirement is being specified? A. RPO B. Cardinality C. RTO D. Selectivity Correct Answer: C. RTO Question 4Which situation most clearly indicates a hot-partition risk? A. Queries use unique customer identifiers evenly distributed across partitions. B. A single globally popular product receives most read and write traffic. C. Historical records are archived after seven years. D. Documents contain optional attributes. Correct Answer: B. A single globally popular product receives most read and write traffic. Question 5Why might assessment submissions be stored separately from a course catalog in the illustrative case? A. Assessment submissions have stronger durability and audit requirements. B. Course catalogs cannot be represented as documents. C. Assessment data never requires security controls. D. Catalog data is always write-heavy. Correct Answer: A. Assessment submissions have stronger durability and audit requirements. Question 6Which statement best describes total cost of ownership? A. It is limited to the database vendor’s storage charge. B. It includes only the cost of developer training. C. It includes acquisition, operation, personnel, migration, support, and exit-related costs. D. It is the number of requests processed per dollar. Correct Answer: C. It includes acquisition, operation, personnel, migration, support, and exit-related costs. Question 7What is the main purpose of sensitivity analysis in a weighted decision matrix? A. To eliminate all mandatory requirements B. To determine whether changes in weights alter the recommendation C. To replace proof-of-concept testing D. To guarantee that the cheapest product wins Correct Answer: B. To determine whether changes in weights alter the recommendation Question 8Which practice best validates a database candidate? A. Testing only a small, uniformly distributed development dataset B. Using the vendor’s published benchmark without modification C. Testing realistic data distributions, concurrency, peaks, failures, and recovery D. Measuring average latency while ignoring tail latency Correct Answer: C. Testing realistic data distributions, concurrency, peaks, failures, and recovery Question 9What is a key risk of adopting eventual consistency without explicit business analysis? A. All writes become impossible. B. Users may observe stale states where freshness is actually required. C. The system cannot use replication. D. Data must always be normalized. Correct Answer: B. Users may observe stale states where freshness is actually required. Question 10Which statement about vendor lock-in is most accurate? A. It is always unacceptable in every architecture. B. It concerns only the ability to export raw data. C. It should be assessed across data, application behavior, operations, skills, and exit costs. D. Managed services eliminate it completely. Correct Answer: C. It should be assessed across data, application behavior, operations, skills, and exit costs.
|
