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

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

Шлюз → сервис корзины (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 мс (чуть выше, но в рамках НФТ). Аналитик добавил в шаблон ТЗ секцию «политика кэширования по полям».


💡 Выводы:

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

Ученица объяснила ценность курса лучше меня 😄

Недавно ездила на ЛАФ (летний аналитический фестиваль). Ехали за город на машине небольшой компанией, и среди нас была моя ученица. По дороге она рассказывала другой девушке про мой курс по ИИ для аналитиков

Что именно рассказывала, честно, не знаю 😅Но у девушки была очень знакомая многим аналитикам боль: документация есть, требований много, а уверенности, что нигде не спрятались противоречия, пробелы или забытые сценарии - нет

В какой-то момент разговор закончился тем, что курс купили прямо по дороге😅

Через неделю я написала ей: "Ну как успехи?" И получила ответ, после которого сидела и улыбалась весь вечер. Курс уже окупился. Оказалось, что она начала использовать Cursor в рабочих задачах: проверять документы на противоречия, искать пробелы в требованиях, разбирать нормативку, писать критерии приёмки и просто контролировать, чтобы в процессе ничего важного не потерялось

И вот это для меня самое ценное. Не потому что «ура, купили курс», а потому что сработала самая честная рекомендация: один аналитик увидел рабочую боль другого аналитика и сказал: «кажется, тебе это поможет». И реально помогло!

Мне вообще кажется, что самые сильные рекомендации всегда именно такие. Не из рекламы, не из прогревов, а из реального рабочего опыта

📊 Опрос: Масштабирование и отказоустойчивость

4 вопроса про реплики, кэш, шардирование и предохранитель цепи. Отвечай в комментариях — разбор сразу после вопроса


Бесплатный вебинар 30 июня 19:00 мск
"Пошаговый гайд по System Design"

Финальный урок записан. Мы готовы к ученикам!

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

Отдельно докрутила шпаргалки, примеры и задания, чтобы это было не «посмотрел и забыл», а можно было применять в работе

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

1 поток стартует уже 6 июля, в понедельник!
До конца июня можно попасть со скидкой 15% по промокоду JUNE15

👉Подробнее о курсе

Успевайте попасть в первый поток😎