Выбор базы данных по паттернам доступа, а не по трендам

Проблема: тренды не знают ваших запросов

Выбор СУБД «потому что так делают все» звучит безопасно: меньше объяснений, проще найм, больше статей и кейсов. Но трендовая база данных не знает, какие именно запросы будут доминировать у вас: что читается чаще всего, как обновляются данные, какие отчёты нужны бизнесу, насколько важны задержки и какие пики нагрузки случаются по расписанию.

Почему «модная» СУБД не гарантирует успех

Мода обычно отражает чужие контексты: другие объёмы данных, команды, SLA и компромиссы. В результате продукт может получить:

• долгие ответы на ключевые запросы из‑за неподходящих индексов или модели данных;
• сложную поддержку (больше сервисов, больше точек отказа);
• неожиданные расходы на инфраструктуру и администрирование;
• ограничения по консистентности или транзакциям, которые всплывают слишком поздно.

Что значит «паттерны доступа» простыми словами

Паттерны доступа — это привычки вашей системы «читать и писать» данные. Какие запросы выполняются каждую секунду? Это поиск по одному ключу, выборка ленты, обновление статусов, агрегации за день, полнотекст? Какие операции должны быть мгновенными, а какие можно выполнять асинхронно? Как часто данные меняются и как долго хранятся?

Что вы получите, если выбирать от нагрузки

Вы начинаете не с бренда СУБД, а с поведения продукта. Это помогает заранее подобрать модель данных, индексацию, стратегию масштабирования и оценить стоимость владения — без героических переделок на продакшене.

О чём статья

Дальше — практичные критерии и чек-лист: как описать нагрузку (OLTP/OLAP/смешанная), определить требования к консистентности и транзакциям, понять роль запросов и индексов, а затем подтвердить выбор через POC и нагрузочные тесты.

Как описать паттерны доступа до выбора СУБД

Прежде чем спорить «PostgreSQL или MongoDB», зафиксируйте, как именно продукт читает и пишет данные. Паттерны доступа — это описание реальных операций и их частоты. Оно быстро отсекает популярные, но неподходящие варианты.

1) Какие операции доминируют

Ответьте в процентах или порядках величин: что происходит чаще — чтение, создание записей, обновления, удаления. Отдельно отметьте «дорогие» операции: массовые апдейты, дедупликацию, пересчёты, импорты.

2) Форма запросов

Опишите 10–20 ключевых запросов «как в жизни»:

• точечные по ключу (получить сущность по id);
• фильтры по нескольким полям (статусы, диапазоны дат);
• джойны (профиль + подписка + права);
• агрегации (суммы, топы, отчёты).

Даже грубая формулировка помогает понять, нужен ли вам сильный оптимизатор запросов и гибкая индексация, колоночное хранение, или достаточно почти key-value доступа.

3) Предсказуемость запросов

Запросы повторяемые и заранее известные (API, экраны продукта) или пользователь может «свободно искать» по множеству полей, сортировать, комбинировать фильтры? Во втором случае резко растут требования к индексам, полнотекстовому поиску и стоимости поддержки.

4) Ритм нагрузки

Зафиксируйте пики (день/ночь, распродажи), сезонность, фоновые задачи (ETL, пересчёты). Часто «одна база» не справляется именно из‑за конкуренции интерактивных запросов с пакетными.

5) Требования к задержке

Разделите операции на интерактивные (например, p95 < 200–500 мс) и пакетные (минуты допустимы). Это влияет на выбор движка, кэширования и стратегию индексации.

Чек-лист вопросов к продукту и команде

Чтобы выбрать СУБД по реальным паттернам доступа, начните не со сравнения «брендов», а с разговора с продуктом, аналитиками и разработкой. Цель — зафиксировать ожидания от данных так, чтобы их можно было проверить цифрами и простыми примерами.

1) Нагрузка и рост

Сформулируйте текущую долю чтений и записей (например, 80/20) и прогноз на 6–12 месяцев. Важно уточнить «рост чего»: пользователей, событий, размера сущностей, числа запросов в секунду. Если есть пики (утро понедельника, распродажи) — обозначьте их отдельно.

2) Сущности и связи

Список ключевых сущностей и связей часто быстрее проясняет выбор, чем абстрактные требования:

• Какие основные объекты: пользователь, заказ, платеж, событие?
• Какие связи критичны: 1:1 (профиль), 1:N (пользователь → заказы), N:M (товары ↔ заказы)?
• Какие запросы требуют «собирать» данные через несколько связей?

3) Top-10 запросов и SLA

Попросите команду назвать 10 самых важных запросов (или экранов/отчетов) и SLA по времени ответа: что должно быть <100 мс, что допустимо за 1–3 секунды, а что можно считать пакетно. Это сразу подсветит необходимость индексов, агрегаций, денормализации или отдельного хранилища.

4) Цена ошибки и требования к истории

Уточните, можно ли «временно» ошибиться в данных (и как это исправлять): допускаются ли дубликаты, запоздалые обновления, расхождения между сервисами. Отдельно зафиксируйте требования к аудиту и истории изменений: нужно ли хранить все версии, кто и когда изменил запись, как долго держать логи, можно ли удалять персональные данные по запросу.

Если ответы расплывчатые — сделайте короткий совместный воркшоп и оформите результаты как одностраничный документ, к которому вы будете возвращаться в POC и нагрузочных тестах (см. /blog/kak-prinimat-reshenie-matrica-poc-i-nagruzochnye-testy).

Тип нагрузки: OLTP, OLAP и смешанные сценарии

Перед выбором СУБД полезно честно назвать тип нагрузки. Не «у нас веб‑сервис», а что именно происходит с данными каждую секунду: сколько записей, какие чтения, какие задержки допустимы, и кто с кем конкурирует за одни и те же строки.

OLTP: много коротких транзакций и конкурентные записи

OLTP — это поток небольших операций: создать заказ, списать остаток, обновить статус, записать платеж. Характерные признаки — частые записи, много параллельных пользователей и необходимость предсказуемой задержки на запрос.

Здесь критичны транзакции, блокировки/версионность, индексы под точечные выборки и обновления. Если хранилище не рассчитано на конкурирующие записи, вы быстро увидите очереди, конфликты и «скачущие» времена ответа.

OLAP: тяжёлые агрегации, сканы, отчёты, BI

OLAP — это аналитика: группировки, джоины по большим таблицам, сканы за периоды, витрины, отчёты для BI. Нагрузка часто пакетная, но запросы «тяжёлые» и могут читать миллионы строк за раз.

Здесь выигрывают колоночные форматы, партиционирование по времени, предагрегации и движки, оптимизированные под последовательное чтение.

Смешанные сценарии: оперативные отчёты рядом с транзакциями

Самая частая ситуация: транзакции идут постоянно, а бизнес хочет «отчёт прямо сейчас». Если пускать аналитические сканы в ту же базу, где живёт OLTP, они начинают конкурировать за CPU, память, диски и кэши.

Практичный подход — разделять контуры: транзакционная база для операций и отдельный контур для аналитики (реплика, поток событий, витрина), чтобы отчёты не влияли на SLA пользовательских действий.

Фоновая обработка: очереди, события, батчи

Импорт/экспорт, пересчёты, рассылки, обработка событий — это отдельный профиль нагрузки. Батчи создают пики записи и чтения, а очереди требуют гарантированной доставки и идемпотентности обработчиков.

Что обычно ломается, если перепутать тип нагрузки

Если выбрать OLAP‑хранилище под OLTP, страдают конкурентные обновления, транзакционность и латентность. Если тащить OLAP‑запросы в OLTP‑базу без изоляции, получаете деградацию времени ответа, рост блокировок/конфликтов и непредсказуемые пики нагрузки.

Модель данных следует за тем, как вы читаете и пишете

Выбирая СУБД, полезнее начинать не с «какая база модная», а с вопроса: какие операции будут происходить чаще всего — чтение, запись, обновления, поиск, агрегации, обход связей. Модель данных — это не абстракция из учебника, а способ сделать типовые запросы дешевле и проще.

Реляционная модель: когда важны связи и выборки

Таблицы и связи хороши там, где вы часто делаете выборки по нескольким сущностям сразу: «заказ + позиции + клиент», «платёж + статус + история». Джойны помогают не дублировать данные, а индексы — держать быстрые фильтры и сортировки. Цена — более строгая схема и необходимость заранее думать о структуре.

Документная модель: когда читаете «целым объектом»

Если основной паттерн — получить объект целиком (профиль пользователя, карточка товара со всеми атрибутами), то вложенность и денормализация уменьшают число запросов. Но частые точечные обновления вложенных полей и сложные «сквозные» отчёты могут усложниться.

Ключ–значение: когда нужен молниеносный доступ по ключу

Сессии, токены, кэш результатов, счётчики, feature-flags — классические случаи. Операции простые: положить/взять по ключу. Как только вам нужны гибкие фильтры и сложные выборки, придётся дополнять другим хранилищем.

Колонночные хранилища: когда преобладают агрегации

Для аналитики важнее быстро читать много строк, но мало колонок и считать суммы/средние/группировки. Такие базы оптимизированы под сканирование и сжатие данных, а не под частые точечные обновления.

Поисковые движки: когда нужен полнотекст и релевантность

Поиск по тексту, автодополнение, ранжирование, «похожие товары» — это отдельный класс задач. Они плохо ложатся на классические индексы СУБД, зато естественны для поисковых движков с анализаторами и скорингом.

Графовые модели: когда главный запрос — обход связей

Рекомендации, антифрод, социальные связи — там, где запрос звучит как «найди через 2–3 шага» или «какие пути связывают». Если ваш продукт живёт на таких обходах, граф часто даст кратно проще запросы и предсказуемее время ответа.

Консистентность и транзакции: что действительно необходимо

Слова «ACID» и «eventual consistency» часто звучат как выбор религии, но на практике это набор конкретных требований к тому, что пользователь увидит после записи и что произойдёт при сбое. Чем точнее вы сформулируете ожидания, тем меньше переплатите за «максимальную строгость везде».

Нужны ли транзакции на несколько сущностей

Начните с простого вопроса: бывают ли операции, которые должны обновить сразу несколько таблиц/сущностей как единое целое.

Например, «создать заказ + уменьшить остаток + записать оплату». Если допускается промежуточное состояние (заказ создан, остаток ещё не списан), то можно жить с более мягкой консистентностью и компенсирующими действиями. Если нет — вам нужны транзакции на несколько сущностей и понятная модель изоляции.

Строгая консистентность или допускающая задержку

Сформулируйте, где «видеть сразу» критично (балансы, лимиты, права доступа), а где допустима задержка в секунды/минуты (рекомендации, аналитические витрины, счётчики просмотров). Часто получается гибрид: строгая консистентность на ядре и «с задержкой» на производных данных.

Ретраи, идемпотентность и конкурентные обновления

Сбои и таймауты неизбежны, поэтому повторные запросы (ретраи) должны быть безопасными. Для этого продумайте идемпотентность: ключ идемпотентности для платежа, уникальные ограничения, upsert вместо insert, дедупликацию событий.

При конкурентных обновлениях решите, что важнее: блокировки (проще, но могут снижать параллелизм) или версионирование/оптимистичные проверки (эффективнее при редких конфликтах, но требует обработки конфликтов на уровне приложения).

Восстановление после сбоев: RPO/RTO

Переведите «надёжно» в числа: сколько данных можно потерять (RPO) и как быстро система должна восстановиться (RTO). Эти требования напрямую влияют на репликацию, журналирование, кворумы и то, какую цену вы заплатите за доступность и строгую консистентность.

Запросы и индексы: главные драйверы производительности

Когда база «тормозит», причина чаще всего не в «не той» СУБД, а в том, какие запросы вы реально выполняете и какие индексы под них есть. Поэтому выбирать хранилище стоит, начиная с будущих запросов: они диктуют схему, индексы и иногда даже тип базы.

Сначала — карта запросов

Соберите 10–30 самых важных запросов: те, что будут выполняться часто и/или определяют время ответа продукта.

Обратите внимание:

• Какие поля чаще всего в фильтрах и сортировках (например, status, created_at, user_id). Частая сортировка без подходящего индекса быстро превращается в дорогие операции.
• Нужны ли сложные джойны и сколько их в цепочке. Если в типовом сценарии 4–6 таблиц в одной выборке — вам важны оптимизатор запросов и предсказуемые планы.
• Агрегации: группировки, окна, топ-N. Дашборды «за 7 дней по категориям» и рейтинги «топ-100» — разные по профилю нагрузки задачи и по требованиям к индексации.

Ограничения и индексы — это цена за скорость

Транзакционные ограничения (уникальность, внешние ключи) повышают качество данных, но добавляют работу на запись. То же касается индексов:

• каждый новый индекс ускоряет чтение, но делает вставки/обновления тяжелее и увеличивает объём хранения;
• «лишние» индексы незаметно превращаются в налог на запись и обслуживание.

План: эталонные запросы заранее

Составьте набор «эталонных» запросов до выбора СУБД:

1. Для каждого запроса зафиксируйте ожидаемый результат, параметры и допустимую задержку.
2. Опишите частоту (RPS) и долю чтений/записей.
3. Прогоните эти запросы на прототипе данных: так вы увидите, какая модель и какие индексы реально работают, а какие дают «красивую теорию» без выигрыша на практике.

Масштабирование и доступность под реальные SLA

SLA — это не абстрактные «99,9%», а конкретные ожидания: сколько минут простоя допустимо, какой RPO/RTO нужен, какие пики нагрузки должны переживать чтение и запись. От этих цифр зависит, нужна ли вам простая репликация, шардинг или мульти‑регион.

Горизонтальное масштабирование чтения и записи

Чтение чаще всего масштабируется проще: добавили реплики, развели трафик по read-only узлам. Но реплики не бесплатны — вы платите задержками и усложнением маршрутизации запросов.

Запись масштабировать сложнее: если один мастер упирается в CPU/IO, появляются варианты вроде шардинга, распределённых транзакций или смены архитектуры (например, очереди + асинхронные обработчики). Спросите себя: что именно «упирается» — количество транзакций, размер индексов, блокировки, IOPS?

Репликация, задержки и согласованность

Репликация почти всегда означает лаг между узлами. Проверьте, где вам критично «читать своё» сразу после записи, а где допустима eventual consistency. Иначе получите странные баги: пользователь сохранил данные и тут же «не видит» их в интерфейсе.

Шардинг: когда нужен и что усложняет

Шардинг оправдан, когда запись/объём больше не помещаются в один узел или окно обслуживания стало неприемлемым. Цена — сложнее запросы (особенно агрегаты и джойны), тяжелее миграции ключей, больше операционных ошибок.

Доступность и сценарии отказа

Один регион проще и дешевле, но мульти‑регион нужен, если SLA включает катастрофоустойчивость. Протестируйте отказы: обрыв сети, деградация диска, перегрузка CPU, «шумный сосед».

Наблюдаемость

Без метрик (latency p95/p99, лаг репликации, очередь блокировок), логов медленных запросов и алертов вы не докажете выполнение SLA и не поймёте, что ломается первым.

Комбинации хранилищ: когда одной СУБД недостаточно

Одна СУБД редко одинаково хорошо закрывает быстрые онлайн-записи, сложную аналитику, полнотекстовый поиск и «горячие» чтения. Комбинация хранилищ оправдана, когда вы можете чётко описать разные паттерны доступа и изолировать их, не раздувая операционные риски.

Разделение контуров: запись/чтение, онлайн/аналитика

Частый сценарий — «ядро» транзакций (OLTP) отдельно, а аналитические запросы и отчёты — в витрине/хранилище для OLAP. Так вы не блокируете кассовые операции тяжёлыми джойнами и агрегациями.

Похожий принцип работает и внутри онлайна: запись идёт в основной контур, а чтение — через реплики, кэш или подготовленные представления. Важно заранее договориться о допустимой задержке данных на чтении.

Кэш: что кэшировать и как инвалидировать

Кэш имеет смысл для «часто читаемого и редко меняемого»: карточки товаров, настройки, справочники, результаты тяжёлых вычислений.

Самая сложная часть — инвалидировать: по TTL, по событию (обновили сущность — сбросили ключи), либо через версионирование. Если вы не можете надёжно определить момент протухания, кэш начнёт вредить качеству данных.

Поиск отдельно от основной БД: когда оправдано

Полнотекстовый поиск, подсказки, ранжирование и фильтры по множеству полей часто лучше вынести в отдельный поисковый движок. Оправдано, когда поиск — критическая фича, а не «пара LIKE-запросов».

Событийные потоки и очереди как часть архитектуры доступа

Очереди и стримы помогают разводить запись и обработку: вы фиксируете событие в ядре, а индексы поиска, кэш, витрины и уведомления обновляются асинхронно. Это повышает устойчивость, но требует дисциплины: идемпотентность обработчиков и мониторинг отставания.

Материализованные представления и витрины данных

Если одни и те же агрегаты считаются снова и снова, выгоднее хранить их готовыми: материализованные представления, денормализованные таблицы или отдельные витрины. Ключевой вопрос — как часто их обновлять и насколько допустима «вчерашняя правда» для продукта.

Как принимать решение: матрица, POC и нагрузочные тесты

Выбор СУБД стоит превращать из «спора вкусов» в управляемое решение. Для этого достаточно трёх артефактов: матрицы требований, короткого POC и честных нагрузочных тестов. В итоге вы защищаете выбор цифрами и снижаете риск дорогой миграции.

1) Матрица требований

Соберите таблицу (хотя бы в Google Sheets), где по строкам — кандидаты (например, PostgreSQL, MySQL, ClickHouse, MongoDB), а по колонкам — критерии.

Обязательные блоки: доступность (SLA, RPO/RTO), консистентность и транзакции, производительность ключевых запросов, стоимость владения (инфраструктура + поддержка), операционные риски (сложность эксплуатации, дефицит компетенций), зрелость экосистемы (репликация, бэкапы, мониторинг).

Поставьте веса и заранее зафиксируйте «красные линии» (например, «нужны транзакции на несколько таблиц», «потеря данных недопустима»). Это быстро отсекает неподходящие варианты.

2) Минимальный POC под top‑10 запросов

POC не должен моделировать весь продукт. Возьмите 10 самых важных операций: 5 чтений и 5 записей (или как у вас устроено), создайте приближённую схему, индексы и загрузите реалистичный объём данных.

Важно: измеряйте не «красивые» запросы, а те, что будут в продакшене — с сортировками, фильтрами, пагинацией, агрегациями.

Если вам нужно быстро собрать такой прототип (API + простые экраны) и «пощупать» запросы на приближённых данных, удобно делать это в TakProsto.AI: платформа поддерживает вайб-кодинг через чат, умеет поднимать веб на React и бэкенд на Go с PostgreSQL, а ещё позволяет делать снапшоты и откат — полезно для итераций схемы и индексов во время POC.

3) Нагрузочные тесты и «плохие дни»

Сгенерируйте нагрузку, близкую к реальной: распределение по запросам, конкурентность, рост данных.

Отдельно проверьте сценарии деградации: пики трафика, холодные кэши, отвал реплики, деградация диска/сети. Хорошая СУБД — не та, что fastest в идеале, а та, что предсказуемо ведёт себя при сбоях.

Критерии успеха и фиксация выводов

Зафиксируйте пороги: p95/p99 латентности, throughput, время восстановления, а также операционные затраты (часы команды на сопровождение, сложность бэкапов и обновлений).

Итоги оформите как короткий документ: «что тестировали», «какие цифры получили», «почему выбрали», «когда пересматривать». Это поможет через год, когда паттерны доступа изменятся.

Миграции и эволюция: думать о выходе заранее

Выбор СУБД — не брак на всю жизнь. У продукта меняются паттерны чтения/записи, требования к задержкам и объёмы данных. Поэтому полезно заранее ответить на вопрос: как мы будем уходить (или расширяться) без остановки бизнеса.

Сначала — не миграция, а устранение узких мест

Не всегда «надо менять базу». Часто проблему решают дешевле и быстрее:

• пересмотр схемы (например, денормализация под частые чтения или выделение горячих полей);
• индексы и переписывание запросов (особенно по ORDER BY, диапазонам и фильтрам);
• кэш на чтение (включая precompute/материализованные представления, где уместно);
• разделение нагрузки: вынести аналитические запросы или отчёты в отдельное хранилище.

Миграция оправдана, когда паттерны доступа стабильно «упираются» в фундаментальные ограничения выбранной модели данных/консистентности/масштабирования, а не в настройки.

Стратегии миграции без простоя

Две рабочие тактики:

1. Параллельная запись (dual write): приложение пишет в старую и новую СУБД, пока новая не догонит по данным и стабильности.

2. Двойное чтение (dual read): часть запросов читает из новой СУБД, результаты сравниваются с эталоном (старой), затем трафик постепенно переключается.

Обе стратегии требуют дисциплины в обработке ошибок и чётких метрик качества.

Риски данных: расхождения неизбежны — ими нужно управлять

На практике всплывают: расхождения из‑за ретраев, разный порядок событий, повторная доставка сообщений. Нужны:

• идемпотентность операций и дедупликация (ключи идемпотентности, уникальные ограничения);
• правила разрешения конфликтов (какая запись «побеждает»);
• контроль порядка событий там, где он важен (sequence/версии, watermark’и).

Инструменты, совместимость и план отката

Проверьте заранее, поддерживаются ли привычные вещи: бэкапы/восстановление, репликация, мониторинг, алерты, аудит. Заложите точки контроля качества (сверка выборок, балансов, агрегатов) и план отката: как быстро вернуться на старую СУБД, не потеряв данные и не сломав клиентов.

Типичные ошибки выбора «по тренду» и как их избежать

Мода на технологии полезна как источник идей, но вредна как критерий выбора. Ниже — ошибки, которые чаще всего приводят к дорогим переделкам и «вечно медленной базе».

Ошибка 1: «Возьмём X, потому что все так делают»

Если за выбором нет списка сценариев чтения/записи, объёмов, требований к задержкам и отказоустойчивости — вы покупаете неизвестность.

Как избежать: зафиксируйте 10–20 ключевых запросов и операций записи, их частоту и SLO (например, p95 < 200 мс), а уже потом сравнивайте варианты.

Ошибка 2: перенос OLTP в аналитическое хранилище без разделения нагрузок

Аналитика любит тяжёлые сканы и агрегации, OLTP — быстрые точечные операции. Смешивание часто заканчивается блокировками, ростом задержек и «борьбой за ресурсы».

Как избежать: разделяйте контуры (операционное хранилище + витрина/реплика/ETL/стриминг), даже если сначала всё живёт в одном месте.

Ошибка 3: выбор по чужим бенчмаркам

Чужой тест редко повторяет ваши индексы, фильтры, распределение данных, долю чтения/записи и пики.

Как избежать: сделайте маленький POC на своих запросах и данных (пусть даже на 1–5% объёма), измеряйте p95/p99 и стоимость ресурса.

Ошибка 4: игнорирование стоимости владения

Дешёвый старт может обернуться дорогим хранением, бэкапами, сетевыми расходами, поддержкой и дефицитом компетенций.

Как избежать: считайте TCO: ресурсы, хранение, операции (резервное копирование, обновления), время команды и риски.

Как объяснить решение стейкхолдерам простыми словами

Формула: «Мы выбираем Х, потому что у нас такие операции (A, B, C), им нужны такие характеристики (задержка, консистентность, масштабирование), и по POC это даёт такие цифры и такую стоимость. Альтернативы Y/Z проигрывают по конкретным сценариям».

Итоги: практический алгоритм выбора базы данных

Выбирать СУБД стоит не по популярности и «как у всех», а от ваших паттернов чтения/записи, требований к консистентности и реальных SLA по задержкам, доступности и восстановлению. Тренды помогают узнать инструменты, но не подменяют постановку задачи.

Практический алгоритм (коротко)

1. Зафиксируйте SLA: p95/p99 задержки, RPO/RTO, окна простоя, рост нагрузки на 6–12 месяцев.

2. Опишите паттерны доступа: что читают/пишут, размер сущностей, частоту, «горячие» ключи, пиковые периоды.

3. Определите минимально нужную консистентность и границы транзакций: где обязателен ACID, а где допустима задержка согласования.

4. Составьте top‑10 запросов и top‑5 операций записи (включая массовые): с фильтрами, сортировками, пагинацией, агрегациями.

5. Подберите кандидатов и проверьте модель данных под паттерны: как будут выглядеть ключи, индексы, партиционирование.

6. Сделайте POC и нагрузочные тесты на данных, близких к боевым: измерьте задержки, конфликтность, стоимость ресурсов и операционную сложность.

Мини-чек-лист перед внедрением

• Есть прогноз роста и понятный «план Б» (репликация, шардирование, архивирование).
• Понятны индексы/ограничения, бэкапы, мониторинг, сценарии деградации.
• Подсчитана стоимость владения: люди, поддержка, инфраструктура, лицензии.

Что пересматривать по мере роста

Пересматривайте паттерны раз в квартал: новые отчёты (OLAP), увеличение доли чтения, появление очередей/событий, требования к аналитике и хранению истории.

Следующие шаги

Описать паттерны доступа, собрать top‑10 запросов, запланировать POC и нагрузочные тесты с критериями «прошло/не прошло» по SLA.