Урок пройдёт в формате System Design. Вместе с преподавателем спроектируешь маркетплейс наподобие Ozon, выберешь границы сервисов и способы их взаимодействия
проектируем архитектуру маркетплейса:
микросервисы на практике
Дата проведения
9 ноября в 19:00 МСК
Для кого
Разработчикам, Системным аналитикам
Скорее всего ты уже пытался разобраться в микросервисах
Монолит, API, брокеры сообщений, паттерны — читал статьи и смотрел видео, но пока непонятно, как всё это работает вместе в реальном проекте.
Проблема
01
Непонятно, когда монолит пора разделять
Проблема
02
Неясно, как связать сервисы между собой
Проблема
03
Учебные схемы не объясняют реальные сбои
как согласовать работу сервисов и обрабатывать сбои при оформлении заказа
когда использовать HTTP, а когда Kafka или RabbitMQ
Что ты узнаешь на уроке
как разделить маркетплейс на микросервисы и определить их границы
как связать каталог, заказы, оплату и остатки
СПИКЕР урока — Станислав Клоков
Тимлид в Highload Fintech, Ex-Техлид Яндекс
Занимается проработкой технических решений и реализацией работы с высоконагруженными хранилищами и сервисами
NDA
Тимлид
Руководит командой в высоконагруженном финтех-проекте с нагрузкой 100k RPS
Яндекс
Техлид
Занимался разработкой ядра платформы микросервисов. Вел проекты по работе с сетями и БД
Т-Банк
Middle Fullstack
Развивал внутренний фреймворк для построения микро-фронтенд узлов на Express
НИУ ВШЭ, МФТИ
Лектор
Преподаёт курс по Backend разработке, выступает в роли руководителя курсовых работ
© 2026 ИП Шумейко Артём Владимирович
ИНН 110103208338 ОГРНИП 323784700281112
Параллелизм в Python на примерах из реальной разработки
Продолжая пользоваться сайтом, вы соглашаетесь с использованием куки и обработкой данных в соответствии с политикой конфиденциальности.
Микросервисы позволяют независимо развивать и масштабировать части приложения. Вместе с этим появляются сетевые вызовы, отдельные развёртывания и сложности с согласованностью данных. По статьям трудно понять, когда эти затраты оправданы, какую проблему решит переход и где провести границы между сервисами.
Один сервис может вызвать другой через API или отправить сообщение через брокер. В примерах оба варианта выглядят просто, но в проекте нужно решить, ждать ли ответ сразу, что делать при недоступности соседнего сервиса и как обрабатывать повторные сообщения.
На схеме запрос дошёл, сервис ответил, операция завершилась. В реальной системе платёж может пройти, а ответ — потеряться по дороге. Сервис заказов повторит запрос, и деньги спишутся ещё раз. Упрощённые примеры редко объясняют, как найти причину такого сбоя и защитить систему от повторного выполнения операции.