Товарищи, Поступашкам нужны контент мейкеры в основной канал по алгоритмам и другим дисциплинам. Если вы творческая личность, интересующейся алгоритмами (или другим), вам нравится писать посты/ придумывать идеи для контента, то обязательно пишите @vice22821. Оплата сдельная, ориентировочно за один пост от 2 тыс до 15 тыс рублей.
Обязательно делитесь с ребятами, которым это может быть интересно.
Обязательно делитесь с ребятами, которым это может быть интересно.
🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Залетаем с ноги в Яндекс: регистрация проходит до октября, а задания уже лежат тут.
А чтобы ты точно получил оффер, мы уже сделали разбор контеста и технических этапов, они доступны нашим студентам на наших курсах:
Помимо разборов, которые проходят все скрытые тесты на наличие ИИ в решениях, на наших курсах вы получаете:
🔽 Доступ к закрытой базе собесов и тестовых заданий🔽 Разбор стажировки ДС Авито (на МЛ ПРО и ИИ агенты ПРО)🔽 Курс по выходу на доход в валюте🔽 Гарантия оффера🔽 Рефералка в бигтех после защиты пет-проекта🔽 mock-собеседования с обратной связью
Успей написать администратору и не откладывай: задания могут скоро поменять!
Please open Telegram to view this post
VIEW IN TELEGRAM
Полный цикл собесов в Яндекс (Бэкенд 2026)
Сейчас студенты наших курсов под чутким сопровождением проходят отборы в Яндекс, поэтому продолжаю радовать вас инсайдами и актуальными вопросами. Далее представлен слегка отредактированный текст нашего студента. Кстати разбор стажировки Яндекс и Яндекс Intern Week Offer по бэкенду уже выложен на наших курсах Бэкенд ПРО, Алгоритмы ПРО.
➡️ Записаться
Вступительный контест
Началось всё с Яндекс Контеста. На текущем наборе после подачи через yaintern приходит ссылка на пять задач, запустить его можно в любой момент в течение недели. На решение пяти задач дается пять часов, решать можно на любом языке, независимо от того, какой ты указал в анкете.
Я решил четыре задачи из пяти. Пятую посмотрел в разборе на курсе и попросил GPT переписать код, чтобы антиплагиат не нашёл совпадения. Четырёх хватило, хотя я часто слышал от ребят в чате, что проходили и с тремя, так что не стоит ставить на себе крест, если контест не закрыт полностью.
Также тут стоит отметить, что на контесте включён антиплагиат, и тут я советую следующее, как я сам обходил систему при использовании решения от GPT:
- руками вписывать решение, а не копировать из буфера обмена;
- не выделять и копировать условие, лучше сделать скрин и его уже отправить нейронке;
- не отправлять сразу лучшее решение, если у вас все пять задач с первой посылки решены верно, то либо вы гений, либо мухлюете;
- постарайтесь равномерно по времени делать посылки, а не закидывать все сразу, это первый звоночек, что вы решили их нечестно.
Что после контеста
Если приглашение долго не приходит, можно написать на intern@yandex-team.ru, другу это сдвигало процесс. Ещё нюанс: лучше отдельно уточнять у HR город стажировки, ведь информация на сайте и фактический набор могут отличаться.
Дальше технические интервью. Их было два, каждое примерно по часу, в Zoom, с камерой и редактором без автокомплита и нельзя запускать код, так будьте к такому готовы, заранее стоит потренироваться писать все руками и прогонять код в голове.
Алгособес
На первом дали палиндром, с которым я справился быстро. Потом попросили найти максимальную палиндромную подстроку. Я её быстренько решил, так как это довольно известная задача. Следующей задачей была LRU Cache, здесь уже подольше посидеть пришлось. И напоследок удаление n-й ноды с конца связного списка.
Технический
Второй собес начался со скобочной последовательности на стек, тоже быстро, а затем перешли к Go. Нужно было реализовать обход сайта по ссылкам, используя функции загрузки страницы, извлечения домена и парсинга ссылок, а после этого решение попросили распараллелить с ограничением числа воркеров. После алгоритмов пошли вопросы по Go: чем отличаются слайсы от массивов, как устроены map, как работают горутины и каналы, для чего нужен context и что делают defer, panic и recover.
Задачи во многом пересекались с ранжированным списком Поступашек, так что перед отбором стоит заранее прорешать задачи оттуда.
Финальные собесы с командами
После техсекций HR согласовала встречи с двумя командами. Первый собес прошёл в формате вайбчека. Интервьюер и я оказались с одного вуза, и у нас было то же направление, только на восемь лет раньше, поэтому разговор быстро ушёл в университет: что изменилось, те ли преподаватели остались. Затем попросили рассказать о нескольких пет-проектах, их задачах, стеке и результате. Я спросил, есть ли места после стажировки, мне честно ответили, что нет, но это меня не остановило, и я ответил, что всё равно готов пойти к ним в команду.
На втором собесе код тоже не писали, но обсуждали более прикладную задачу. Нужно было словами описать worker pool с graceful shutdown, где воркеры берут задачи из канала, после сигнала перестают принимать новые задачи, а WaitGroup дожидается завершения текущих задач. Отсюда вышли на мьютексы и другие примитивы синхронизации, а затем обсудили масштабирование: сколько запускать воркеров, зачем нужен буфер при всплесках нагрузки и когда стоит переходить на распределённую очередь.
В итоге обе команды были готовы меня принять, и я выбрал вторую из-за открытой позиции в штат команды. Если команда не может взять стажёра, HR подбирает другие варианты.
Я рекомендую при отборе в Яндекс иметь уверенную базу в алгоритмах, попадаются задачи разного уровня, поэтому стоит быть готовым ко всему. Также подтянуть знания по языку и сетям и ОС, всегда могут и по ним спросить. Ну и главное, это не бояться, если чего-то забыли или не знаете, всегда можно побеседовать с интервьюером и попробовать прийти к правильному ответу, это лучше, чем просто молчать или сдаться.
Подписаться: @codeof_art
Сейчас студенты наших курсов под чутким сопровождением проходят отборы в Яндекс, поэтому продолжаю радовать вас инсайдами и актуальными вопросами. Далее представлен слегка отредактированный текст нашего студента. Кстати разбор стажировки Яндекс и Яндекс Intern Week Offer по бэкенду уже выложен на наших курсах Бэкенд ПРО, Алгоритмы ПРО.
Вступительный контест
Началось всё с Яндекс Контеста. На текущем наборе после подачи через yaintern приходит ссылка на пять задач, запустить его можно в любой момент в течение недели. На решение пяти задач дается пять часов, решать можно на любом языке, независимо от того, какой ты указал в анкете.
Я решил четыре задачи из пяти. Пятую посмотрел в разборе на курсе и попросил GPT переписать код, чтобы антиплагиат не нашёл совпадения. Четырёх хватило, хотя я часто слышал от ребят в чате, что проходили и с тремя, так что не стоит ставить на себе крест, если контест не закрыт полностью.
Также тут стоит отметить, что на контесте включён антиплагиат, и тут я советую следующее, как я сам обходил систему при использовании решения от GPT:
- руками вписывать решение, а не копировать из буфера обмена;
- не выделять и копировать условие, лучше сделать скрин и его уже отправить нейронке;
- не отправлять сразу лучшее решение, если у вас все пять задач с первой посылки решены верно, то либо вы гений, либо мухлюете;
- постарайтесь равномерно по времени делать посылки, а не закидывать все сразу, это первый звоночек, что вы решили их нечестно.
Что после контеста
Если приглашение долго не приходит, можно написать на intern@yandex-team.ru, другу это сдвигало процесс. Ещё нюанс: лучше отдельно уточнять у HR город стажировки, ведь информация на сайте и фактический набор могут отличаться.
Дальше технические интервью. Их было два, каждое примерно по часу, в Zoom, с камерой и редактором без автокомплита и нельзя запускать код, так будьте к такому готовы, заранее стоит потренироваться писать все руками и прогонять код в голове.
Алгособес
На первом дали палиндром, с которым я справился быстро. Потом попросили найти максимальную палиндромную подстроку. Я её быстренько решил, так как это довольно известная задача. Следующей задачей была LRU Cache, здесь уже подольше посидеть пришлось. И напоследок удаление n-й ноды с конца связного списка.
Технический
Второй собес начался со скобочной последовательности на стек, тоже быстро, а затем перешли к Go. Нужно было реализовать обход сайта по ссылкам, используя функции загрузки страницы, извлечения домена и парсинга ссылок, а после этого решение попросили распараллелить с ограничением числа воркеров. После алгоритмов пошли вопросы по Go: чем отличаются слайсы от массивов, как устроены map, как работают горутины и каналы, для чего нужен context и что делают defer, panic и recover.
Задачи во многом пересекались с ранжированным списком Поступашек, так что перед отбором стоит заранее прорешать задачи оттуда.
Финальные собесы с командами
После техсекций HR согласовала встречи с двумя командами. Первый собес прошёл в формате вайбчека. Интервьюер и я оказались с одного вуза, и у нас было то же направление, только на восемь лет раньше, поэтому разговор быстро ушёл в университет: что изменилось, те ли преподаватели остались. Затем попросили рассказать о нескольких пет-проектах, их задачах, стеке и результате. Я спросил, есть ли места после стажировки, мне честно ответили, что нет, но это меня не остановило, и я ответил, что всё равно готов пойти к ним в команду.
На втором собесе код тоже не писали, но обсуждали более прикладную задачу. Нужно было словами описать worker pool с graceful shutdown, где воркеры берут задачи из канала, после сигнала перестают принимать новые задачи, а WaitGroup дожидается завершения текущих задач. Отсюда вышли на мьютексы и другие примитивы синхронизации, а затем обсудили масштабирование: сколько запускать воркеров, зачем нужен буфер при всплесках нагрузки и когда стоит переходить на распределённую очередь.
В итоге обе команды были готовы меня принять, и я выбрал вторую из-за открытой позиции в штат команды. Если команда не может взять стажёра, HR подбирает другие варианты.
Я рекомендую при отборе в Яндекс иметь уверенную базу в алгоритмах, попадаются задачи разного уровня, поэтому стоит быть готовым ко всему. Также подтянуть знания по языку и сетям и ОС, всегда могут и по ним спросить. Ну и главное, это не бояться, если чего-то забыли или не знаете, всегда можно побеседовать с интервьюером и попробовать прийти к правильному ответу, это лучше, чем просто молчать или сдаться.
Подписаться: @codeof_art
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3🔥2
Новый пост из серии про паттерны на реальном коде. Разбираем штуку, с которой рано или поздно встречается любой сервис, живущий в интернете: в него начинают лить больше, чем он способен переварить.
Ситуация простая. У тебя есть сервис, который что-то принимает извне — запросы, события, сообщения. И в какой-то момент поток на входе становится больше, чем ты успеваешь обрабатывать. Причины разные: у клиента выкатили баг, и он спамит одним и тем же по кругу; резкий наплыв пользователей; банальный DDoS. Если просто сидеть и принимать всё подряд, исход один из двух — либо сервис ложится под нагрузкой, либо копит необработанное в памяти, пока она не кончится, и падает уже намертво. Защита от этого называется backpressure: сервис не молча захлёбывается, а сам говорит источникам «э, притормозите».
Разберём на Sentry. Если не знаком: это сервис, куда приложения шлют информацию о своих ошибках и падениях — упало что-то в проде, полетел отчёт с деталями, разработчики видят его в удобном интерфейсе, а не роются в логах. Нагрузка у неё дикая: тысячи чужих приложений долбят её событиями безостановочно. На входе у Sentry стоит отдельный компонент — Relay, он первым встречает весь этот поток и решает, что с ним делать. На нём и посмотрим, как грамотно держать удар. Код открыт: https://github.com/getsentry/relay
Первое, что там сделано с умом, — ограничение стоит не одним общим рубильником на всё, а раздельно, по типам данных и по каждому проекту. Можно прижать один вид событий у одного клиента, не задев остальной трафик. Клиенту, который упёрся в лимит, прилетает ответ 429 и заголовок с числом: «подожди столько-то секунд». И вот ключевая тонкость: правильный клиент в ответ на это НЕ шлёт то же самое заново — он выбрасывает событие и ждёт. Потому что если в ответ на «перегруз» все дружно начнут повторять запросы, они этим перегруз только усилят. В этом и суть backpressure: смысл ответа — «перестань слать вообще», а не «попробуй ещё разок». Обычная ошибка говорит «повтори», backpressure говорит «уймись» — это разные вещи.
Второй умный момент — как Relay хранит сами лимиты. Он держит их в памяти и освежает раз в несколько минут, а не бегает во внешнее хранилище на каждое событие (иначе оно само стало бы узким горлышком). Отсюда забавная деталь: самый первый запрос, упёршийся в свежий лимит, может ещё проскочить с ответом 200 — просто потому что в памяти лимит ещё не обновился, а следующий уже получит честный отказ. Осознанный размен: чуть менее точно, зато во много раз дешевле под нагрузкой. Клиентов, которые давно в лимите, Relay отшивает вообще бесплатно — их «приговор» уже лежит в памяти.
Третий уровень — что делать с тем, что уже приняли, но обработать пока не успели. Relay складывает такие события в очередь в памяти, но следит за её размером: пока памяти занято меньше порога (по умолчанию 80%) — держит очередь в ней, ради скорости. Перевалило за порог — начинает скидывать на диск. Медленнее, зато не сожрёт всю память и не рухнет, пока разгребает завал. Такой буфер сглаживает всплеск: не теряем события и не падаем от переполнения памяти.
Теперь — как это утащить к себе, даже без всякого Sentry. Принцип работает везде, где что-то принимает поток извне. Пишешь API, которое дёргают чужие сервисы? Отдавай на перегрузе честный 429 с «подожди столько-то», а не пытайся героически переварить всё и не роняй сервер. Обрабатываешь очередь сообщений? Следи за её длиной и умей притормозить того, кто в неё пишет. Ходишь во внешний API сам? Уважай его 429 и не ретрай мгновенно — ты этим только добьёшь того, кто и так лежит.
И три мысли на вынос. Лимиты делай точечными, а не «рубильник на всё сразу». Сигнал перегруза — это «перестань», а не «повтори», и клиенты должны его уважать. И заранее думай, что делать с тем, что уже принял, но не осилил, — буфер с выходом на диск лучше, чем гордое падение. Наивное «очередь большая — верну 500» не делает ничего из этого, поэтому и падает первым.
Подписаться: @codeof_art
Вступить в чатик: @code_of_art
Ситуация простая. У тебя есть сервис, который что-то принимает извне — запросы, события, сообщения. И в какой-то момент поток на входе становится больше, чем ты успеваешь обрабатывать. Причины разные: у клиента выкатили баг, и он спамит одним и тем же по кругу; резкий наплыв пользователей; банальный DDoS. Если просто сидеть и принимать всё подряд, исход один из двух — либо сервис ложится под нагрузкой, либо копит необработанное в памяти, пока она не кончится, и падает уже намертво. Защита от этого называется backpressure: сервис не молча захлёбывается, а сам говорит источникам «э, притормозите».
Разберём на Sentry. Если не знаком: это сервис, куда приложения шлют информацию о своих ошибках и падениях — упало что-то в проде, полетел отчёт с деталями, разработчики видят его в удобном интерфейсе, а не роются в логах. Нагрузка у неё дикая: тысячи чужих приложений долбят её событиями безостановочно. На входе у Sentry стоит отдельный компонент — Relay, он первым встречает весь этот поток и решает, что с ним делать. На нём и посмотрим, как грамотно держать удар. Код открыт: https://github.com/getsentry/relay
Первое, что там сделано с умом, — ограничение стоит не одним общим рубильником на всё, а раздельно, по типам данных и по каждому проекту. Можно прижать один вид событий у одного клиента, не задев остальной трафик. Клиенту, который упёрся в лимит, прилетает ответ 429 и заголовок с числом: «подожди столько-то секунд». И вот ключевая тонкость: правильный клиент в ответ на это НЕ шлёт то же самое заново — он выбрасывает событие и ждёт. Потому что если в ответ на «перегруз» все дружно начнут повторять запросы, они этим перегруз только усилят. В этом и суть backpressure: смысл ответа — «перестань слать вообще», а не «попробуй ещё разок». Обычная ошибка говорит «повтори», backpressure говорит «уймись» — это разные вещи.
Второй умный момент — как Relay хранит сами лимиты. Он держит их в памяти и освежает раз в несколько минут, а не бегает во внешнее хранилище на каждое событие (иначе оно само стало бы узким горлышком). Отсюда забавная деталь: самый первый запрос, упёршийся в свежий лимит, может ещё проскочить с ответом 200 — просто потому что в памяти лимит ещё не обновился, а следующий уже получит честный отказ. Осознанный размен: чуть менее точно, зато во много раз дешевле под нагрузкой. Клиентов, которые давно в лимите, Relay отшивает вообще бесплатно — их «приговор» уже лежит в памяти.
Третий уровень — что делать с тем, что уже приняли, но обработать пока не успели. Relay складывает такие события в очередь в памяти, но следит за её размером: пока памяти занято меньше порога (по умолчанию 80%) — держит очередь в ней, ради скорости. Перевалило за порог — начинает скидывать на диск. Медленнее, зато не сожрёт всю память и не рухнет, пока разгребает завал. Такой буфер сглаживает всплеск: не теряем события и не падаем от переполнения памяти.
Теперь — как это утащить к себе, даже без всякого Sentry. Принцип работает везде, где что-то принимает поток извне. Пишешь API, которое дёргают чужие сервисы? Отдавай на перегрузе честный 429 с «подожди столько-то», а не пытайся героически переварить всё и не роняй сервер. Обрабатываешь очередь сообщений? Следи за её длиной и умей притормозить того, кто в неё пишет. Ходишь во внешний API сам? Уважай его 429 и не ретрай мгновенно — ты этим только добьёшь того, кто и так лежит.
И три мысли на вынос. Лимиты делай точечными, а не «рубильник на всё сразу». Сигнал перегруза — это «перестань», а не «повтори», и клиенты должны его уважать. И заранее думай, что делать с тем, что уже принял, но не осилил, — буфер с выходом на диск лучше, чем гордое падение. Наивное «очередь большая — верну 500» не делает ничего из этого, поэтому и падает первым.
Подписаться: @codeof_art
Вступить в чатик: @code_of_art
❤3⚡2
Ты поступишь в ШАД
Старт набора на наши ШАДовские курсы: без воды и лишней теории, 3 месяца семинаров, пробников и лекций! За результат отвечаем⭐️ пройдешь курсы, но не поступишь в ШАД - вернем деньги⭐️ Программы и подробности:
⏩ Алгоритмы
⏩ Анализ данных
⏩ Линейная алгебра
⏩ Теория вероятностей
⏩ Дискретная математика
⏩ Математический анализ
Можно взять один курс, или комбо по спеццене! Даже все 6 сразу — программа выстроена так, что ты все успеешь. Не веришь — чекай отзывы наших выпускников!
Курсы для тебя, если ты:
🔵 Только задумался о подготовке
🔵 Уже готовился, но не уверен в себе
🔵 Подзабыл математику, но хочешь в ШАД
🔵 Хочешь совмещать подготовку с работой
🔵 Готовишься к собесам в BigTech, АА и маги
Записи и материалы остаются навсегда, а сдать ДЗ, пробники, пройти мок-собес и получить фидбэк куратора можно после окончания курса!
Только у нас ты получишь:
Для вопросов и записи пиши менджеру: @menshe_treh▶️
Старт набора на наши ШАДовские курсы: без воды и лишней теории, 3 месяца семинаров, пробников и лекций! За результат отвечаем
Можно взять один курс, или комбо по спеццене! Даже все 6 сразу — программа выстроена так, что ты все успеешь. Не веришь — чекай отзывы наших выпускников!
Курсы для тебя, если ты:
Записи и материалы остаются навсегда, а сдать ДЗ, пробники, пройти мок-собес и получить фидбэк куратора можно после окончания курса!
Только у нас ты получишь:
🔵 Онлайн-семинары, лекции, ДЗ и пробники с проверкой🔵 Разбор отбора 2027, саппорт с анкетой и мотивацией🔵 Доступ к закрытой базе знаний и протоколам ШАД🔵 Пробное тестирование, экзамен и собеседование🔵 Сборник всех задач ШАДа для самоподготовки
Для вопросов и записи пиши менджеру: @menshe_treh
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Осень обычно время, когда компании запускают свои образовательные потоки, и в этом году многие уже успели закрыть набор. Я прошёлся по крупным программам и оставил только те, куда реально можно подать заявку сейчас и где учёба начинается в ближайшие недели. Всё бесплатно, а лучших выпускников почти везде зовут на стажировку.
Начнём с самого срочного. YADRO набирает студентов на курс «Системное программирование с использованием языка C». Заявки принимают до 28 сентября, то есть до завтра, так что если давно хотел разобраться, как код работает поближе к железу, откладывать некуда. Дальше будет отбор с 29 сентября по 12 октября, а занятия стартуют 19 октября и идут раз в неделю до мая. Формат онлайн, большая часть времени уходит на практику с разбором домашек от инженеров компании, а самых сильных участников приглашают на стажировку в YADRO. Подать заявку могут студенты со второго курса. После окончания регистрации на канале будет оперативно выложен разбор тестового задания.
Если хочется войти в разработку с нуля и без всякого профильного бэкграунда, стоит посмотреть на Школу 21 от Сбера. Поступление идёт через «бассейн», двухнедельный очный интенсив в кампусе, на котором как раз погружают в основы и командную работу. Ближайшие бассейны пройдут в Магасе с 12 октября (заявки до 7 октября, иногородним там ещё и дают бесплатное жильё), в Ярославле тоже с 12 октября и в Казани с 26 октября. Участвовать может любой человек старше 18 лет, опыт программирования не нужен.
Напоследок вариант для тех, кто не хочет привязываться к расписанию. У VK Education открыт набор на асинхронные курсы, среди которых есть «Системное программирование», «Алгоритмы и структуры данных» и «Базовый Python». Лекции уже записаны, смотреть их можно в своём темпе, а подать заявку получится до 31 декабря. Неплохой способ подтянуть базу параллельно с учёбой или работой.
Подписаться: @codeof_art
Вступить в чатик: @code_of_art
Начнём с самого срочного. YADRO набирает студентов на курс «Системное программирование с использованием языка C». Заявки принимают до 28 сентября, то есть до завтра, так что если давно хотел разобраться, как код работает поближе к железу, откладывать некуда. Дальше будет отбор с 29 сентября по 12 октября, а занятия стартуют 19 октября и идут раз в неделю до мая. Формат онлайн, большая часть времени уходит на практику с разбором домашек от инженеров компании, а самых сильных участников приглашают на стажировку в YADRO. Подать заявку могут студенты со второго курса. После окончания регистрации на канале будет оперативно выложен разбор тестового задания.
Если хочется войти в разработку с нуля и без всякого профильного бэкграунда, стоит посмотреть на Школу 21 от Сбера. Поступление идёт через «бассейн», двухнедельный очный интенсив в кампусе, на котором как раз погружают в основы и командную работу. Ближайшие бассейны пройдут в Магасе с 12 октября (заявки до 7 октября, иногородним там ещё и дают бесплатное жильё), в Ярославле тоже с 12 октября и в Казани с 26 октября. Участвовать может любой человек старше 18 лет, опыт программирования не нужен.
Напоследок вариант для тех, кто не хочет привязываться к расписанию. У VK Education открыт набор на асинхронные курсы, среди которых есть «Системное программирование», «Алгоритмы и структуры данных» и «Базовый Python». Лекции уже записаны, смотреть их можно в своём темпе, а подать заявку получится до 31 декабря. Неплохой способ подтянуть базу параллельно с учёбой или работой.
Подписаться: @codeof_art
Вступить в чатик: @code_of_art
🔥3❤2⚡2
System Design: backend
Эту задачу дают на бэковых собесах в Ozon, и звучит она затрагивает максимально типичную задачу. Есть сервис, который принимает оплату заказа. Когда платёж прошёл, складу нужно узнать, что заказ оплачен и его можно собирать, поэтому сервис отправляет событие в Kafka. Интервьюер описывает ситуацию, в которой платёж уже записан в базу, а Kafka именно в эту секунду недоступна, и просит рассказать, что будет с заказом и как сделать так, чтобы ничего не потерялось. Большинство кандидатов в этот момент рисуют ровно тот код, который потом и разбирают на части.
Выглядит он так: сначала коммитим платёж в базу, потом отправляем событие в брокер. Проблема в том, что это две операции в двух разных системах, и между ними может случиться что угодно. Процесс упадёт после коммита или сеть пропадёт на полсекунды, и в итоге деньги у клиента списаны, а склад про заказ так и не узнал. Если поменять порядок и сначала отправить событие, получится зеркальная беда, потому что транзакция в базе может откатиться уже после того, как склад начал собирать заказ, за который никто не заплатил. Хороший кандидат на этом месте останавливается и спрашивает интервьюера, что для бизнеса хуже, потерять событие или получить его два раза. Ответ почти всегда одинаковый. Потерянный заказ обходится дороже, потому что о нём никто не узнает, пока клиент не придёт ругаться в поддержку, а лишнюю копию события получатель может просто отбросить. Раз так, задача сводится к тому, чтобы гарантировать доставку хотя бы один раз и научить получателя спокойно относиться к повторам.
Для этого используют приём, который называется Transactional Outbox. В той же базе, где лежат платежи, заводится отдельная таблица для исходящих событий, и строка в неё пишется в той же транзакции, что и сам платёж. База умеет гарантировать атомарность внутри себя, поэтому после коммита у нас либо есть и платёж, и событие о нём, либо нет ни того, ни другого. В Kafka эти строки перекладывает отдельный процесс, его обычно называют реле. Он берёт из таблицы то, что ещё не отправлено, публикует в брокер и только после подтверждения помечает строку как отправленную. Если реле упадёт между публикацией и пометкой, после перезапуска оно отправит те же строки повторно, и здесь становится понятно, зачем вопрос про дубли задавали в самом начале. Когда экземпляров реле несколько, строки удобно разбирать через SELECT FOR UPDATE SKIP LOCKED, чтобы два процесса не схватили одну запись, а ключом сообщения лучше делать id заказа, тогда все события одного заказа попадут в одну партицию и склад получит их в правильном порядке.
Раз повторы стали нормальной частью системы, получатель обязан с ними справляться. Склад хранит идентификаторы уже обработанных событий и просто пропускает те, что видел раньше. Если про это забыть, Outbox решит проблему у отправителя и тут же создаст новую у склада, где один и тот же заказ начнут собирать дважды. Обычно после этого интервьюер переходит к эксплуатации. Опрашивать таблицу раз в секунду можно, но это нагружает базу и добавляет задержку, поэтому в больших системах изменения часто читают прямо из журнала транзакций с помощью CDC вроде Debezium. Отправленные строки со временем нужно чистить, иначе таблица событий разрастётся быстрее самих платежей. Для мониторинга хватает одной метрики, возраста самой старой неотправленной строки. Если он начал расти, значит реле встало или брокер лежит, и лучше узнать об этом от алерта, чем от склада.
По сути интервьюер проверяет, замечаешь ли ты, что запись в базу и отправка в брокер по умолчанию никак не связаны между собой, и можешь ли собрать схему, в которой событие гарантированно доедет, а его повтор никому не навредит.
Подписаться: @codeof_art
Вступить в чатик: @code_of_art
Эту задачу дают на бэковых собесах в Ozon, и звучит она затрагивает максимально типичную задачу. Есть сервис, который принимает оплату заказа. Когда платёж прошёл, складу нужно узнать, что заказ оплачен и его можно собирать, поэтому сервис отправляет событие в Kafka. Интервьюер описывает ситуацию, в которой платёж уже записан в базу, а Kafka именно в эту секунду недоступна, и просит рассказать, что будет с заказом и как сделать так, чтобы ничего не потерялось. Большинство кандидатов в этот момент рисуют ровно тот код, который потом и разбирают на части.
Выглядит он так: сначала коммитим платёж в базу, потом отправляем событие в брокер. Проблема в том, что это две операции в двух разных системах, и между ними может случиться что угодно. Процесс упадёт после коммита или сеть пропадёт на полсекунды, и в итоге деньги у клиента списаны, а склад про заказ так и не узнал. Если поменять порядок и сначала отправить событие, получится зеркальная беда, потому что транзакция в базе может откатиться уже после того, как склад начал собирать заказ, за который никто не заплатил. Хороший кандидат на этом месте останавливается и спрашивает интервьюера, что для бизнеса хуже, потерять событие или получить его два раза. Ответ почти всегда одинаковый. Потерянный заказ обходится дороже, потому что о нём никто не узнает, пока клиент не придёт ругаться в поддержку, а лишнюю копию события получатель может просто отбросить. Раз так, задача сводится к тому, чтобы гарантировать доставку хотя бы один раз и научить получателя спокойно относиться к повторам.
Для этого используют приём, который называется Transactional Outbox. В той же базе, где лежат платежи, заводится отдельная таблица для исходящих событий, и строка в неё пишется в той же транзакции, что и сам платёж. База умеет гарантировать атомарность внутри себя, поэтому после коммита у нас либо есть и платёж, и событие о нём, либо нет ни того, ни другого. В Kafka эти строки перекладывает отдельный процесс, его обычно называют реле. Он берёт из таблицы то, что ещё не отправлено, публикует в брокер и только после подтверждения помечает строку как отправленную. Если реле упадёт между публикацией и пометкой, после перезапуска оно отправит те же строки повторно, и здесь становится понятно, зачем вопрос про дубли задавали в самом начале. Когда экземпляров реле несколько, строки удобно разбирать через SELECT FOR UPDATE SKIP LOCKED, чтобы два процесса не схватили одну запись, а ключом сообщения лучше делать id заказа, тогда все события одного заказа попадут в одну партицию и склад получит их в правильном порядке.
Раз повторы стали нормальной частью системы, получатель обязан с ними справляться. Склад хранит идентификаторы уже обработанных событий и просто пропускает те, что видел раньше. Если про это забыть, Outbox решит проблему у отправителя и тут же создаст новую у склада, где один и тот же заказ начнут собирать дважды. Обычно после этого интервьюер переходит к эксплуатации. Опрашивать таблицу раз в секунду можно, но это нагружает базу и добавляет задержку, поэтому в больших системах изменения часто читают прямо из журнала транзакций с помощью CDC вроде Debezium. Отправленные строки со временем нужно чистить, иначе таблица событий разрастётся быстрее самих платежей. Для мониторинга хватает одной метрики, возраста самой старой неотправленной строки. Если он начал расти, значит реле встало или брокер лежит, и лучше узнать об этом от алерта, чем от склада.
По сути интервьюер проверяет, замечаешь ли ты, что запись в базу и отправка в брокер по умолчанию никак не связаны между собой, и можешь ли собрать схему, в которой событие гарантированно доедет, а его повтор никому не навредит.
Подписаться: @codeof_art
Вступить в чатик: @code_of_art
❤2👍1
Вопросы на System Design в Ozon.pdf
2.1 MB
Ozon: Полный слив направления Go-разработки
Продолжаем грабить бигтехи, чтобы вы реально почувствовали насколько круты наши курсы. Делимся гайдом, на основе внутренних материалов Ozona, которые предоставили наши выпускники: техчасть Go и System Design. Если на языковой секции ты хорошо себя показал и интервьюер видит уровень мидла+, тебя отправляют дальше на архитектурную секцию.
Все закрывается нашими курсами Бэкенд Старт и Бэкенд ПРО.
➡️ Записаться.
В файле самое полезное: ответы разбиты по уровням. Не просто «правильно вот так», а видно, что ждут от джуна, что уже должен знать мидл и где начинается сеньор. Плюс комментарии интервьюера: где ответ выглядит подозрительно, где красный флаг, а где можно, наоборот, хорошо себя показать.
Go — 63 задачи и 7 больших тем: ОС и сети, теория, практика, структуры данных, БД, архитектура и скрининг. Практика — реальные продовые кейсы: код-ревью кеша, странности со слайсами и каналами, проблемы с производительностью. Уточняющие вопросы.
System Design — ещё 33 задачи. Стартует с базовых концептов (CAP, консистентное хеширование, гарантии доставки), а дальше доходит до полноценных кейсов: спроектировать мессенджер, поисковик или Instagram с нуля. С расчётом нагрузки и разбором, где система начнёт разваливаться. Для бота советую наш канал @codeof_art
Еще больше материалов в наших открытых банках собесов.
— Аналитика
— ML & DS
— Бэкенд
— Фронтенд
— Алгоритмы
Обсудить задачи можно в нашей боталке.
Подписаться: @postypashki_old
Продолжаем грабить бигтехи, чтобы вы реально почувствовали насколько круты наши курсы. Делимся гайдом, на основе внутренних материалов Ozona, которые предоставили наши выпускники: техчасть Go и System Design. Если на языковой секции ты хорошо себя показал и интервьюер видит уровень мидла+, тебя отправляют дальше на архитектурную секцию.
Все закрывается нашими курсами Бэкенд Старт и Бэкенд ПРО.
В файле самое полезное: ответы разбиты по уровням. Не просто «правильно вот так», а видно, что ждут от джуна, что уже должен знать мидл и где начинается сеньор. Плюс комментарии интервьюера: где ответ выглядит подозрительно, где красный флаг, а где можно, наоборот, хорошо себя показать.
Go — 63 задачи и 7 больших тем: ОС и сети, теория, практика, структуры данных, БД, архитектура и скрининг. Практика — реальные продовые кейсы: код-ревью кеша, странности со слайсами и каналами, проблемы с производительностью. Уточняющие вопросы.
System Design — ещё 33 задачи. Стартует с базовых концептов (CAP, консистентное хеширование, гарантии доставки), а дальше доходит до полноценных кейсов: спроектировать мессенджер, поисковик или Instagram с нуля. С расчётом нагрузки и разбором, где система начнёт разваливаться. Для бота советую наш канал @codeof_art
Еще больше материалов в наших открытых банках собесов.
— Аналитика
— ML & DS
— Бэкенд
— Фронтенд
— Алгоритмы
Обсудить задачи можно в нашей боталке.
Подписаться: @postypashki_old
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3