Architecture Reference

Appearance

Database Foundations ​

Database Foundations Graphics Coverage ​

Primary chapter graphic: Database Normalization Progression, PostgreSQL Process Architecture, Cache Failure Modes, Database Learning Map, MongoDB Request Routing, Database Index Types, Key-Value Store Comparison, Database Type Selection Map, SQL Join Types, CQRS Read and Write Split, Redis Query Persistence Lifecycle. Accepted graphics: 11. Reviewed non-signal pages: 0. Open graphics in review: 0. QA status lives in graphics audit and visual review ledger.

Corpus pages: p. 83-84, p. 86, p. 96, p. 151, p. 187, p. 214-215, p. 218-221, p. 226, p. 246, p. 252 Coverage: 15 pages

This chapter is part of Marius's owned architecture build corpus. The text routes decisions; durable implementation signal is carried by accepted graphics, reviewed non-signal decisions, and the linked QA audit.

Chapter Visuals ​

Accepted graphics carry the canonical design signal for this chapter. Each selected source page is either accepted as a graphic or explicitly marked non-signal in the source-faithful ledger. Review and QA state live in visual inventory, visual review ledger, and graphics audit.

Database Normalization Progression ​

Database Normalization Progression

PostgreSQL Process Architecture ​

PostgreSQL Process Architecture

Cache Failure Modes ​

Cache Failure Modes

Database Learning Map ​

Database Learning Map

MongoDB Request Routing ​

MongoDB Request Routing

Database Index Types ​

Database Index Types

Key-Value Store Comparison ​

Key-Value Store Comparison

Database Type Selection Map ​

Database Type Selection Map

SQL Join Types ​

SQL Join Types

CQRS Read and Write Split ​

CQRS Read and Write Split

Redis Query Persistence Lifecycle ​

Redis Query Persistence Lifecycle

Open Review Queue ​

  • none

Reviewed Non-Signal Pages ​

  • none

Use When ​

  • A system needs durable records, queryable state, transactions, or reporting foundations.

Avoid When ​

  • A short-lived artifact can be regenerated and does not need storage ownership.

Core Model ​

  • Databases encode ownership, invariants, query paths, and retention promises.
  • Prefer explicit ownership over accidental coupling. Every boundary should say who owns correctness, cost, data, recovery, and change.
  • Use corpus page pointers for inspection, and keep the chapter notes focused on reusable design decisions.

Implementation Guidance ​

  • Name entities, source of truth, relationships, transactions, read patterns, retention, and restore requirements.
  • Write the smallest useful design note: purpose, inputs, outputs, state, failure behavior, observability, and rollback.
  • Choose the first implementation that can be tested against the real workflow without hiding a known production risk.

Tradeoffs ​

  • Normalized schemas protect consistency, while denormalized shapes optimize common reads.
  • Centralization reduces duplicated work but can become a bottleneck when every team needs exceptions.
  • Specialized infrastructure helps at scale, but it must earn its operational cost.

Failure Modes ​

  • Two stores both claim to be the source of truth for the same entity.
  • The diagram shows boxes but not ownership, retry behavior, data freshness, or user-visible failure.
  • The system has no proof path for the highest-risk assumption.

Decision Checklist ​

  • Document entity ownership, invariants, migrations, backups, restore drill, and deletion behavior.
  • Name the owner, source of truth, timeout, retry policy, and evidence that the path works.
  • Add one regression check for the failure mode most likely to recur.

Neutral Automation Examples ​

  • A booking workflow keeps reservations transactional while search and reporting read from projections.
  • A neutral internal automation starts with fixtures, then adds credentials, permissions, and production scheduling only after the boundary is tested.
  • A customer-facing workflow keeps irreversible actions behind explicit approval until metrics show it is safe to automate further.