System Design Cases
DB Selection Framework
DB Selection Framework — decision tree concept page. 6 dimensions (data model, scale, consistency, query patterns, ops maturity, cost) → engine pick. Maps workloads (e-commerce OLTP+search, real-time analytics, social graph, vector AI/RAG, global ACID, NoSQL antipattern) to engines (Postgres, MongoDB, Cassandra, DynamoDB, Spanner, ClickHouse, Pinecone, Neo4j, Redis, Elasticsearch). Includes ADR on NoSQL hype vs Postgres-достаточно. 6 scenarios.
Database selection framework: workload evidence before product choice
Database selection is a constraint-matching and measurement problem, not a table of user-count or dataset-size thresholds. Start with access patterns, invariants, consistency, failure objectives, deployment constraints, team operations, and migration cost. Only then shortlist systems and run representative correctness and load tests.
A system may support transactions, JSON, indexes, graph queries, vector search, or columnar analytics with different scopes and costs. Product categories overlap; capability must be checked in the current official documentation and proved for the exact query and failure path.
Модель и предпосылки
- Hard gates reject a candidate before performance scoring: required isolation, data residency, backup/restore, supported query semantics, and operability.
- Benchmarks replay production-shaped key skew, data distribution, concurrency, failure, recovery, and tail latency; vendor headline numbers are not acceptance tests.
- The chosen design includes an exit path: canonical data ownership, export/restore test, schema evolution, and a reversible migration plan.
Проверяемые утверждения
- C1. Serializable transactions are a scoped database capability; they must be matched to application invariants and retry behavior.
- C2. DynamoDB tables and LSIs can serve strong reads, while GSIs and Streams are eventually consistent.
- C3. Neo4j shortest-path planning depends on endpoints, predicates, and operator choice; graph storage is not a universal complexity shortcut.
- C4. Qdrant combines vector and payload indexes; filtered ANN requires both modeling and recall/latency evaluation.
- C5. DuckDB is an in-process analytical engine with columnar-vectorized execution, not a general network OLTP replacement.
Исполняемые сценарии
Transactional invariant gate. A candidate must preserve the actual concurrent invariant and expose a workable retry contract before latency is scored.
Key-value access-pattern fit. Known partition-key reads may fit a key-value store, but secondary-index and consistency semantics remain explicit.
Graph and vector evidence. Traversal shape and ANN recall are measured separately; neither product label proves the workload.
Embedded analytics boundary. An in-process OLAP engine is selected for local analytical scans, not assumed to be a multi-service OLTP authority.
Reversible decision and re-test. Restore, export, migration, and workload-drift triggers are part of selection, not post-launch paperwork.
Ошибки проектирования
- Не выбирайте database по числу пользователей, гигабайтам или «стартап/enterprise» без workload и SLO.
- Schemaless не означает отсутствие schema: validation, indexes, migration и compatibility просто переходят в другие слои.
- Наличие ACID не означает, что multi-service dual write атомарен, а наличие JOIN не гарантирует хороший план для конкретной модели.
- Не сравнивайте managed price по одной единице: учитывайте replicas, indexes, egress, backups, operations и idle/peak profile.
Границы гарантии
- Framework не объявляет одного победителя: один продукт может быть system of record, другой — производной search/analytics projection.
- Полиглотность оправдана только с явным ownership, replication lag semantics, rebuild и incident runbook.
- Все числовые пределы и цены должны быть датированы и проверены перед решением; в уроке нет универсальных cutoffs.