📌 НФТ в архитектуре: измеримые требования

«Система должна быть быстрой» — не НФТ. Без цифр и сценариев архитектурные решения не защитить ни перед техлидом, ни перед бизнесом.


👉 Что такое НФТ для аналитика:

Не список технологий, а критерии успеха системы в цифрах и сценариях.

Минимальный набор для архитектурного ТЗ:
▫️ Нагрузка — запросов в секунду, заказов в час, одновременных пользователей, рост на год
▫️ Задержка ответа — 95-й и 99-й перцентиль (не «среднее»)
▫️ Доступность — 99,9% ≈ 8,7 ч простоя в год; что допустимо
▫️ Время восстановления / допустимая потеря данных — сколько можно быть недоступными и что потерять
▫️ Безопасность — платёжные данные, персональные данные, аудит


👉 Как переводить бизнес-фразы в НФТ:

Схема: Бизнес говорит → Аналитик фиксирует
«Быстро» → 95-й перцентиль < 300 мс на оформлении при 500 запр/с
«Не должно падать» → 99,95% доступности, плавное снижение функций при отказе каталога
«Чёрная пятница» → Пик в 10 раз от среднего, 2 ч, автомасштабирование за 5 мин


👉 Зачем это влияет на архитектуру:

▫️ 99-й перцентиль 300 мс при 5 синхронных вызовах → нужна прослойка для фронта или параллельные запросы
▫️ Нулевая потеря заказов → синхронная репликация или исходящая таблица со строгим порядком
▫️ Пик в 10 раз → горизонтальное масштабирование слоя без состояния + кэш, не «больше процессора на монолите»


💡 На собеседовании: после условия задачи спроси «какие НФТ?» — это отделяет тех, кто рисует схемы, от тех, кто проектирует систему.

Курсы по архитектуре уже на финишной прямой

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

“Всё, что записывается второй раз, звучит и выглядит намного лучше” - написал автор курса, Владимир Бурмистров

Вот это как раз то, что мы применяем в подходе к курсам. Не просто записать урок, выложить и сказать "готово", а довести материал до состояния, когда его действительно удобно смотреть, понимать и применять

Поэтому сейчас мы не просто "обновляем курс", а фактически усиливаем архитектурную линейку: пересобираем материалы, практику, тесты и домашние задания так, чтобы после обучения оставалось не ощущение "я послушал про архитектуру", а понимание, как с этим работать!

Старт уже близко:

— «Архитектура систем. База» — 6 июля
— «Архитектура систем. Хард» — 27 июля

Актуальные программы уже можно посмотреть на сайте

Успевайте приобрести по предпродаже по выгодным условиям!

📝 Задача | Архитектура · Корзина и оформление заказа

Условие:

Интернет-магазин электроники. Пользователь кладёт товары в корзину, применяет промокод, выбирает доставку и оплачивает.

Вводные:
▫️ Средняя нагрузка 800 rps на каталог, в пик (распродажа) до 4000 rps на оформление
▫️ Каталог и остатки — разные сервисы; остатки обновляются с задержкой до 2 сек из складской системы
▫️ Промокоды проверяются во внешнем сервисе лояльности (95-й перцентиль 150 мс)
▫️ При оплате нельзя продать товар, которого нет на остатке — перепродажа недопустима
▫️ Корзина должна переживать закрытие вкладки (вернуться через день)

Задание:
1. Назови основные компоненты (4–7).
2. Где хранить корзину и почему (БД, брокер, кеш)
3. В какой момент резервировать/списывать остаток — при добавлении в корзину, при оформлении или при оплате? Обоснуй.
4. Что кэшировать и с каким временем жизни?


⏱️ Попробуй решить сам.
Разбор опубликуем 24.06.

Пиши ответ в комментариях 👇

Я немного боюсь этого проекта. И очень его хочу

Сейчас обсуждаем корпоративное обучение для одной известной компании. Название пока не раскрываю, но масштаб там такой, что я одновременно радуюсь и думаю:

«Оля, ну ты точно готова?» 😄

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

Такой подход мне нравится. Мы сейчас собираем программу под их задачи: выбираем только нужные темы, продумываем воркшопы, Q&A-сессии и практику, чтобы обучение было не для галочки, а реально закрывало пробелы

Я очень хочу, чтобы больше компаний так подходили к развитию аналитиков. Не «ну купим доступ к курсу», а сначала понять, где команда проседает, и под это собрать обучение

Если у вас в компании аналитиков много, а общей базы и единого подхода не хватает — возможно, это знак показать этот пост руководителю 🙂

Оставить заявку на корпоративное обучение

✅ Решение | Архитектура · Корзина и оформление

Краткий ответ:

Шлюз → сервис корзины (Redis) + каталог + остатки + лояльность + заказ + оплата. Резерв остатка — при переходе к оплате, списание — после успешной оплаты. Кэш — каталог и цены, не остатки.


📖 Разбор:

1️⃣ Компоненты

▫️ Шлюз / прослойка для фронта — агрегация для веба и мобилки, ограничение частоты на оформлении
▫️ Сервис корзины — корзина пользователя, время жизни 7–14 дней
▫️ Сервис каталога — товары, цены, медиа
▫️ Сервис остатков — складские остатки, резервы, единственный источник правды по артикулу
▫️ Лояльность — внешняя проверка промокодов
▫️ Заказ + оплата — создание заказа, оплата, сага при сбоях


2️⃣ Где хранить корзину

Redis (или аналог) с ключом по идентификатору пользователя:
▫️ Быстрые чтение и запись при высокой нагрузке
▫️ Время жизни для «брошенных» корзин
▫️ Не смешивать с транзакционными заказами в PostgreSQL

Для гостя — ключ по сессии с объединением при входе в аккаунт.


3️⃣ Когда резервировать остаток

Добавление в корзину
+ «Мягкая» бронь
- Тысячи мёртвых резервов, перепродажа при задержке склада

Оформление (перед оплатой)
+ Баланс удобства и точности
- Нужен срок резерва 10–15 мин

После оплаты
+ Просто
- Перепродажа на этапе оплаты — нельзя по НФТ

Оптимально: нажатии «Оформить» — синхронный резерв в сервисе остатков со сроком; при успешной оплате — подтверждение; при таймауте/отмене — снятие резерва. В корзину — только проверка «есть ли хоть что-то» без жёсткой брони.


4️⃣ Кэш

▫️ Каталог, цены, картинки — сеть доставки контента + Redis, время жизни 5–60 мин, сброс по событию
▫️ Остатки — не кэшировать на пути оформления; читать остатки напрямую при резерве
▫️ Промокод — не кэшировать надолго; короткое время жизни или только на шаге применения


❌ Типичные ошибки:

▫️ Резерв при добавлении в корзину на 4000 rps — склад «заморожен» чужими корзинами
▫️ Кэш остатков с задержкой 2 сек + оплата без резерва = перепродажа
▫️ Всё в одной БД монолита без ограничения частоты на оформлении — падение при пике


💡 Связывай решение с НФТ из условия: 4000 rps, задержка 2 сек, запрет перепродажи.

📂 Кейс: кэш спас скорость — и чуть не убил согласованность цен

🏢 Контекст:

Онлайн-аптека, 1,5 млн артикулов. Сервис каталога отдаёт карточку товара. После кэша в Redis 95-й перцентиль упал с 420 мс до 40 мс. Бизнес доволен. Через две недели — жалобы: в корзине одна цена, на оплате другая.


😬 Проблема:

Аналитик в ТЗ написал: «Кэшировать ответ карточки товара на 24 часа». Разработчики закэшировали весь ответ, включая поле «цена». Маркетинг обновил цены в БД в 09:00, пользователи до следующего дня видели старую цену в каталоге; при оформлении цена бралась из актуальной таблицы заказа — расхождение.


🔍 Что сделали:

1. Разделили кэшируемые поля: статика (название, фото) — долгое время жизни; цена — короткое (60 сек) или отдельный ключ по артикулу
2. Добавили сброс кэша по событию «цена изменилась» из админки
3. В контракт прослойки для фронта: на шаге оформления пересчёт цены с сервера, интерфейс показывает «цена обновлена» при расхождении
4. В ТЗ явно: «источник правды цены при оплате — сервис ценообразования, не кэш каталога»


✅ Результат:

Жалобы исчезли. 95-й перцентиль каталога — 55 мс (чуть выше, но в рамках НФТ). Аналитик добавил в шаблон ТЗ секцию «политика кэширования по полям».


💡 Выводы:

▫️ Кэш — архитектурное решение с бизнес-последствиями, не только про скорость
▫️ В ТЗ указывай: что кэшируем, срок жизни, сброс, что нельзя кэшировать на критичном пути
▫️ «Согласованность цены» — НФТ, которое ломается тихо