Курсы по архитектуре уже на финишной прямой
Сейчас у нас тот самый этап подготовки курса, который обычно не видно снаружи: уроки записываются, потом пересматриваются, потом часть уроков перезаписывается заново, тесты разделяются, домашки проверяются, вопросы докидываются, формулировки докручиваются
Вот это как раз то, что мы применяем в подходе к курсам. Не просто записать урок, выложить и сказать "готово", а довести материал до состояния, когда его действительно удобно смотреть, понимать и применять
Поэтому сейчас мы не просто "обновляем курс", а фактически усиливаем архитектурную линейку: пересобираем материалы, практику, тесты и домашние задания так, чтобы после обучения оставалось не ощущение "я послушал про архитектуру", а понимание, как с этим работать!
Старт уже близко:
— «Архитектура систем. База» — 6 июля
— «Архитектура систем. Хард» — 27 июля
Актуальные программы уже можно посмотреть на сайте
Успевайте приобрести по предпродаже по выгодным условиям!
Сейчас у нас тот самый этап подготовки курса, который обычно не видно снаружи: уроки записываются, потом пересматриваются, потом часть уроков перезаписывается заново, тесты разделяются, домашки проверяются, вопросы докидываются, формулировки докручиваются
“Всё, что записывается второй раз, звучит и выглядит намного лучше” - написал автор курса, Владимир Бурмистров
Вот это как раз то, что мы применяем в подходе к курсам. Не просто записать урок, выложить и сказать "готово", а довести материал до состояния, когда его действительно удобно смотреть, понимать и применять
Поэтому сейчас мы не просто "обновляем курс", а фактически усиливаем архитектурную линейку: пересобираем материалы, практику, тесты и домашние задания так, чтобы после обучения оставалось не ощущение "я послушал про архитектуру", а понимание, как с этим работать!
Старт уже близко:
— «Архитектура систем. База» — 6 июля
— «Архитектура систем. Хард» — 27 июля
Актуальные программы уже можно посмотреть на сайте
Успевайте приобрести по предпродаже по выгодным условиям!
❤8🔥1
📝 Задача | Архитектура · Корзина и оформление заказа
Условие:
Интернет-магазин электроники. Пользователь кладёт товары в корзину, применяет промокод, выбирает доставку и оплачивает.
Вводные:
▫️ Средняя нагрузка 800 rps на каталог, в пик (распродажа) до 4000 rps на оформление
▫️ Каталог и остатки — разные сервисы; остатки обновляются с задержкой до 2 сек из складской системы
▫️ Промокоды проверяются во внешнем сервисе лояльности (95-й перцентиль 150 мс)
▫️ При оплате нельзя продать товар, которого нет на остатке — перепродажа недопустима
▫️ Корзина должна переживать закрытие вкладки (вернуться через день)
Задание:
1. Назови основные компоненты (4–7).
2. Где хранить корзину и почему (БД, брокер, кеш)
3. В какой момент резервировать/списывать остаток — при добавлении в корзину, при оформлении или при оплате? Обоснуй.
4. Что кэшировать и с каким временем жизни?
⏱️ Попробуй решить сам.
Разбор опубликуем 24.06.
Пиши ответ в комментариях 👇
Условие:
Интернет-магазин электроники. Пользователь кладёт товары в корзину, применяет промокод, выбирает доставку и оплачивает.
Вводные:
▫️ Средняя нагрузка 800 rps на каталог, в пик (распродажа) до 4000 rps на оформление
▫️ Каталог и остатки — разные сервисы; остатки обновляются с задержкой до 2 сек из складской системы
▫️ Промокоды проверяются во внешнем сервисе лояльности (95-й перцентиль 150 мс)
▫️ При оплате нельзя продать товар, которого нет на остатке — перепродажа недопустима
▫️ Корзина должна переживать закрытие вкладки (вернуться через день)
Задание:
1. Назови основные компоненты (4–7).
2. Где хранить корзину и почему (БД, брокер, кеш)
3. В какой момент резервировать/списывать остаток — при добавлении в корзину, при оформлении или при оплате? Обоснуй.
4. Что кэшировать и с каким временем жизни?
⏱️ Попробуй решить сам.
Разбор опубликуем 24.06.
Пиши ответ в комментариях 👇
🔥1👌1
Команда 💛👩👩👦
А школа начинается там, где появляются люди, которым тоже не всё равно. Кто проверяет домашки не для галочки, разруливает сложные ситуации, видит косяки, предлагает идеи и может честно сказать: «Оль, тут надо переделать»
За несколько лет мы, конечно, ошибались с людьми. Иногда быстро понимали: не совпали по подходу, ответственности, вниманию к деталям. Но зато когда находишь своих - это прям отдельное счастье
🪿 Вчера был год, как со мной работает моя ассистентка/менеджер. Я отправила ей тортик с кофе, а она написала, что у нас самая лучшая команда. И я такая: ну всё, можно немного всплакнуть и дальше работать 😄
Наверное, один из главных выводов за годы школы: качество делают не только программы курсов. Качество делают люди
И моя команда - одна из главных причин, почему школа вообще стала школой
❤️ - если хочется больше узнавать о нашей команде и кто стоит за "школой"
В какой-то момент я поняла: школа держится не только на курсах, лендингах и моём желании сделать всё хорошо. Без команды это был бы просто мой личный проект, который я тащу на себе
А школа начинается там, где появляются люди, которым тоже не всё равно. Кто проверяет домашки не для галочки, разруливает сложные ситуации, видит косяки, предлагает идеи и может честно сказать: «Оль, тут надо переделать»
За несколько лет мы, конечно, ошибались с людьми. Иногда быстро понимали: не совпали по подходу, ответственности, вниманию к деталям. Но зато когда находишь своих - это прям отдельное счастье
Наверное, один из главных выводов за годы школы: качество делают не только программы курсов. Качество делают люди
И моя команда - одна из главных причин, почему школа вообще стала школой
❤️ - если хочется больше узнавать о нашей команде и кто стоит за "школой"
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20🔥4
Я немного боюсь этого проекта. И очень его хочу
Сейчас обсуждаем корпоративное обучение для одной известной компании. Название пока не раскрываю, но масштаб там такой, что я одновременно радуюсь и думаю:
Запрос у них очень правильный: они не просто хотят «курс для аналитиков». Они увидели, где у команды проседают знания, и пришли с конкретным списком: что аналитики должны знать и уметь
Такой подход мне нравится. Мы сейчас собираем программу под их задачи: выбираем только нужные темы, продумываем воркшопы, Q&A-сессии и практику, чтобы обучение было не для галочки, а реально закрывало пробелы
Я очень хочу, чтобы больше компаний так подходили к развитию аналитиков. Не «ну купим доступ к курсу», а сначала понять, где команда проседает, и под это собрать обучение
Если у вас в компании аналитиков много, а общей базы и единого подхода не хватает — возможно, это знак показать этот пост руководителю 🙂
Оставить заявку на корпоративное обучение
Сейчас обсуждаем корпоративное обучение для одной известной компании. Название пока не раскрываю, но масштаб там такой, что я одновременно радуюсь и думаю:
«Оля, ну ты точно готова?» 😄
Запрос у них очень правильный: они не просто хотят «курс для аналитиков». Они увидели, где у команды проседают знания, и пришли с конкретным списком: что аналитики должны знать и уметь
Такой подход мне нравится. Мы сейчас собираем программу под их задачи: выбираем только нужные темы, продумываем воркшопы, Q&A-сессии и практику, чтобы обучение было не для галочки, а реально закрывало пробелы
Я очень хочу, чтобы больше компаний так подходили к развитию аналитиков. Не «ну купим доступ к курсу», а сначала понять, где команда проседает, и под это собрать обучение
Если у вас в компании аналитиков много, а общей базы и единого подхода не хватает — возможно, это знак показать этот пост руководителю 🙂
Оставить заявку на корпоративное обучение
❤15👍6
✅ Решение | Архитектура · Корзина и оформление
Краткий ответ:
Шлюз → сервис корзины (Redis) + каталог + остатки + лояльность + заказ + оплата. Резерв остатка — при переходе к оплате, списание — после успешной оплаты. Кэш — каталог и цены, не остатки.
📖 Разбор:
1️⃣ Компоненты
▫️ Шлюз / прослойка для фронта — агрегация для веба и мобилки, ограничение частоты на оформлении
▫️ Сервис корзины — корзина пользователя, время жизни 7–14 дней
▫️ Сервис каталога — товары, цены, медиа
▫️ Сервис остатков — складские остатки, резервы, единственный источник правды по артикулу
▫️ Лояльность — внешняя проверка промокодов
▫️ Заказ + оплата — создание заказа, оплата, сага при сбоях
2️⃣ Где хранить корзину
Redis (или аналог) с ключом по идентификатору пользователя:
▫️ Быстрые чтение и запись при высокой нагрузке
▫️ Время жизни для «брошенных» корзин
▫️ Не смешивать с транзакционными заказами в PostgreSQL
Для гостя — ключ по сессии с объединением при входе в аккаунт.
3️⃣ Когда резервировать остаток
Добавление в корзину
+ «Мягкая» бронь
- Тысячи мёртвых резервов, перепродажа при задержке склада
Оформление (перед оплатой)
+ Баланс удобства и точности
- Нужен срок резерва 10–15 мин
После оплаты
+ Просто
- Перепродажа на этапе оплаты — нельзя по НФТ
Оптимально: нажатии «Оформить» — синхронный резерв в сервисе остатков со сроком; при успешной оплате — подтверждение; при таймауте/отмене — снятие резерва. В корзину — только проверка «есть ли хоть что-то» без жёсткой брони.
4️⃣ Кэш
▫️ Каталог, цены, картинки — сеть доставки контента + Redis, время жизни 5–60 мин, сброс по событию
▫️ Остатки — не кэшировать на пути оформления; читать остатки напрямую при резерве
▫️ Промокод — не кэшировать надолго; короткое время жизни или только на шаге применения
❌ Типичные ошибки:
▫️ Резерв при добавлении в корзину на 4000 rps — склад «заморожен» чужими корзинами
▫️ Кэш остатков с задержкой 2 сек + оплата без резерва = перепродажа
▫️ Всё в одной БД монолита без ограничения частоты на оформлении — падение при пике
💡 Связывай решение с НФТ из условия: 4000 rps, задержка 2 сек, запрет перепродажи.
Краткий ответ:
Шлюз → сервис корзины (Redis) + каталог + остатки + лояльность + заказ + оплата. Резерв остатка — при переходе к оплате, списание — после успешной оплаты. Кэш — каталог и цены, не остатки.
📖 Разбор:
1️⃣ Компоненты
▫️ Шлюз / прослойка для фронта — агрегация для веба и мобилки, ограничение частоты на оформлении
▫️ Сервис корзины — корзина пользователя, время жизни 7–14 дней
▫️ Сервис каталога — товары, цены, медиа
▫️ Сервис остатков — складские остатки, резервы, единственный источник правды по артикулу
▫️ Лояльность — внешняя проверка промокодов
▫️ Заказ + оплата — создание заказа, оплата, сага при сбоях
2️⃣ Где хранить корзину
Redis (или аналог) с ключом по идентификатору пользователя:
▫️ Быстрые чтение и запись при высокой нагрузке
▫️ Время жизни для «брошенных» корзин
▫️ Не смешивать с транзакционными заказами в PostgreSQL
Для гостя — ключ по сессии с объединением при входе в аккаунт.
3️⃣ Когда резервировать остаток
Добавление в корзину
+ «Мягкая» бронь
- Тысячи мёртвых резервов, перепродажа при задержке склада
Оформление (перед оплатой)
+ Баланс удобства и точности
- Нужен срок резерва 10–15 мин
После оплаты
+ Просто
- Перепродажа на этапе оплаты — нельзя по НФТ
Оптимально: нажатии «Оформить» — синхронный резерв в сервисе остатков со сроком; при успешной оплате — подтверждение; при таймауте/отмене — снятие резерва. В корзину — только проверка «есть ли хоть что-то» без жёсткой брони.
4️⃣ Кэш
▫️ Каталог, цены, картинки — сеть доставки контента + Redis, время жизни 5–60 мин, сброс по событию
▫️ Остатки — не кэшировать на пути оформления; читать остатки напрямую при резерве
▫️ Промокод — не кэшировать надолго; короткое время жизни или только на шаге применения
❌ Типичные ошибки:
▫️ Резерв при добавлении в корзину на 4000 rps — склад «заморожен» чужими корзинами
▫️ Кэш остатков с задержкой 2 сек + оплата без резерва = перепродажа
▫️ Всё в одной БД монолита без ограничения частоты на оформлении — падение при пике
💡 Связывай решение с НФТ из условия: 4000 rps, задержка 2 сек, запрет перепродажи.
🔥6👍1
📂 Кейс: кэш спас скорость — и чуть не убил согласованность цен
🏢 Контекст:
Онлайн-аптека, 1,5 млн артикулов. Сервис каталога отдаёт карточку товара. После кэша в Redis 95-й перцентиль упал с 420 мс до 40 мс. Бизнес доволен. Через две недели — жалобы: в корзине одна цена, на оплате другая.
😬 Проблема:
Аналитик в ТЗ написал: «Кэшировать ответ карточки товара на 24 часа». Разработчики закэшировали весь ответ, включая поле «цена». Маркетинг обновил цены в БД в 09:00, пользователи до следующего дня видели старую цену в каталоге; при оформлении цена бралась из актуальной таблицы заказа — расхождение.
🔍 Что сделали:
1. Разделили кэшируемые поля: статика (название, фото) — долгое время жизни; цена — короткое (60 сек) или отдельный ключ по артикулу
2. Добавили сброс кэша по событию «цена изменилась» из админки
3. В контракт прослойки для фронта: на шаге оформления пересчёт цены с сервера, интерфейс показывает «цена обновлена» при расхождении
4. В ТЗ явно: «источник правды цены при оплате — сервис ценообразования, не кэш каталога»
✅ Результат:
Жалобы исчезли. 95-й перцентиль каталога — 55 мс (чуть выше, но в рамках НФТ). Аналитик добавил в шаблон ТЗ секцию «политика кэширования по полям».
💡 Выводы:
▫️ Кэш — архитектурное решение с бизнес-последствиями, не только про скорость
▫️ В ТЗ указывай: что кэшируем, срок жизни, сброс, что нельзя кэшировать на критичном пути
▫️ «Согласованность цены» — НФТ, которое ломается тихо
🏢 Контекст:
Онлайн-аптека, 1,5 млн артикулов. Сервис каталога отдаёт карточку товара. После кэша в Redis 95-й перцентиль упал с 420 мс до 40 мс. Бизнес доволен. Через две недели — жалобы: в корзине одна цена, на оплате другая.
😬 Проблема:
Аналитик в ТЗ написал: «Кэшировать ответ карточки товара на 24 часа». Разработчики закэшировали весь ответ, включая поле «цена». Маркетинг обновил цены в БД в 09:00, пользователи до следующего дня видели старую цену в каталоге; при оформлении цена бралась из актуальной таблицы заказа — расхождение.
🔍 Что сделали:
1. Разделили кэшируемые поля: статика (название, фото) — долгое время жизни; цена — короткое (60 сек) или отдельный ключ по артикулу
2. Добавили сброс кэша по событию «цена изменилась» из админки
3. В контракт прослойки для фронта: на шаге оформления пересчёт цены с сервера, интерфейс показывает «цена обновлена» при расхождении
4. В ТЗ явно: «источник правды цены при оплате — сервис ценообразования, не кэш каталога»
✅ Результат:
Жалобы исчезли. 95-й перцентиль каталога — 55 мс (чуть выше, но в рамках НФТ). Аналитик добавил в шаблон ТЗ секцию «политика кэширования по полям».
💡 Выводы:
▫️ Кэш — архитектурное решение с бизнес-последствиями, не только про скорость
▫️ В ТЗ указывай: что кэшируем, срок жизни, сброс, что нельзя кэшировать на критичном пути
▫️ «Согласованность цены» — НФТ, которое ломается тихо
👍8❤4
«Пошаговый гайд по System Design»
30 июня в 19:00 проведем бесплатный вебинар
На вебинаре разберём:
— что такое System Design и из каких этапов он состоит;
— как подойти к проектированию системы пошагово;
— зачем System Design спрашивают на собеседованиях и как пройти эту секцию;
— какие ошибки можно допустить на каждом этапе и завалить решение;
— где и как дальше изучать System Design, чтобы прокачаться системно.
🎁 Бонус за регистрацию:
💡 Вебинар подойдёт системным аналитикам, которые хотят лучше понимать архитектуру, увереннее участвовать в технических обсуждениях и прокачать базу для работы и собеседований
Дата: 30 июня 19:00 (мск)
Формат: онлайн, бесплатно
Участие: по регистрации
Регистрируйтесь по ссылке: https://school.systemanalyst.life/abkhi
30 июня в 19:00 проведем бесплатный вебинар
System Design часто воспринимают как страшную секцию на собеседовании: нужно быстро придумать архитектуру, нарисовать схему, объяснить решения и не посыпаться на вопросах.
Но на самом деле System Design — это не
только про собеседования
Это навык, который помогает системному аналитику:
— понимать, как требования превращаются в архитектуру;
— увереннее общаться с разработчиками, архитекторами и техлидами;
— видеть ограничения, риски и trade-off’ы;
— не теряться в интеграциях, брокерах, очередях, НФТ и микросервисах;
— расти внутри компании, в зарплате и своей ценности на рынке
На вебинаре разберём:
— что такое System Design и из каких этапов он состоит;
— как подойти к проектированию системы пошагово;
— зачем System Design спрашивают на собеседованиях и как пройти эту секцию;
— какие ошибки можно допустить на каждом этапе и завалить решение;
— где и как дальше изучать System Design, чтобы прокачаться системно.
🎁 Бонус за регистрацию:
После регистрации вы получите полезные материалы по System Design:
— подборку статей;
— книги по архитектуре и проектированию систем;
— конференции и митапы;
— подкасты и блоги;
— презентацию с вебинара
Дата: 30 июня 19:00 (мск)
Формат: онлайн, бесплатно
Участие: по регистрации
Регистрируйтесь по ссылке: https://school.systemanalyst.life/abkhi
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9
Ученица объяснила ценность курса лучше меня 😄
Недавно ездила на ЛАФ (летний аналитический фестиваль). Ехали за город на машине небольшой компанией, и среди нас была моя ученица. По дороге она рассказывала другой девушке про мой курс по ИИ для аналитиков
Что именно рассказывала, честно, не знаю 😅Но у девушки была очень знакомая многим аналитикам боль: документация есть, требований много, а уверенности, что нигде не спрятались противоречия, пробелы или забытые сценарии - нет
В какой-то момент разговор закончился тем, чтокурс купили прямо по дороге😅
И вот это для меня самое ценное. Не потому что «ура, купили курс», а потому что сработала самая честная рекомендация: один аналитик увидел рабочую боль другого аналитика и сказал: «кажется, тебе это поможет». И реально помогло!
Мне вообще кажется, что самые сильные рекомендации всегда именно такие. Не из рекламы, не из прогревов, а из реального рабочего опыта
Недавно ездила на ЛАФ (летний аналитический фестиваль). Ехали за город на машине небольшой компанией, и среди нас была моя ученица. По дороге она рассказывала другой девушке про мой курс по ИИ для аналитиков
Что именно рассказывала, честно, не знаю 😅Но у девушки была очень знакомая многим аналитикам боль: документация есть, требований много, а уверенности, что нигде не спрятались противоречия, пробелы или забытые сценарии - нет
В какой-то момент разговор закончился тем, что
Через неделю я написала ей: "Ну как успехи?" И получила ответ, после которого сидела и улыбалась весь вечер. Курс уже окупился. Оказалось, что она начала использовать Cursor в рабочих задачах: проверять документы на противоречия, искать пробелы в требованиях, разбирать нормативку, писать критерии приёмки и просто контролировать, чтобы в процессе ничего важного не потерялось
И вот это для меня самое ценное. Не потому что «ура, купили курс», а потому что сработала самая честная рекомендация: один аналитик увидел рабочую боль другого аналитика и сказал: «кажется, тебе это поможет». И реально помогло!
Мне вообще кажется, что самые сильные рекомендации всегда именно такие. Не из рекламы, не из прогревов, а из реального рабочего опыта
❤13💯6
📊 Опрос: Масштабирование и отказоустойчивость
4 вопроса про реплики, кэш, шардирование и предохранитель цепи. Отвечай в комментариях — разбор сразу после вопроса
Бесплатный вебинар 30 июня 19:00 мск
"Пошаговый гайд по System Design"
4 вопроса про реплики, кэш, шардирование и предохранитель цепи. Отвечай в комментариях — разбор сразу после вопроса
Бесплатный вебинар 30 июня 19:00 мск
"Пошаговый гайд по System Design"
Пользователь обновил профиль (запись в основную PostgreSQL). Сразу открыл профиль — чтение с реплики, задержка 200–500 мс. Видит старые данные и жмёт обновить страницу. Что заложить в архитектуру?
Anonymous Quiz
70%
После своей записи читать профиль с основного узла или с реплики с проверкой задержки
7%
Увеличить задержку реплики до 5 сек — меньше нагрузка на основной узел
16%
Кэшировать профиль в сети доставки контента на 1 час
6%
Запретить чтение сразу после записи — только ответ без тела
📖 Пояснение:
Классика согласованности «прочитай своё»: после своей записи пользователь должен видеть свои изменения.
Варианты реализации:
▫️ Привязка сессии: после записи N секунд читать с основного узла
▫️ Маршрутизация по пользователю + метка времени последней записи в токене
▫️ Синхронная репликация для критичного чтения (дороже)
Почему не 2
Увеличение задержки ухудшает проблему, не лечит. Нагрузку на основной узел снимают асинхронной репликой, но удобство ломается без «прочитай своё».
Почему не 3
Кэш профиля на час — пользователь никогда не увидит свежие данные без сброса. Для персональных данных ещё и риск утечки через общий кэш.
Почему не 4
Запрет чтения — ломает контракт интерфейса и фронт. Клиенту нужны данные; проблема в маршрутизации чтения, не в методе.
💡 В ТЗ на реплики: какие операции допускают устаревшее чтение, какие — нет.
Сервис остатков: при каждом промахе кэша — запрос в БД. В пик 4000 запр/с на один горячий артикул — десятки параллельных промахов бьют в БД. Стратегия в ТЗ?
Anonymous Quiz
6%
Убрать кэш — только БД с индексом
39%
Кэш по требованию + блокировка на ключ при промахе; один поток грузит, остальные ждут
11%
Время жизни 0 — всегда свежие данные из Redis
44%
Сквозная запись: каждое изменение остатка пишет в кэш и БД синхронно
📖 Пояснение:
Лавина промахов кэша — множество запросов в БД при истечении времени жизни горячего ключа.
Блокировка на ключ (один запрос на ключ):
▫️ Первый промах захватывает блокировку загрузки
▫️ Остальные ждут или получают слегка устаревшее значение
▫️ Один запрос в БД → заполнение кэша → снятие блокировки
Дополнительно: разброс во времени жизни, раннее обновление с вероятностью.
Почему не 1
4000 rps на одну строку БД — узкое горлышко без кэша. Индекс не спасает от конкуренции за блокировку строки.
Почему не 3
Нулевое время жизни при кэше по требованию = каждый запрос — промах → БД. Противоречит цели кэша.
Почему не 4
Сквозная запись помогает при частых записях, но лавина на чтении при горячем ключе всё равно возможна без блокировки. D не закрывает сценарий из вопроса.
💡 Для остатков на пути оформления кэш часто отключают; лавина — про каталог и горячее чтение, не про резерв.
❤1
БД заказов > 2 ТБ, вставка 5 тыс/с. Шардируем PostgreSQL. Запросы: по id заказа, по id пользователя (история), отчёты по дате за месяц. Какой ключ шардирования в приоритете?
Anonymous Quiz
12%
id региона — 5 шардов по географии
27%
id заказа (случайный UUID) — равномерная запись
19%
дата создания по месяцу — удобные отчёты
42%
id пользователя — история заказов на одном шарде
📖 Пояснение:
Ключ шардирования выбирают по доминирующему паттерну запросов и равномерности.
▫️ id пользователя — типичная нагрузка: «мои заказы» = один шард, без опроса всех узлов
▫️ Вставка распределяется по активным пользователям — обычно достаточно равномерно
Отчёты по дате — отдельно: реплика для чтения, аналитическое хранилище или отдельный сервис, не основной ключ шардирования.
Почему не 1
География работает, если трафик реально региональный. В вопросе доминирует история пользователя — id пользователя логичнее.
Почему не 2
Случайный UUID — равномерная запись, но запрос «все заказы пользователя» = опрос всех шардов — убивает задержку и процессор.
Почему не 3
Шард по месяцу — горячий шард в текущем месяце, старые простаивают; запись не масштабируется равномерно.
💡 В ТЗ: основные сценарии доступа → ключ шардирования → что уходит в аналитику отдельно.
Сервис рекомендаций падает: таймаут 3 сек, 80% ошибок. Оформление заказа без рекомендаций должно работать. Предохранитель цепи в состоянии «разомкнут». Что видит пользователь при оформлении по ТЗ?
Anonymous Quiz
89%
Оформление без блока рекомендаций; пустой блок или популярные товары из кэша
8%
Оформление недоступно (503) — нельзя без рекомендаций
2%
Ждать 3 сек на каждом запросе — вдруг сервис оживёт
1%
Бесконечные повторы в фоне — пользователь на загрузке
📖 Пояснение:
Предохранитель «разомкнут» = быстрый отказ без вызова недоступного сервиса. Для необязательного функционала (рекомендации) — плавное снижение функций:
▫️ Критичный путь оформления не блокируется
▫️ Запасной вариант: статический блок, кэш «хиты», скрыть секцию
▫️ Состояние «полуоткрыто» — редкие пробные запросы для проверки восстановления
Почему не 2
Рекомендации не в критичном пути — 503 на всё оформление неоправданная потеря выручки.
Почему не 3
Ждать 3 сек при каждом оформлении при разомкнутом предохранителе — нарушает его смысл и убивает 95-й перцентиль. Разомкнут как раз чтобы не ждать.
Почему не 4
Бесконечные повторы в синхронном запросе — те же таймауты и каскадные сбои. Повторы — в фоне с лимитом, не в пользовательском сценарии.
💡 В ТЗ разделяй: критичный путь необязательное — для каждого свой запасной вариант при разомкнутом предохранителе.
❤4
Дарим подарки нашим подписчикам 🎁
Мы с ребятами решили порадовать вас интересными подарками от наших каналов:
- Внешний жесткий диск
- Настольная игра от Школы Систем Аналист
- Футболка BA | SA
Условия максимально простые:
- подписаться на каналы;
- нажать «участвую».
1. Системный анализ | Ольга Пономарева
2. Business | System analyst
3. Analyst IT
07.07 в 17:00 мы проведем розыгрыш и троим из вас улыбнется удача)))
Мы с ребятами решили порадовать вас интересными подарками от наших каналов:
- Внешний жесткий диск
- Настольная игра от Школы Систем Аналист
- Футболка BA | SA
Условия максимально простые:
- подписаться на каналы;
- нажать «участвую».
1. Системный анализ | Ольга Пономарева
2. Business | System analyst
3. Analyst IT
07.07 в 17:00 мы проведем розыгрыш и троим из вас улыбнется удача)))
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥3👍1
Финальный урок записан. Мы готовы к ученикам!
Сегодня записала последний урок для курса «Архитектура. База» и наконец-то могу выдохнуть: курс собран и получилось просто бомба! Как обычно объясняю просто даже сложные вещи, такие как балансировщик, вебхуки, вебсоекты и другие страшные слова!
Отдельно докрутила шпаргалки, примеры и задания, чтобы это было не «посмотрел и забыл», а можно было применять в работе
1 поток стартует уже 6 июля, в понедельник!
До конца июня можно попасть со скидкой 15% по промокоду
👉Подробнее о курсе
Успевайте попасть в первый поток😎
Сегодня записала последний урок для курса «Архитектура. База» и наконец-то могу выдохнуть: курс собран и получилось просто бомба! Как обычно объясняю просто даже сложные вещи, такие как балансировщик, вебхуки, вебсоекты и другие страшные слова!
Отдельно докрутила шпаргалки, примеры и задания, чтобы это было не «посмотрел и забыл», а можно было применять в работе
Первый поток буду вести лично я: домашки, воркшопы, разборы. Я всегда очень трепетно отношусь к первым потокам, потому что именно там видно, где курс уже сильный, а где можно докрутить ещё лучше
1 поток стартует уже 6 июля, в понедельник!
До конца июня можно попасть со скидкой 15% по промокоду
JUNE15👉Подробнее о курсе
Успевайте попасть в первый поток😎
👍4
Аналитик до освоения дизайна систем:
Аналитик после освоения дизайна систем:
Результат: меньше «архитектурных переделок» в будущем, лучшее планирование.
✅ Именно так повлияют знания System Design на вас, а как итогом станет сеньорский грейд и увеличение зп
‼️ Уже во вторник, 30 июня, в 19:00 (мск) на вебинаре будем разбирать Основы System Design
Приходите, чтобы понять эту тему и свой план развития!
Регистрируйтесь по ссылке: https://school.systemanalyst.life/abkhi
“сделаем как проще - а дальше разберемся”
Аналитик после освоения дизайна систем:
"Если трафик вырастет в 10 раз — справится ли архитектура? Где узкие места? Нужен ли кэш? Какие части можно масштабировать горизонтально?"
Результат: меньше «архитектурных переделок» в будущем, лучшее планирование.
Приходите, чтобы понять эту тему и свой план развития!
Регистрируйтесь по ссылке: https://school.systemanalyst.life/abkhi
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5