Источник
Essential Architecture - Data
Расшифровка лекции (4 Oct 2021) о хранении данных и влиянии на API.
Данные напрямую формируют удобство API: от латентности и гарантий консистентности до ретраев, идемпотентности и границ ответственности между командами. Начнем с принципа 12-factor приложения — принципа номер 6. Его суть в том, чтобы делать stateless приложения и не хранить состояние внутри них. Если получается так спроектировать приложение, вопросы отказоустойчивости и масштабирования решаются гораздо проще, чем в случае stateful приложений. Но тогда возникает вопрос: где хранить состояние?
Почему данные определяют 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
Горизонтальное масштабирование ценой компромиссов.
Реляционные БД: ключевые понятия
Связанная тема
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.
Материалы из лекции
Рекомендуемые источники и книги для углубления: