Q10 proof · NoSQL: MongoDB, DynamoDB and Cassandra-style stores

10. NoSQL databases and years of experience

Answer as submitted

“Yes — 8+ years: MongoDB, DynamoDB, DocumentDB, Neptune and Cassandra/Keyspaces.”

Technical decision: expand. The submitted line names the engines and the duration but not the modelling discipline they require. This page is the separate, detailed version: it shows how the key schema is derived, when data is embedded, and how capacity and hot keys are handled.

Expanded answer

Yes — eight plus years, mostly with MongoDB (embedding versus referencing, compound and text indexes, aggregation pipelines, TTL indexes, replica sets) and Amazon DynamoDB (single-table design, partition and sort key strategy, GSIs/LSIs, on-demand versus provisioned capacity, streams and conditional writes). I have also worked with DocumentDB for document workloads, Neptune for graph modelling and Keyspaces / Cassandra for wide-column, high-write partitions with tunable consistency. The constant across all of them is that the data model starts from the access patterns, not from the entity list.

Decision	Typical implementation	Why it is done this way
Key schema	`PK` + `SK` composite, single table	Every screen becomes a Query against one partition; no Scan on a read path.
Secondary indexes	GSI/LSI, MongoDB compound index	Each index exists to serve a named access pattern, and its cost is counted.
Embed vs reference	embed bounded lines, reference shared data	Data read together is stored together, unless the list is unbounded or shared.
Consistency	eventual by default, strong where required	Cost and latency follow the requirement, not the other way round.
Idempotency	conditional writes, outbox item, streams	A retried write cannot double-apply; events are never lost.
Capacity	on-demand or auto-scaled provisioned	Traffic spikes are absorbed without throttling a paying customer.
Hot partitions	high-cardinality keys, write sharding, TTL	The partition key decides whether the table scales horizontally.

Live NoSQL modelling workflow proof

The running component below changes its design/result view through real event binding. Select a step to see the decision, the reasoning behind it, and the measurement that proves it.

NOSQL WORKFLOWRUNNING

Choose a modelling step

Select a step to inspect the decision, the reasoning and the measured result.

$ PK = CUSTOMER#42 SK = ORDER#2026-10-14#8842

The key schema is derived from the access patterns first: one table with composite keys and overloaded GSIs, instead of one table per entity.

Query (single partition)  ·  137 items  ·  3.1 ms  ·  1 RCU
no Scan anywhere on the read path

How the model is kept honest

Rules I apply. List the access patterns before writing a line of schema; make each screen a partition-scoped Query; justify every index with the query it serves; embed only bounded, co-read data; keep a conditional write or an outbox item for anything that must happen exactly once; and pick the partition key as if the table will one day be 100× larger.

Boundary for Q10: this page covers document, key-value and wide-column modelling. Cross-store migration, graph-traversal algorithm design on Neptune and multi-region global-table topology are separate topics.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of the same decisions.

Acceptance criteria

Names MongoDB, DynamoDB and Cassandra-style stores and the years behind them.
Distinguishes key-schema design, indexing, embedding, consistency and capacity.
Shows an interactive proof of choosing a modelling step and reading its measurement.
Derives the schema from access patterns and keeps every read path free of Scans.
Defers cross-store migration, graph algorithms and global-table topology to a later topic.