❤3
📝 Задача | Архитектура
Условие:
Сервис онлайн-записи к врачам. Пользователь выбирает клинику, врача и слот, получает подтверждение на email и push.
Вводные:
▫️ ~50 000 записей в день, пики утром и вечером
▫️ Есть веб и мобильное приложение
▫️ Расписание врачей хранится в CRM клиники — интеграция по REST API
▫️ Уведомления должны уходить даже если CRM временно недоступна после создания записи
Задание:
1. Назови основные компоненты системы (3–6 штук).
2. Опиши поток: пользователь записался → что происходит дальше.
3. Объясни, где уместна синхронная интеграция, а где асинхронная — и почему.
⏱️ Попробуй решить сам.
Разбор опубликуем 10.06 в первой половине дня по мск
Пиши ответ в комментариях 👇
Условие:
Сервис онлайн-записи к врачам. Пользователь выбирает клинику, врача и слот, получает подтверждение на email и push.
Вводные:
▫️ ~50 000 записей в день, пики утром и вечером
▫️ Есть веб и мобильное приложение
▫️ Расписание врачей хранится в CRM клиники — интеграция по REST API
▫️ Уведомления должны уходить даже если CRM временно недоступна после создания записи
Задание:
1. Назови основные компоненты системы (3–6 штук).
2. Опиши поток: пользователь записался → что происходит дальше.
3. Объясни, где уместна синхронная интеграция, а где асинхронная — и почему.
⏱️ Попробуй решить сам.
Разбор опубликуем 10.06 в первой половине дня по мск
Пиши ответ в комментариях 👇
❤4
✅ Решение | Архитектура · Запись к врачу
Краткий ответ:
Компоненты: Web/Mobile → API Gateway → Сервис записи → CRM (REST) + Брокер → Сервис уведомлений → Email/Push-провайдер. БД записи — у сервиса записи.
📖 Разбор:
1️⃣ Компоненты
▫️ API Gateway — единая точка входа для веба и мобилки
▫️ Сервис записи — бизнес-логика: проверка слота, создание записи, своя БД
▫️ CRM клиники — внешняя система с расписанием (REST)
▫️ Брокер сообщений — очередь событий «запись создана»
▫️ Сервис уведомлений — читает из брокера, шлёт email и push
2️⃣ Поток
Пользователь выбирает слот → Gateway → Сервис записи синхронно проверяет слот в CRM → создаёт запись у себя в БД → кладёт событие в брокер → сразу отвечает пользователю «Запись создана».
Сервис уведомлений асинхронно забирает событие и отправляет письмо и push. Если CRM упала после успешного создания записи — пользователь уже получил ответ, уведомление уйдёт позже из очереди.
3️⃣ Синхрон vs асинхрон
Синхронно (REST к CRM) — проверка и бронирование слота. Пользователь должен сразу узнать: слот свободен или занят.
Асинхронно (брокер) — уведомления. Не блокируем ответ пользователю, переживаем временные сбои email/push за счёт повторной обработки из очереди.
❌ Типичные ошибки:
▫️ Всё через синхронные вызовы — при падении push-сервиса пользователь не получит ответ о записи
▫️ CRM как единственная БД записей — потеря контроля над своими данными и зависимость от чужого SLA
▫️ Брокер для проверки слота — лишняя сложность, пользователь ждёт мгновенный результат
💡 На собеседовании важно: назвать почему граница между sync и async проходит именно здесь.
Краткий ответ:
Компоненты: Web/Mobile → API Gateway → Сервис записи → CRM (REST) + Брокер → Сервис уведомлений → Email/Push-провайдер. БД записи — у сервиса записи.
📖 Разбор:
1️⃣ Компоненты
▫️ API Gateway — единая точка входа для веба и мобилки
▫️ Сервис записи — бизнес-логика: проверка слота, создание записи, своя БД
▫️ CRM клиники — внешняя система с расписанием (REST)
▫️ Брокер сообщений — очередь событий «запись создана»
▫️ Сервис уведомлений — читает из брокера, шлёт email и push
2️⃣ Поток
Пользователь выбирает слот → Gateway → Сервис записи синхронно проверяет слот в CRM → создаёт запись у себя в БД → кладёт событие в брокер → сразу отвечает пользователю «Запись создана».
Сервис уведомлений асинхронно забирает событие и отправляет письмо и push. Если CRM упала после успешного создания записи — пользователь уже получил ответ, уведомление уйдёт позже из очереди.
3️⃣ Синхрон vs асинхрон
Синхронно (REST к CRM) — проверка и бронирование слота. Пользователь должен сразу узнать: слот свободен или занят.
Асинхронно (брокер) — уведомления. Не блокируем ответ пользователю, переживаем временные сбои email/push за счёт повторной обработки из очереди.
❌ Типичные ошибки:
▫️ Всё через синхронные вызовы — при падении push-сервиса пользователь не получит ответ о записи
▫️ CRM как единственная БД записей — потеря контроля над своими данными и зависимость от чужого SLA
▫️ Брокер для проверки слота — лишняя сложность, пользователь ждёт мгновенный результат
💡 На собеседовании важно: назвать почему граница между sync и async проходит именно здесь.
❤13🔥4
Проходят сьёмки нового сезона...
Курса по архитектуре!
Проблема была в том, что был определенный процент людей, которым курс казался "слишком легким, простым", а был небольшой процент, которым, наоборот, казался "тяжелым"
Поэтому, мы приняли решение, во-первых:
1️⃣ Актуализировать информацию
а во-вторых:
Первую часть (будем называть его БАЗА по архитектуре, для тех, кто хочет освоить тему архитектуры) - записываю я, а вторую часть (будем называть ХАРД, для тех, кто хочет углубить свои знания) - Владимир Бурмистров (сейчас он главный СА в Т1, а до этого был разработчиком, и архитектура - это его "стихия")
Так что, будет актуально для каждого кому нужна архитектура (для новичков и опытных аналитиков)
Как всегда, без воды, с практикой 🫶
Следите за новостями!🤩
А записаться в предзапись на обновленные курсы можно тут: https://systemanalyst.life/architecture
(Ориентировочный старт: начало июля)
Курса по архитектуре!
О да, наконец добрались руки до самого мощного и актуального курса среди аналитиков за всю историю школы
Проблема была в том, что был определенный процент людей, которым курс казался "слишком легким, простым", а был небольшой процент, которым, наоборот, казался "тяжелым"
Поэтому, мы приняли решение, во-первых:
1️⃣ Актуализировать информацию
а во-вторых:
2️⃣ РАЗДЕЛИТЬ ОБУЧЕНИЕ НА ДВЕ ЧАСТИ!Первую часть (будем называть его БАЗА по архитектуре, для тех, кто хочет освоить тему архитектуры) - записываю я, а вторую часть (будем называть ХАРД, для тех, кто хочет углубить свои знания) - Владимир Бурмистров (сейчас он главный СА в Т1, а до этого был разработчиком, и архитектура - это его "стихия")
Так что, будет актуально для каждого кому нужна архитектура (для новичков и опытных аналитиков)
Как всегда, без воды, с практикой 🫶
Следите за новостями!
А записаться в предзапись на обновленные курсы можно тут: https://systemanalyst.life/architecture
(Ориентировочный старт: начало июля)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👏3👌2
📂 Кейс: «Почему вы не взяли Kafka?» — вопрос с собеседования, который стал реальным проектом
🏢 Контекст:
Маркетплейс доставки еды, ~200 заказов в минуту в пик. Команда из 8 разработчиков, монолит на Python, один PostgreSQL. Собеседование на Middle SA — тестовое: предложить целевую архитектуру на 12 месяцев.
😬 Проблема:
Кандидат на схеме нарисовал 6 микросервисов, Kafka и Redis "как в статьях". На защите тестового техлид спросил: "Зачем Kafka при 200 заказах и команде из 8 человек? Как будете дебажить?"
Кандидат уверенно отвечал про масштабируемость. Но не смог объяснить, какой бизнес-риск решает брокер на данном этапе.
🔍 Что сделал аналитик (уже на проекте, тот же вопрос от бизнеса):
1. Собрал НФТ: пик 200 зак/мин, рост до 500 за год, RTO 30 мин
2. Выделил узкое место: не заказы, а расчёт времени доставки из трёх внешних сервисов (карты, курьеры, кухня)
3. Предложил поэтапно:
— Сейчас: вынести расчёт ETA в отдельный сервис + кэш Redis (синхронный REST для заказа остаётся)
— Через 6 мес.: события «заказ создан» в RabbitMQ для уведомлений и аналитики
— Kafka — только при выходе на 500+ и появлении event streaming для отчётов
4. Зафиксировал в ADR: почему не Kafka на старте (операционная сложность, нет consumer-групп на объёме)
✅ Результат:
Архитектурный комитет принял roadmap без "микросервисов ради микросервисов". Через 4 месяца ETA-сервис снизил таймауты на 40%. RabbitMQ добавили точечно — под уведомления.
💡 Выводы:
▫️ На собеседовании и на проекте побеждает не самая модная схема, а обоснованная под контекст
▫️ Вопрос "почему не X?" важнее, чем "мы взяли X"
▫️ Аналитик связывает НФТ, команду и этап продукта — не только рисует блоки
Кстати, у нас идет обновление курса "Архитектура для аналитика", скоро вернется в новом формате. Мы делим большой курс на два уровня:
База — чтобы перестать плавать в архитектуре
Hard — для сложных архитектурных решений
Подробности на сайте. Оставь заявку, чтобы первым получить уведомление о запуске!
🏢 Контекст:
Маркетплейс доставки еды, ~200 заказов в минуту в пик. Команда из 8 разработчиков, монолит на Python, один PostgreSQL. Собеседование на Middle SA — тестовое: предложить целевую архитектуру на 12 месяцев.
😬 Проблема:
Кандидат на схеме нарисовал 6 микросервисов, Kafka и Redis "как в статьях". На защите тестового техлид спросил: "Зачем Kafka при 200 заказах и команде из 8 человек? Как будете дебажить?"
Кандидат уверенно отвечал про масштабируемость. Но не смог объяснить, какой бизнес-риск решает брокер на данном этапе.
🔍 Что сделал аналитик (уже на проекте, тот же вопрос от бизнеса):
1. Собрал НФТ: пик 200 зак/мин, рост до 500 за год, RTO 30 мин
2. Выделил узкое место: не заказы, а расчёт времени доставки из трёх внешних сервисов (карты, курьеры, кухня)
3. Предложил поэтапно:
— Сейчас: вынести расчёт ETA в отдельный сервис + кэш Redis (синхронный REST для заказа остаётся)
— Через 6 мес.: события «заказ создан» в RabbitMQ для уведомлений и аналитики
— Kafka — только при выходе на 500+ и появлении event streaming для отчётов
4. Зафиксировал в ADR: почему не Kafka на старте (операционная сложность, нет consumer-групп на объёме)
✅ Результат:
Архитектурный комитет принял roadmap без "микросервисов ради микросервисов". Через 4 месяца ETA-сервис снизил таймауты на 40%. RabbitMQ добавили точечно — под уведомления.
💡 Выводы:
▫️ На собеседовании и на проекте побеждает не самая модная схема, а обоснованная под контекст
▫️ Вопрос "почему не X?" важнее, чем "мы взяли X"
▫️ Аналитик связывает НФТ, команду и этап продукта — не только рисует блоки
Кстати, у нас идет обновление курса "Архитектура для аналитика", скоро вернется в новом формате. Мы делим большой курс на два уровня:
База — чтобы перестать плавать в архитектуре
Hard — для сложных архитектурных решений
Подробности на сайте. Оставь заявку, чтобы первым получить уведомление о запуске!
❤5
Вчера провели первую встречу воркшопа по Postman
По отзывам участников, главная цель была достигнута💛:
Темп получился плотный, это правда. Кто-то успевал повторять сразу, кто-то в какой-то момент просто смотрел и решил спокойно пересобрать всё по записи. Но для этого запись и будет: чтобы вернуться, повторить шаги и закрепить уже без спешки
Сейчас участникам выдали домашнее задание. Следующая встреча — 16 июня, там будем разбирать решения, отвечать на вопросы и смотреть, где чаще всего возникают ошибки!
⭐️ Если вдруг, по какой то причине, вы не смогли попасть, то сообщаем, что осталось несколько мест (14), и вы можете приобрести тариф с записями, чтобы пересмотреть первую встречу и подготовиться ко второй: https://systemanalyst.life/apiworkshop
По отзывам участников, главная цель была достигнута💛:
«Цель про то, чтобы пощупать сам Postman, была выполнена»
Темп получился плотный, это правда. Кто-то успевал повторять сразу, кто-то в какой-то момент просто смотрел и решил спокойно пересобрать всё по записи. Но для этого запись и будет: чтобы вернуться, повторить шаги и закрепить уже без спешки
Сейчас участникам выдали домашнее задание. Следующая встреча — 16 июня, там будем разбирать решения, отвечать на вопросы и смотреть, где чаще всего возникают ошибки!
И вот это, на мой взгляд, самое ценное в формате воркшопа: это не "посмотрел вебинар и забыл", а практика → домашка → разбор → вопросы
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Кажется, мы дошли до той стадии развития сообщества, когда аналитика можно узнать не только по ноутбуку 😄
У нас есть классный мерч:
👕 футболки с аналитическими надписями
🎲 настольная игра для системных аналитиков
Теперь главный вопрос...
А вы вообще хотели бы такой мерч себе?
Давайте честно оценим уровень желания по шкале системного аналитика:
🔥 «Хочу сильнее, чем заказчик хочет поменять требования после согласования»
👌 «Взял бы, если не придётся писать ТЗ на получение мерча»
💯«Готов обменять на него пару диаграмм и один use case»
👏«Уже мысленно пришёл на созвон в этой футболке»
👍 «Где записаться в очередь и почему это ещё не user story?»
Пишите свой вариант в комментариях
У нас есть классный мерч:
👕 футболки с аналитическими надписями
🎲 настольная игра для системных аналитиков
Теперь главный вопрос...
А вы вообще хотели бы такой мерч себе?
Давайте честно оценим уровень желания по шкале системного аналитика:
🔥 «Хочу сильнее, чем заказчик хочет поменять требования после согласования»
👌 «Взял бы, если не придётся писать ТЗ на получение мерча»
💯«Готов обменять на него пару диаграмм и один use case»
👏«Уже мысленно пришёл на созвон в этой футболке»
👍 «Где записаться в очередь и почему это ещё не user story?»
Пишите свой вариант в комментариях
🔥20👏9👍5❤4💯2
Команда "распилила" монолит на 6 микросервисов, но все пишут в одну PostgreSQL, используют JOIN между таблицами разных сервисов и выкатывают релиз одним пайплайном. Какой архитектурный риск здесь главный?
Anonymous Quiz
65%
Distributed monolith: формально сервисы разделены, но связаны через общую схему БД
16%
Нарушение принципа REST: внутренние вызовы должны идти только через методы, а не через общую БД
9%
Недостаточная отказоустойчивость: при падении одного pod Kubernetes не поднимет остальные реплики
10%
Отсутствие API Gateway — без него микросервисная архитектура считается невалидной
❤1
📖 Пояснение:
Это классический distributed monolith — худший из двух миров. Сложность микросервисов (сеть, версионирование контрактов, observability) уже есть, а выгоды MSA нет.
Признаки из вопроса:
▫️ Общая БД — главный антипаттерн MSA; граница сервиса = граница данных
▫️ JOIN между "сервисами" — скрытая жёсткая связность; изменение схемы ломает всех
▫️ Один пайплайн релиза — нет независимого deploy, команды блокируют друг друга
На собеседовании сильный ход — назвать это по имени и предложить: database per service, интеграция через API/события, отдельные CI/CD.
Почему не 2
Проблема не в выборе REST. Даже идеальные gRPC-контракты не спасут, если сервисы делят таблицы и миграции схемы согласуются вручную на весь зоопарк.
Почему не 3
Kubernetes поднимет реплики — это про оркестрацию контейнеров, не про логическую связность. Система может быть"живой" и при этом архитектурно неправильной.
Почему не 4
API Gateway не лечит shared database. Шлюз — фасад для клиентов. Без gateway MSA всё равно возможна — вопрос в границах доменов.
💡 Запомни формулировку для собеса: «Микросервисы без изоляции данных — distributed monolith»."
🔥7❤3
Сервис оплаты публикует событие «payment.completed» в Kafka с гарантией at-least-once. Консьюмер списывает бонусы. Из-за retry одно и то же событие может прийти дважды. Что аналитик обязан заложить в требования к консьюмеру?
Anonymous Quiz
80%
Идемпотентная обработка по бизнес-ключу payment_id: повторное событие не меняет баланс второй раз
16%
Переключить Kafka на exactly-once — брокер сам гарантирует уникальность на уровне всей цепочки
3%
Заменить асинхронную схему на синхронный REST-вызов с таймаутом 30 секунд между сервисами
0%
Отключить acknowledgment у консьюмера, чтобы сообщение не переотправлялось при сбое
❤5
📖 Пояснение:
At-least-once означает: сообщение дойдёт, но возможен дубликат (сбой после обработки, но до commit offset).
Решение на уровне бизнес-логики — идемпотентность:
▫️ Хранить обработанные
payment_id▫️ Или upsert с тем же ключом — повторный вызов даёт тот же результат
▫️ Это стандартное требование аналитика в ТЗ на интеграции через брокер
Почему не 2
Exactly-once в распределённой системе — сложная комбинация (транзакции Kafka + идемпотентный producer + координация с БД). «Брокер сам всё решит без дедупликации» — миф. Даже EOS в Kafka не отменяет идемпотентность на стороне consumer для внешних side effects (бонусы, деньги).
Почему не 3
Sync REST не убирает дубликаты — клиент может повторить запрос при таймауте. Проблема идемпотентности остаётся, плюс появляется coupling и каскадные таймауты по цепочке сервисов.
Почему не 4
Отключение ack усугубляет потери и хаос: при сбое offset не фиксируется, но отказ от ack не равно "не будет retry". На практике — риск потерять сообщения или обрабатывать бесконечно. Это антипаттерн.
💡 На Middle-собесе ждут связку: at-least-once → дубликаты возможны → idempotency key в ТЗ.
🔥9❤2
Мобильное приложение открывает экран «Заказ». API Gateway последовательно вызывает 5 микросервисов. p95 ответа — 4,2 сек, таймаут клиента — 3 сек. Какое архитектурное решение корректно заложить в ТЗ?
Anonymous Quiz
59%
BFF с параллельной агрегацией или выделенный composite endpoint, собирающий ответ за один round-trip
15%
Увеличить таймаут мобильного клиента до 10 секунд — проблема на стороне UX, не архитектуры
23%
Перенести всю бизнес-логику пяти сервисов в API Gateway, чтобы сократить сетевые вызовы
3%
Отказаться от Gateway и вызывать микросервисы напрямую с телефона — так меньше промежуточных hop'ов
❤2
📖 Пояснение:
Проблема — синхронная цепочка (latency суммируется: 5 × ~800 мс ≈ 4 с). Gateway как "тупой прокси" не обязан агрегировать — но кто-то должен.
Варианты в ТЗ:
▫️ BFF (Backend for Frontend) — сервис под мобилку, параллельно дергает 5 API (Promise.all / async), отдаёт один DTO экрана
▫️ Composite endpoint в доменном сервисе — GET /orders/{id}/screen внутри собирает данные
▫️ Параллель, а не последовательность — p95 падает до max(вызовов), а не sum(вызовов)
Почему не 2
Увеличение таймаута — костыль. Пользователь ждёт 4+ секунды на каждом экране — плохой UX и отток. НФТ по latency нужно решать архитектурой, не настройкой клиента.
Почему не 3
Перенос бизнес-логики в Gateway — антипаттерн "умный gateway". Раздувается компонент, смешиваются cross-cutting и domain logic, усложняется тестирование и релизы. Gateway = фасад, BFF = агрегация под клиента.
Почему не 4
Прямые вызовы с телефона в 5 микросервисов — хуже: больше round-trip'ов с мобильной сети, нет единой точки auth/rate limit, внутренняя топология светится наружу, CORS и безопасность усложняются.
💡 На собесе: "Gateway ≠ BFF. Для тяжёлых экранов — отдельный BFF с параллельной агрегацией".
🔥11❤4
На складе 1 товар. При сетевом разрыве между двумя зонами оба сервера одновременно оформляют заказ. Двойная продажа хуже, чем ошибка 503. Какой принцип из CAP-теоремы выбрать в НФТ?
Anonymous Quiz
67%
При разрыве работа с остатками только при большинстве реплик. Если кворума нет — ошибка
11%
Обе зоны принимают заказ, расхождения остатков исправятся позже фоновой сверкой
11%
Держать один дата-центр без репликации между зонами
11%
Показывать клиенту последний известный остаток без обращения к серверу
❤4
📖 Пояснение:
Бизнес-правило из вопроса: перепродажи недопустимы → важнее согласованность, чем доступность любой ценой.
При network partition:
▫️ CP: система откажет в записи/чтению, если нет большинства реплик (quorum) — клиент получит 503/409, но двойная продажа одной единицы не произойдёт
▫️ Это ближе к strong consistency / linearizability на критичном ресурсе
Примеры подходов: etcd/ZooKeeper consensus, БД с sync replication и правилом "не пишем без кворума".
Почему не 2
Классический анти паттерн: оба узла принимают заказ → две продажи одной штуки — как раз то, от чего бизнес отказался. Согласованность для остатков склада без компенсации = финансовые потери.
Почему не 3
Один DC без репликации не решает отказоустойчивость. Partition tolerance в облаке неизбежна. Это шаг назад по availability при аварии ЦОД, а не осознанный CAP-выбор.
Почему не 4
Клиентский кэш остатка — ещё слабее по консистентной работе: пользователь видит фантомный товар. Не заменяет серверную модель согласованности и не предотвращает race condition на двух репликах.
💡 CAP на практике: не зубрить буквы, а привязать к НФТ — "перепродажа vs 503" → CP на остатках.
🔥9❤3💯1
Последние пару недель мы начали экспериментировать с форматом контента.
Если раньше чаще были карточки с теоретической информацией, то сейчас стали добавлять больше настоящих рабочих кейсов аналитиков.
Например такие вопросы, которые вполне могут прилететь на собеседовании мидла или встретиться на проекте:
— как правильно проектировать интеграции;
— где узкое место в архитектуре;
— почему решение выглядит логичным, но создаёт проблемы в проде;
— какие варианты реально используются в компаниях.
Интересно понять, как вы это ощущаете 🙂
Если раньше чаще были карточки с теоретической информацией, то сейчас стали добавлять больше настоящих рабочих кейсов аналитиков.
Например такие вопросы, которые вполне могут прилететь на собеседовании мидла или встретиться на проекте:
— как правильно проектировать интеграции;
— где узкое место в архитектуре;
— почему решение выглядит логичным, но создаёт проблемы в проде;
— какие варианты реально используются в компаниях.
Интересно понять, как вы это ощущаете 🙂
🔥11❤4
Заметили ли вы изменения в контенте
Anonymous Poll
51%
Да, стало интереснее
31%
Да, стало сложнее, но полезнее
14%
Не заметил(а) изменений
47%
Хочу больше практических кейсов
11%
Хочу больше контента для джунов
🎙 Вышел новый выпуск подкаста «Аналитик за кулисами»
Тема выпуска — архитектура систем
Про то, как на самом деле рождаются IT-системы: от бизнес-идеи и Vision до требований, архитектурных решений, MVP и пилота
В гостях — Кирилл Егоркин, архитектор решений
Этот выпуск особенно хорошо зайдёт тем, кто хочет лучше понимать, почему системы проектируются именно так, а не просто запоминать термины вроде DDD, микросервисов, брокеров и C4
🆘 А для тех, кто хочет системно разобраться в архитектуре, — в ближайшие дни расскажем про обновлённые программы наших курсов
Будет два уровня обучения, чтобы каждый мог выбрать подходящий формат под свой опыт и задачи
А пока выпуск можно посмотреть и послушать здесь:
📱 VK Видео
📱 YouTube
📱 Apple Podcasts
📱 Яндекс Музыка
Тема выпуска — архитектура систем
Про то, как на самом деле рождаются IT-системы: от бизнес-идеи и Vision до требований, архитектурных решений, MVP и пилота
В гостях — Кирилл Егоркин, архитектор решений
В выпуске обсудили:
— зачем проекту Vision и кто его формирует;
— где заканчивается зона ответственности аналитика и начинается зона архитектора;
— какие артефакты нужны до разработки;
— почему бизнес часто приходит не с проблемой, а с уже готовым решением;
— когда выбирать монолит, а когда микросервисы;
— как системному аналитику начать мыслить архитектурно
Этот выпуск особенно хорошо зайдёт тем, кто хочет лучше понимать, почему системы проектируются именно так, а не просто запоминать термины вроде DDD, микросервисов, брокеров и C4
Будет два уровня обучения, чтобы каждый мог выбрать подходящий формат под свой опыт и задачи
А пока выпуск можно посмотреть и послушать здесь:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤3
Мой воркшоп прошел на ура! Рассказывала, как создавать продукт, который будет приносить деньги и нужен пользователям😎
А помимо воркшопа я соорганизатор сообщества аналитического клуба и мы проводили совместный воркшоп, где просили ребят написать ТЗ на снежинки. Было забавно, посмотрите как парень смеется на последних видео)
А помимо воркшопа я соорганизатор сообщества аналитического клуба и мы проводили совместный воркшоп, где просили ребят написать ТЗ на снежинки. Было забавно, посмотрите как парень смеется на последних видео)
❤12👏2