🤓 Небольшая инженерная задачка, чтобы размяться Ты пилишь сервис уведомлений. Обычная штука, которая шлёт людям пуши: юзер оформил заказ, ему на телефон прилетело "заказ отправлен". Внутри всё скучно: приняли запрос, записали в Postgres, кинули событие в Kafka, ответили 202. Дальше отдельный сервис с воркером, разгребает очередь и шлет пуши. Окей, а что будет, если посреди этого что-нибудь отвалится? Попытка 1. Пишем в базу, потом в Kafka Записали в базу, коммит прошёл, идём публиковать в Kafka, и там таймаут. Клиенту мы уже ответили 202 типо все ок. Запись в базе лежит, в Kafka пусто. Воркер не сделает ничего, для него этого события просто не существует. И кто его теперь опубликует? Клиент второй раз не придёт, он получил успешный ответ и живёт себе дальше. Попытка 2. Кладём запись и намерение в одну транзакцию Ладно. Рядом с сервисом заводим outbox табличку и пишем туда в той же транзакции. Из хендлера в Kafka не ходим вообще. Теперь единственный, кто публикует, это отдельный крон: вычитал неотправленные строки, отправил, пометил. Потерю между базой и Kafka убрали. Зато вылез дубль: крон мог опубликовать и упасть до того, как пометил строку, а после перезапуска отправит ещё раз. Попытка 3. Учим систему узнавать повторы Значит, каждому событию свой event_id, живёт от outbox до воркера. Воркер, вычитав из Kafka, сначала смотрит, не обрабатывал ли он это уже, и уникальный ключ в базе не даёт двум инстансам взяться за одно событие. И вот можно накидывать про backoff, rate limit, circuit breaker и так далее. второму кругу. Такие вот развилки и спрашивают на System Design секции. А от неё зависит немало: пройдёшь ты собес или нет, на какой грейд возьмут и с какой зарплатой. При этом готовиться к ней непонятно как: что спрашивают, насколько глубоко копают, по каким правилам оценивают, сколько надо успеть за 50 минут. Чтобы разобраться с этим, мой хороший знакомый Олег Козырев 27 августа в 19:00 по МСК проводит открытый урок: 📆Как пройти секцию System Design за 50 минут Для кого будет урок: - Хочешь апнуть грейд и зарплату, а рост упёрся в сисдиз, с которым ты мало работал - Уже готовишься к секции: теорию знаешь, а как уложиться в отведённое время и ничего не упустить, непонятно - Уже пробовал проходить секцию, но в итоге завалил Что будет на уроке: 🔍Разберём реальную задачу с собеса: сервис уведомлений на 2 млн отправок в сутки 🔍Поймём, что интервьюер оценивает на самом деле и обычно это совсем не то, что тебе кажется 🔍Какие вопросы задать в начале, чтобы размытая формулировка превратилась в задачу, которую реально закрыть за 50 минут 🔍Посчитаем нагрузку и хранение руками: 2 млн в сутки, вечерний пик х5, запас на год, и на выходе цифры, под которые дальше и рисуется схема 🔍Разберёмся с углублёнными вопросами, на которых ломаются заученные решения: потери, дубли, тормозящий провайдер 🔍Также Олег подробно расскажет про свой курс по System Design, который как раз заточен на прохождение собесов После урока у тебя будет понятный порядок действий на секцию: что спросить в начале, что посчитать, что рисовать и в каком порядке всё это говорить. Урок бесплатный и ссылка на него будет в этом телеграм-канале⬇️ 🔨Перейти в канал с уроком P.S. Напоминаю что урок будет уже в этот четверг и записи, если что, не будет #промо #текст_прислан
Небольшая инженерная задачка, чтобы размяться Ты пилишь сервис… — Николай Тузов — TG.ME
August 24, 2026 6.6K 11 34