Масштабирование, кэширование, согласованность, микросервисы и оценка нагрузки.
Домен в центре и не зависит ни от чего внешнего. Он объявляет порты — интерфейсы на своём языке: входящие (сценарии использования) и исходящие (OrderRepository, PaymentGateway)…
Вертикальное (scale up) — мощнее одна машина; горизонтальное (scale out) — больше машин под балансировщиком.
При разделении сети (P) распределённая система выбирает: отвечать, рискуя отдать устаревшее (A), или отказать, сохранив согласованность (C).
Если записи прекратятся, все реплики со временем придут к одному значению. Сразу после записи разные клиенты могут видеть разное.
Кэш хранит результат дорогой операции ближе к потребителю: меньше задержка и нагрузка на источник. Главные риски — устаревшие данные и зависимость от кэша.
CDN — сеть серверов по миру, которые кэшируют контент рядом с пользователями: меньше задержка и нагрузка на исходный сервер (origin).
Сбои неизбежны, поэтому: таймауты на каждый вызов, повторы с отсрочкой и джиттером, идемпотентность операций, чтобы повтор был безопасен, circuit breaker против долгих отказов и…
По порядку от дешёвого к дорогому: оптимизировать запросы и индексы → кэш → реплики для чтения → денормализация и модели чтения → шардирование.
Микросервисы решают организационную задачу — независимую разработку и выкатку многими командами, а не задачу производительности.
По ограниченным контекстам (bounded context) и бизнес-возможностям: типичный сценарий должен выполняться внутри одного сервиса.
Цена распределённой системы уплачена, а независимость не получена: общий релиз, общая база, синхронные цепочки, общая библиотека моделей.
В синхронной цепочке доступности перемножаются: 0,999⁵ ≈ 0,995. Простой вырастает впятеро — с ~43 минут до ~3,6 часа в месяц.
Своя база нужна ради независимого изменения схемы и защиты инвариантов: только владелец пишет в свои данные по своим правилам. Дело не в нагрузке.
Модульный монолит: границы внутри процесса стоят дёшево и переносятся рефакторингом, а границы сервисов закрепляются сетевым контрактом и стоят дорого.
Идемпотентны GET, HEAD, OPTIONS, PUT, DELETE: повтор запроса оставляет сервер в том же состоянии. POST и обычно PATCH — нет.
Клиент генерирует ключ идемпотентности (UUID) на операцию и передаёт его в заголовке; сервер сохраняет ключ и результат в одной транзакции с созданием заказа и на повтор…
OFFSET заставляет базу пройти и отбросить N строк — чем глубже страница, тем медленнее; а вставки между запросами сдвигают окно — отсюда дубли и пропуски. Решение — keyset…
Добавлять можно (новое необязательное поле в ответе, новый эндпоинт, новый необязательный параметр); удалять, переименовывать, менять тип и ужесточать — нельзя.
Главный вопрос: нужен ли ответ немедленно, чтобы продолжить? Нужен — синхронный вызов (REST, gRPC). Не нужен — событие через брокер.
По уровням: дисциплина совместимых изменений → схема как источник истины → автоматическая проверка совместимости в CI → контрактные тесты от потребителей.
CQRS — разные модели для записи (команды) и чтения (запросы): запись защищает инварианты на нормализованной модели, чтение берёт денормализованные представления под экраны.
Это независимые решения, которые часто применяют вместе. CQRS — разделение моделей чтения и записи; event sourcing — хранение изменений как неизменяемого журнала событий вместо…
Обязательная механика: снапшоты (не проигрывать миллион событий), оптимистичная блокировка по версии потока (конкурентные команды), версионирование и апкастинг событий. Записанные…
Отставание модели чтения — свойство полного CQRS, а не дефект: его закладывают в продукт и интерфейс.
Проекция строит модель чтения из потока событий. Требования: идемпотентность, порядок внутри агрегата (партиционирование по его id), наблюдаемое отставание и возможность…
Не нужно в CRUD-домене, при требовании немедленной согласованности и без опыта эксплуатации асинхронных конвейеров. Вводить по нарастающей и точечно.
Мониторинг отвечает на заранее известные вопросы (дашборды и алерты под известные отказы). Наблюдаемость — свойство системы отвечать на непредусмотренные вопросы по её телеметрии.
Каждая уникальная комбинация меток — отдельный временной ряд. Метка с user_id превращает одну метрику в миллионы рядов: растут память, диск и время запросов, система мониторинга…
Смотрим перцентили (p50, p95, p99), а не среднее; перцентили не усредняются — считаем из гистограмм; успешные и ошибочные запросы — раздельно.
Бюджет ошибок = 100% − SLO. При SLO 99,9% за 30 дней можно «потратить» ~43 минуты недоступности. Это инструмент решений: бюджет есть — выкатываем смелее, кончился — приоритет…
Алертить на симптомы (пользователям плохо: ошибки, задержка, нарушение SLO), а не на причины (CPU 90%). Высокая загрузка может быть нормой.
Метрики показывают, где и когда выросло; трейсы — в каком шаге ушло время; логи по trace_id — почему. Работает, только если корреляция построена заранее.
Во время выкатки работают обе версии, поэтому совместимость нужна в обе стороны: старая переживает данные и запросы новой, новая — старой.
Expand–contract в пять шагов: добавить full_name → писать в обе колонки → перелить старые данные порциями → читать из новой → удалить name отдельным поздним релизом.
Флаги отделяют выкатку кода от включения функции: код едет в прод выключенным, включение и откат — за секунды, без деплоя.
Blue-green — второй полный комплект и переключение всего трафика разом: мгновенный откат, но ошибку сразу видят все. Canary — новая версия на малую долю трафика, сравнение метрик…
Миграция и код — разными релизами; схема меняется через expand–contract; необратимые шаги (удаление колонок, данных) — в самом конце и с задержкой.
Проверено «кто ты» (аутентификация), но не «можно ли тебе этот заказ» (авторизация): любой вошедший пользователь читает чужие заказы, перебирая id. Это IDOR — Broken Access…
JWT самодостаточен — сервер проверяет подпись без базы. Отсюда главный минус: его нельзя отозвать до истечения. Решение — короткий access-токен (минуты) и отзываемый refresh…
SHA-256 быстрый — это хорошо для контрольных сумм и плохо для паролей: утёкшую базу перебирают миллиардами вариантов в секунду. bcrypt, scrypt и argon2 намеренно медленные и…
Секрет в истории git — утёк. Единственное надёжное действие — отозвать и перевыпустить (ротация), затем проверить журналы использования ключа.
Всё, что попадает в продукт извне: зависимости (включая транзитивные), артефакты сборки, образы, сам конвейер CI/CD. В OWASP Top 10:2025 — отдельная категория A03.
По слоям: контроль доступа → аутентификация → ввод и транспорт → что отдаём наружу → эксплуатация.
10 млн × 20 = 200 млн запросов в сутки; в сутках ≈ 10⁵ секунд → ~2 000 QPS в среднем; пиковость 3 → ~6 000 QPS.
Важны соотношения: память ~100 нс, SSD ~100 мкс (в тысячу раз медленнее), HDD ~10 мс (ещё в сто), сеть внутри дата-центра ~0,5 мс, другой континент ~100+ мс.
10⁸ × 1 КБ = 100 ГБ в сутки → ~36 ТБ в год → ~100 ТБ с тройной репликацией. Чаще всего забывают множитель репликации.
Ничего хорошего: узкое место — база (пул соединений занят, CPU приложения свободен). Новые экземпляры добавят соединений и конкуренции за ту же базу — может стать даже хуже.
Сначала вопросы и допущения вслух, потом цепочка от аудитории к QPS, хранению и трафику, и обязательно вывод: где узкое место и что из этого следует для архитектуры.
При hash % N смена N переносит почти все ключи; на кольце consistent hashing переезжает только ~1/N — ключи с дуги нового или ушедшего узла.
Stateless — состояние не в памяти экземпляра, а в базе, кэше, брокере или токене. Экземпляры взаимозаменяемы: запрос можно отправить в любой.
Если R + W > N, множества реплик для чтения и записи пересекаются — чтение застанет хотя бы одну реплику с последней подтверждённой записью.
Согласованность — спектр: между линеаризуемостью и итоговой лежат read-your-writes, монотонные чтения, причинная согласованность.
Write-through — запись синхронно в кэш и хранилище: согласованно и надёжно, но каждая запись медленная. Write-back — запись в кэш, в хранилище позже: быстро и объединяет…
Сложно из-за зависимостей: кэшированное значение собрано из нескольких сущностей, и отследить все ключи, затронутые изменением строки, трудно.
Закрыт — вызовы идут, ошибки считаются; порог превышен — открыт: вызовы сразу отклоняются; после паузы — полуоткрыт: несколько пробных вызовов решают, закрыться или снова…
Проблема двойной записи: между коммитом в базу и отправкой в брокер можно упасть. Outbox пишет событие строкой в ту же транзакцию, а отдельный процесс публикует его в брокер.
Частичный отказ лучше полного: сбрасывать лишнюю нагрузку, отключать второстепенное, отдавать устаревшие данные.
C — согласованность (каждое чтение видит последнюю запись), A — доступность (каждый запрос получает ответ), P — устойчивость к разделению сети.
Операция идемпотентна, если состояние после одного и нескольких выполнений одинаково — повтор безопасен.
Система из независимо развёртываемых сервисов, каждый владеет своими данными и отвечает за бизнес-возможность. Ключевое — независимость, а не размер.
REST — Representational State Transfer: ресурсы адресуются URL, действия выражаются методами HTTP, клиент работает с представлениями ресурсов.
Команды меняют состояние, запросы возвращают данные — и модели для них разные.
Метрики — дешёвые агрегаты для алертов и трендов; логи — подробности событий; трейсы — путь одного запроса через сервисы.
Экземпляры заменяются постепенно: поднимается новый, проходит readiness, старый снимается. Сервис отвечает всё время.
Аутентификация — «кто ты» (проверка личности); авторизация — «что тебе можно» (проверка прав на действие и ресурс).
В сутках 86 400 с → 8,64 млн / 86 400 = 100 QPS.
Мешает всё, что привязывает запрос или работу к экземпляру: сессии в памяти, файлы на локальном диске, локальный кэш изменяемых данных, планировщик задач без координации.
Перекос создаёт сам ключ: данные крупного клиента по определению в одном шарде. Добавление шардов не поможет — лечат гранулярностью ключа и выделением тяжёлых клиентов.
Ограничение не в приложении: нужно разложить время запроса и найти насыщенный общий ресурс — чаще всего база или пул соединений.
Кворум гарантирует свежесть, но не порядок: прерванные и конкурентные записи, а также нестрогий кворум ломают линеаризуемость.
Требование несимметрично: автору — чтение своих записей, остальным — согласованность в конечном счёте. Линеаризуемость на всех чтениях ленты не нужна и дорога.
Популярный ключ истёк — сотни запросов разом идут в базу. Защита: разброс TTL, пересчёт в один поток (single flight), выдача устаревшего с фоновым обновлением.
Гонка: читатель прочитал старое из базы, писатель обновил базу и кэш, читатель записал старое поверх. Лечится удалением ключа вместо перезаписи плюс TTL и версиями.
Разделить данные по требуемой свежести: картинки и статика — CDN с версионированными именами; описания — кэш на десятки минут; цена и остаток — отдельный ключ с коротким TTL и…
Медленная зависимость выедает общий пул потоков и соединений: каждый запрос держит поток в 150 раз дольше, и сервис перестаёт обслуживать даже страницы без оплаты.
Повторы умножаются по цепочке: 3 уровня × 3 попытки = до 27 запросов вниз. Кратковременная деградация превращается в отказ.
sotto слышит вопрос и сразу показывает короткий ответ. Оставьте контакт — пришлём доступ и промокод.
sotto