Document and wide-column stores
Use a document store for data read and written by key with a changing shape, and a wide-column store when writes outgrow one machine, and accept what each gives up.
Move data that a relational table fits badly into a document store or a wide-column store, and keep what needs joins on the Database.
Move up when#
The schema keeps changing and features ship slowly because every change is a migration.
The work is documents read by key, such as a profile, a cart, or a settings page.
Writes outgrow one Database, even after a bigger box, and you can live without joins.
The Design#
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | small | Small is enough, because the store does the data work. |
| Document Store | Multi-document transactions | On | A checkout writes several documents, and without this a failure halfway leaves the order half saved. Every write pays more latency for it. |
| Document Store | Instance size | small | One flat rate covers reads and writes, so size is the only capacity knob. |
Research this Design needs: Checkout, Document databases, Document databases.
The App Server calls a Document Store for documents and a Payment Provider for charges. A checkout writes several documents, so Multi-document transactions is on, which keeps the order atomic.
Drag to pan. Hold Ctrl or Cmd and scroll to zoom.
| Where | Setting | Value | Why |
|---|---|---|---|
| App Server | Instance size | small | Small is enough, because the store does the data work. |
| Wide-column Store | Read quorum (R) | 2 | A read asks two of the three replicas, so at least one holds the latest write. |
| Wide-column Store | Write quorum (W) | 2 | A write waits for two of three. With R at two, R plus W is above N, so every read sees the last write. |
| Wide-column Store | Instance size | small | A write costs N replica operations and a read costs R, so capacity is spent faster than the size suggests. |
Research this Design needs: Leaderless replication, Sharding, Leaderless replication.
The second Design uses a Wide-column Store with N replicas per key. A write waits for W of them and a read asks R.
Why it works#
A document store trades joins for speed of change: no migration, no pool to share, and one flat rate for reads and writes. A wide-column store spreads each key over N replicas and has no single primary, so writes scale out. When R plus W is greater than N, a read always asks at least one replica holding the latest write.
What it costs#
A document store has no joins, so a checkout or report that spans documents costs more work, and without transactions a checkout can land half saved. A wide-column store spends N replica operations on every write, so a strong setting costs capacity and lowers the rate. A weak setting is cheap and serves stale reads. Even a strong quorum is not linearizable, so keep checkouts on a relational store.
In Quorum#
The Document Store needs Document databases. The Wide-column Store needs Sharding and then Leaderless replication. Watch for the Hot key incident. See quorum and eventual consistency, and the pattern on Quorum reads and writes. The next rung keeps several stores apart: Split the database by feature.