What NoSQL actually is
NoSQL databases exist because of the wall you just studied: one SQL leader has a write ceiling, and sharding SQL by hand (lesson 5-1) is real surgery. In the late 2000s, web companies stuck at that wall built databases that shard themselves, and the family got the name NoSQL: databases that give up some of SQL's features in exchange for easier horizontal scaling. The two members worth knowing first:
- Key-value stores (Redis, DynamoDB): a giant dict. Get and set by key, blazing fast, no joins, no queries by other columns
- Document stores (MongoDB, DynamoDB again): values are JSON-like documents, queryable by fields, flexible per-row structure
What they typically give up, compared to the SQL you learned:
- Joins: you fetch related data yourself, or duplicate it into the document
- Multi-row transactions: all-or-nothing updates across rows are limited or absent
- A fixed schema: flexible, but typos and drift become your problem
What they buy: most were built sharded, with consistent hashing inside, so scaling out is turning a dial instead of the unit 5 surgery you just studied.
The honest decision table
| Situation | Reasonable default |
|---|---|
| Almost every new app | SQL (Postgres, MySQL) |
| Money, inventory, anything needing transactions | SQL |
| Simple key-based access at enormous write scale | Key-value or document store |
| Caches and sessions | Redis |
| Flexible or fast-changing record shapes | Document store |
The honest part: SQL scales much further than the internet claims. One well-indexed Postgres box with replicas handles millions of users, and sharded SQL runs some of the largest sites alive. Most NoSQL migrations at small companies were fashion, not need, and the teams missed joins within a month.
Pick SQL until you can name the specific limit you are hitting, in numbers, like writes per second beyond one leader (lesson 5-1) or truly key-only access patterns.
Which property makes SQL the safe choice for payments
Transactions, because debiting one account and crediting another must succeed or fail together.
A transfer is two updates that must be atomic, meaning both happen or neither does. SQL transactions guarantee exactly that, and the guarantee holds across a crash, a power loss, or a process being killed mid-operation.
In a store without multi-row transactions, a crash between the debit and the credit silently destroys money. The account was charged, the recipient was never paid, and nothing in the system records that an inconsistency exists.
Silently is the word that matters. There is no error to catch and no log line to find, so the discrepancy surfaces days later when someone reconciles the books, which is the most expensive possible time to discover it.
Reconstructing the guarantee in the application layer is harder than it sounds, and it is why people reach for the database's version. Compensating writes, idempotency keys, and a recovery process are all required, and unit 6 covers the pieces of that machinery.
Where correctness under failure matters most, choose the tool that promises it. Money is the clearest case, and the same argument applies to inventory, bookings, and anything where two records must agree.
Sizing the split-out workload
The answer is 4 nodes.
60,000 / 20,000 = 3 nodes at exactly full capacity, which means one failure overloads the survivors. Three nodes handling 20,000 each leaves nothing in reserve, so losing one leaves 40,000 of capacity against 60,000 of load.
Run 4, which is N+1 provisioning from lesson 2-3. The same arithmetic that sized the app fleet sizes the database tier, since the reasoning does not depend on what the machines do.
With four nodes each carries 15,000 writes per second, which is 75% of capacity. Losing one puts the survivors at 20,000 each, meaning exactly full, and that is the definition of surviving a failure rather than being comfortable during one.
Note why this workload was a good NoSQL candidate, since the sizing is the easy part. Key-only access, no joins, and no transactions means the features SQL would charge scaling pain for are features this data never uses.
Session updates are also the friendliest possible data to lose. They are short-lived and reconstructible by asking the user to log in again, so the weaker durability guarantees that come with easy sharding cost almost nothing here.
That is the honest form of the SQL versus NoSQL decision. It is not a judgment about which database is better, it is a match between one workload's actual requirements and what each tool charges for them.