Эта глава полезна тем, что показывает эволюцию хранения без магии: от файлов и простой OLTP-модели к NoSQL, NewSQL и HTAP системы обычно приходят не из моды, а из накопившихся ограничений.
На практике она помогает честно описать, где в системе живет состояние, как оно перемещается между очередями, объектным хранилищем и базами данных, и почему из этого автоматически вырастают требования к идемпотентности, ретраям и порядку событий.
В интервью и design review этот материал особенно ценен, когда нужно объяснить, почему архитектура данных усложнилась именно в такой последовательности, а не потому что команда сразу побежала за самым тяжелым стеком.
Практическая польза главы
Модель состояния
Явно описывайте, где живет state: в приложении, в очереди, в БД или в object storage, и какие гарантии нужны на каждом шаге.
API и данные
Проектируйте API-контракты с учетом моделей хранения: идемпотентность, ретраи, порядок событий и дедупликация.
NewSQL и HTAP
Понимайте, когда NewSQL/HTAP упрощают архитектуру, а когда лучше разнести транзакционный и аналитический контуры.
Interview-структура
На интервью уверенно объясняйте путь эволюции данных от простого хранения к распределенной архитектуре без лишней сложности.
Источник
Essential Architecture - Data
Расшифровка лекции (4 Oct 2021) о хранении данных и влиянии на API.
Это краткое описание эволюции подходов к хранению состояния: от файлов и классических OLTP-систем до NoSQL, NewSQL и HTAP. Данные напрямую формируют удобство API: от латентности и гарантий консистентности до ретраев, идемпотентности и границ ответственности между командами.
Начнем с принципа 12-factor приложения — принципа номер 6. Его суть в том, чтобы делать stateless приложения и не хранить состояние внутри них. Если получается так спроектировать приложение, вопросы отказоустойчивости и масштабирования решаются гораздо проще, чем в случае stateful приложений. Но тогда возникает ключевой вопрос: где хранить состояние и как это влияет на API-контракты?
Почему данные определяют API
Связанная тема
The Twelve-Factor App
Stateless как фундамент масштабирования и устойчивости.
Архитектурные решения по данным превращаются в свойства интерфейсов.
- Скорость и латентность ответов
- Согласованность (strong vs eventual)
- Модель ошибок и повторов
- Ограничения на фильтрацию/поиск/пагинацию
- Идемпотентность, ретраи и дедупликация
- Границы ответственности между командами
Stateless как фундамент
Принцип 12-factor: приложения не хранят состояние в процессе. Масштабирование становится проще, но нужно осознанно выбрать место хранения данных.
Эволюция хранения состояния
Файловые системы
Форматы хранения и логика чтения легко протекают в бизнес-код.
Реляционные БД (OLTP)
SQL + транзакции дают сильные гарантии и выразительный API.
OLAP и аналитика
Кубы, модели «звезда/снежинка» и агрегаты для BI.
Big Data / Hadoop
MapReduce и экосистема для массовой обработки данных.
Object Storage
Объекты без иерархий, S3 API как де-факто стандарт.
NoSQL
Горизонтальное масштабирование ценой компромиссов.
NewSQL
SQL + ACID в распределённой архитектуре для транзакционной нагрузки на масштабе.
HTAP
Сближение OLTP и OLAP: near real-time аналитика рядом с операционными данными.
NewSQL и HTAP в архитектурных решениях
Когда нужен NewSQL
Если нужны SQL-модель, строгие транзакции и горизонтальный рост без ручного shard management.
Когда нужен HTAP
Когда продукту нужны оперативные транзакции и аналитика почти в реальном времени на тех же данных.
Ключевые риски
Рост операционной сложности, дорогие cross-region запросы, ограничения по сложным аналитическим операциям.
Как это защищать на интервью
Объясняйте, какую боль решает подход, какие trade-offs принимаются и какие guardrails закрывают риски.
Практический ориентир: NewSQL подходит для stateful core-процессов с высокой транзакционной ценой ошибки, а HTAP — для продуктовых сценариев, где аналитика должна идти почти синхронно с операционным контуром.
Реляционные БД: ключевые понятия
Связанная тема
Database Internals
B-Trees, LSM и транзакции внутри СУБД.
Нормализация
Формы данных влияют на схему и поведение запросов.
SQL
Декларативный язык отделяет «что» от «как».
Индексы
Ускоряют чтение, но замедляют запись и обновления.
Транзакции и ACID
Атомарность, изоляция и долговечность формируют контракты.
Репликация
Failover и масштабирование чтений с trade-offs по консистентности.
Шардирование
Роутинг по shard key и распределение нагрузки.
Углубиться: Designing Data-Intensive Applications и Database Internals.
Интеграция между системами
Связанная тема
Enterprise Integration Patterns
Файлы, RPC и messaging как паттерны интеграции.
File transfer
Понятный способ обмена, но со слабой инкапсуляцией.
Shared database
Высокая связанность и замедление развития из-за общей схемы.
RPC
Сильные контракты, но требует дисциплины версионирования.
Messaging
Асинхронные сценарии и гибкость интеграций.
Shared database создаёт high coupling и ломает контракты между командами. Современные системы стремятся к shared-nothing.
Data Lake vs Data Mesh
Связанная тема
Big Data
Эволюция аналитики и архитектурные слои.
Data Lake
Централизованный сбор данных из OLTP с ETL-процессами. Масштабирование усложняет связанность и качество данных.
Data Mesh
- Доменно-ориентированная децентрализация
- Данные как продукт
- Self-service платформа
- Federated computational governance
DDD и границы доменов
Связанная тема
Learning Domain-Driven Design
Bounded contexts и доменные контракты.
Доменные границы и контракты между bounded contexts делают API устойчивыми. Подходы DDD помогают отделить модели данных разных команд.
Как данные превращаются в удобный API
Мостик Data -> API
- Предсказуемые гарантии (ACID vs BASE)
- Ясные источники истины
- Чёткая модель ошибок и ретраев
- Границы доменов и контрактов
- Идемпотентность и дедупликация
- Изоляция от shared database
NoSQL через призму CAP/BASE
Понимание CAP и BASE помогает объяснять клиентам eventual consistency и строить корректные ретраи.
Мини-чеклист удобного API
- Понятно, какие гарантии консистентности даёт система.
- Клиент понимает, где возможна eventual consistency.
- Идемпотентность для операций, которые могут быть повторены.
- Ошибки, ретраи и таймауты описаны детерминированно.
- Нет shared database как скрытого канала интеграции.
- Доменные границы отражены в контракте API.
Практические сценарии выбора хранилища
FinTech ledger / биллинг
Реляционная БД или NewSQL
Сильная консистентность, строгие транзакции, корректная обработка повторов и аудита.
Realtime отчётность продукта
HTAP или OLTP + streaming + OLAP
Нужны быстрые дашборды без долгого ETL-лага и без потери транзакционной части.
Телеметрия и мониторинг
TSDB + object storage
Высокий ingest, retention-политики и дешёвое долгосрочное хранение исторических метрик.
Контент + поиск + рекомендации
Polyglot persistence
Одна БД редко оптимальна для транзакций, полнотекстового поиска и векторного retrieval одновременно.
Связанные главы
- Путеводитель по БД - Практический ориентир по выбору и эксплуатации баз данных под разные нагрузки.
- Фреймворк выбора БД: как принимать решения - Структурирует принятие решений между OLTP/OLAP/NoSQL и учитывает NFR-ограничения.
- Designing Data-Intensive Applications (short summary) - Фундаментальные концепции о моделях данных, репликации и консистентности для API-контрактов.
- Database Internals (short summary) - Детали движков хранения (B-Tree, LSM, WAL), которые напрямую влияют на latency и throughput.
- Enterprise Integration Patterns (short summary) - Паттерны интеграции между системами: когда выбирать файлы, RPC или messaging.
- CAP теорема - Базовые компромиссы консистентности и доступности при сетевых разделениях.
- Data Mesh in Action (Data Mesh в действии) - Эволюция data platform от централизованного lake-подхода к доменному владению данными.
- The Twelve-Factor App: принципы cloud-native - Принцип stateless-приложений как отправная точка для выбора внешнего хранилища состояния.