Databases: the system of record
Databases: the system of record
Stub
A database stores data durably and answers queries. It is usually the slowest and hardest part to scale, so most designs revolve around protecting it.
- Use when
- Data that must survive restarts and be queried consistently
- Avoid when
- Temporary or recomputable data — memory or a cache is cheaper · Large files — object storage fits better
- Trade-offs
- Stronger guarantees (transactions) cost throughput · Managed databases trade control for less operations work
- Requires
- Client–server & request/response
3 objectives · 2 misconceptions
- predict Predict which tier saturates first when read traffic grows on a simple app + database system.
- explain Explain what a durable write is and why it costs latency.
- diagnose Tell connection-pool exhaustion apart from CPU saturation.
- Not true: A database scales out as easily as stateless app servers.
- Not true: More database connections always mean more throughput.
Learn
No lesson yet — this station is a stub. The codex card above is the short version.
Practice
No katas practice this yet.
Check
No test-out yet — it needs live questions.
Neighborhood
builds onClient–server & request/response
→Databases: the system of record→