Key-Value Database - это фундаментальный building block для распределённых систем. Он лежит под кэшами, сессиями, фича-флагами, event state и многими сервисами платформы. На собеседовании этот кейс проверяет умение балансировать latency, consistency, durability и стоимость эксплуатации.
Источник
Acing the System Design Interview
Глава 8: Design Key-Value Database с фокусом на partitioning, quorum и fault tolerance.
Примеры Key-Value систем
- Amazon DynamoDB: managed KV with partitioning и global tables
- Redis: in-memory KV, sub-ms latency, rich data structures
- Cassandra: wide-column KV c tunable consistency
- Riak: AP-ориентированная архитектура с vector clocks
- etcd/Consul: strongly-consistent KV для service discovery и config
Функциональные требования
Core API
PUT /kv/:key- записать значениеGET /kv/:key- получить значениеDELETE /kv/:key- удалить ключBATCH /kv- пакетные операции
Расширенные функции
- TTL и фоновая очистка expired ключей
- Conditional writes (CAS/version check)
- Idempotency для write path
- API наблюдаемости: health, metrics, lag
Нефункциональные требования
| Требование | Целевое значение | Обоснование |
|---|---|---|
| Read latency (p95) | < 20ms | Использование как online serving storage |
| Write latency (p95) | < 40ms | Стабильный ingest при пиковых нагрузках |
| Availability | 99.99% | Критичный инфраструктурный компонент |
| Scalability | Линейный рост по partition | Рост без полного re-architecture |
| Durability | Переживать отказ узлов/AZ | Потеря данных недопустима для core state |
High-Level Architecture
Теория
Репликация и шардинг
Практический разбор partitioning, rebalancing и consistency в распределённых хранилищах.
Ниже базовый контур key-value платформы: request plane, routing через consistent hash ring, shard groups с репликацией и storage maintenance слой.
Architecture Map
partitioning + replication + quorumСхема разделяет request plane, shard groups и фоновые процессы восстановления/поддержки.
Data Model Map
Логическая запись и её физическое размещение в распределённом KV-кластере.
Logical Record
key
user:123:session
value
opaque blob / json / bytes
metadata
Physical Placement
partitioning
hash(key) -> partition_id: 17
replica set
A-leader, A-r1, A-r2
lifecycle
active -> ttl-expired -> background sweep
Identity
Ключ определяет место хранения и маршрутизацию.
Consistency
`version` нужен для CAS/update race и safe merge.
Reliability
`checksum` и реплики помогают обнаруживать и чинить битые данные.
Read / Write Path через компоненты
Интерактивная схема показывает путь запроса от клиента до shard-ов и обратно: как запись фиксируется через WAL и quorum ACK, и как чтение проходит через replica selection и version check.
Key-Value Read/Write Path Explorer
Интерактивный разбор прохождения запросов через ключевые компоненты KV-хранилища.
Write path
- Ключ определяет shard group через consistent hashing, что обеспечивает горизонтальное масштабирование.
- WAL закрывает риск потери данных при сбое между приёмом запроса и flush в storage engine.
- Quorum W контролирует баланс между latency и durability.
- Idempotency/CAS защищают систему от дублей и lost update при ретраях.
Storage Engine: B-Tree vs LSM-Tree
B-Tree vs LSM-Tree: выбор структуры данных
Архитектура B-Tree
✓ Преимущества
- Быстрое чтение: O(log N)
- Эффективные range-запросы
- In-place updates
✗ Недостатки
- Write amplification
- Random I/O при записи
Где используется:
Консистентность и отказоустойчивость
Глубже
Designing Data-Intensive Applications
Консистентность, replication lag, anti-entropy, quorum и CAP/PACELC trade-offs.
Quorum model
Для replica factor N выбираются параметры чтения R и записи W. Базовое правило для сильнейшей tunable consistency:
R + W > N
- W↑, R↓ - дороже запись, быстрее чтение
- W↓, R↑ - быстрее запись, дороже чтение
- R=1, W=1 - максимум latency/perf, минимум гарантий
Repair и recovery
- Hinted handoff: временное хранение writes для недоступной реплики.
- Read repair: исправление stale данных во время чтения.
- Anti-entropy: периодическая сверка (например, Merkle trees).
- Rebalancing: перенос partitions при добавлении/удалении узлов.
Риски и типовые ошибки
- Hot partitions: плохой key design создаёт uneven load и latency spikes.
- Write amplification: агрессивная compaction бьёт по tail latency.
- Stale reads: при слабой консистентности пользователь видит старое состояние.
- Blind retries: без idempotency может сломаться корректность состояния.
- Split-brain: неверная конфигурация leader election/coordination.
Что важно проговорить на интервью
- Почему выбран конкретный consistency mode и где бизнес допускает eventual consistency.
- Как система ведёт себя при отказе узла, AZ, сети и при волне повторных запросов.
- Как предотвращаются hot keys/partitions и как работает online rebalancing.
- Какие SLO мониторятся: p95/p99 latency, error rate, replica lag, repair backlog.