Art of Code

Открываем новую серию постов. Смысл такой: берём известный проект, смотрим, как в нём решили какую-нибудь неочевидную проблему, и разбираемся, чем этот приём полезен лично тебе в твоём коде. Без душной теории — только то, что реально пригодится. И начать хочу с истории, которая случалась с каждым, кто хоть раз что-то куда-то сохранял. Ты сохранил данные. Сервис ответил «готово». Ты выдохнул и пошёл дальше. Знакомо? А теперь неприятная новость: «сервис ответил готово» и «данные действительно на месте» — это два разных события. Между ними есть щель, и данные умеют в неё проваливаться. Причём случается это ровно в тот момент, когда что-то ломается, — то есть в самый неподходящий. Чтобы увидеть эту щель во всей красе, посмотрим, как с ней воюет Kafka. А потом вернёмся к твоему коду, потому что проблема там ровно та же. Как Kafka бережёт данные. Она хранит каждую порцию сообщений сразу на нескольких серверах: один главный, он принимает записи, остальные — его копии, они за ним повторяют. Звучит надёжно. Но вот ловушка, в которую попадают почти все. Главный сервер принял сообщение, записал у себя, ответил «принято» — и в следующую секунду умер. А копии не успели повторить за ним. На его место встаёт одна из копий, но у неё этого сообщения нет. Всё, сообщение исчезло. А отправитель-то уверен, что всё хорошо, — ему же ответили «принято». Как эту дыру закрывают. У отправителя есть настройка, которая решает, когда считать сообщение сохранённым. Можно сказать «мне хватит, что его принял главный» — быстро, но это ровно та история с исчезновением. А можно потребовать «считать сохранённым, только когда его повторили и живые копии тоже». Вот тогда появляется настоящая гарантия: даже если главный умрёт, сообщение уже есть на других. Но и это не всё. Что, если копии отстали и по одной повыпадали, а живым остался только главный? Тогда правило «пусть подтвердят копии» тихо превращается в «пусть подтвердит главный» — и мы снова там же, откуда начали. Поэтому есть ещё одна настройка

Второй пост серии про паттерны на реальном коде. В прошлый раз говорили, почему «сохранилось» и «точно сохранилось» — не одно и то же. Сегодня — про идею, на которой держится половина софта вокруг нас, хотя мало кто задумывается про нее. Если тебе приходится запускать чужой код, которому ты не доверяешь, — держи его от себя подальше, в отдельном процессе. Причина простая: чужой код умеет падать, зависать намертво и течь по памяти. Пусти его внутрь своего приложения — и однажды он утащит тебя за собой на дно. А отдельный процесс работает как стена: за ней хоть потоп, а на твою сторону вода не дойдёт. Поэтому одна упавшая вкладка в браузере не роняет остальные, и поэтому же плагины в редакторах живут отдельно от самого редактора. Посмотрим, как это сделано в VS Code — там всё честно и наглядно. Расширения крутятся не внутри редактора, а в собственном процессе, у него и название есть — extension host. Замысел в одну строчку: что бы ни стряслось с расширениями, редактор обязан устоять. И он выдерживает. Процесс с расширениями рухнул целиком — а редактор даже бровью не повёл: курсор мигает, текст на месте, файл спокойно сохраняется. Разработчики так и ставили задачу — пусть расширения хоть все разом отвалятся, но ни строчки твоей работы пропасть при этом не должно. Когда процесс падает, сверху выезжает плашка «расширения отключились, перезапустить?», жмёшь — и он поднимается заново. На то он и отдельный, что пересоздать его можно, ничего вокруг не задев. А теперь то, из-за чего у людей годами пригорает. Стена стоит между редактором и расширениями — но между самими расширениями никакой стены нет. Все они набиты в один общий процесс и делят на всех единственный поток выполнения. А в JavaScript поток ровно один. И получается некрасивое: стоит одному расширению уйти в тяжёлые вычисления и занять поток надолго — как замирают вообще все расширения сразу. Не только виновник, а все соседи по процессу. Человек видит, что редактор целиком отупел и не реагирует, ругает VS Code

System Design: frontend Сегодня разберём задачу с собеса в геодезическую компанию — из тех, где приложение для полевых работ должно работать там, где связи нет в принципе. Спроектируй фронт, который живёт без интернета: специалист видит данные, что-то в них меняет, а когда сеть возвращается — всё уезжает на сервер и синхронизируется. Почему такое вообще спрашивают. Геодезист выезжает на объект — поле, стройка, лес за городом, — и связи там может не быть весь день. А работать надо: открыть карту участка, занести замеры, отметить точки, что-то поправить. Если приложение при потере сети показывает белый экран, им попросту нельзя пользоваться в поле. Значит, оно должно работать так, будто интернет и не нужен, а сеть подхватывать само, когда специалист вернётся в зону покрытия. Первое, что хочется ляпнуть, — «закешируем данные и всё». И вот это ловушка. Как только ты разрешаешь не только читать офлайн, но и менять данные, ты, по сути, строишь маленькую распределённую систему: у тебя появляется две копии правды (на устройстве и на сервере), и они умеют разъезжаться. Все классические боли распределёнки — конфликты, рассинхрон, порядок операций — теперь твои. Не подумал про них — решение развалится на первом же реальном сценарии. Поэтому до того как проектировать, спроси интервьюера две вещи. Первая: что именно должно пахать офлайн — только чтение или запись тоже? Это небо и земля по сложности. Чисто чтение — задачка на кэш. Запись — уже та самая распределёнка. Вторая, и это гвоздь всей задачи: что делать, если геодезист поменял данные офлайн, а на сервере их за это время тоже кто-то поменял — например, коллега в офисе? Пока ты не ответил, как разруливать такой конфликт, — задача не закрыта. Теперь как устроено внутри. Данные храним прямо на устройстве. Для структурированных данных — IndexedDB (это встроенная в браузер база; localStorage не годится — он крохотный и синхронный, тормозит всё вокруг). Картинки, стили, саму оболочку приложения кладём через Service Worker —

System Design: backend Сегодня разберём задачу, которую мне давали на собесе в Яндекс. Штука на стыке проектирования и алгоритмов: мало накидать красивую схему на доске — надо ещё нормально объяснить, как данные поедут через систему. И вот тут сразу видно, шаришь ты или просто заучил модные слова. Условие такое. Надо забэкапить данные — до терабайта. При сжатии они ужмутся где-то в полтора-три раза. Хранилище, куда мы всё складываем, принимает файлы не больше 100 мегабайт за раз. Нужно собрать конвейер: прочитать данные, сжать, записать. И главный подвох, вокруг которого вся задача: целиком в память это не влезет. Первое, что приходит в голову, — «читаем файл, жмём, отправляем». И это ловушка. Терабайт в оперативку просто не поместится, так что про «прочитать файл целиком» надо забыть сразу. Задача с самого начала не про файл, а про поток: данные текут через тебя, ты хватаешь их по кусочку, обрабатываешь и отпускаешь — и никогда не держишь всё разом. Но прежде чем что-то проектировать, я бы задал интервьюеру один вопрос. Как по мне, ради него задачу и придумали. Что делать, если данные сожмутся хуже обещанного, и очередной сжатый кусок всё равно вылезет за 100 мегабайт? Полтора-три раза — это как средняя температура по больнице, а не гарантия. Попадётся кусок, который жмётся плохо (уже сжатое видео, случайный мусор), — и он не влезет в лимит. Если ты сам спотыкаешься об этот момент, до того как тебя носом ткнули, — считай, полдела сделал: дальше этот вопрос всё равно вылезет. Заодно спроси, нужна ли параллельность и надо ли уметь продолжить с места обрыва, если всё грохнется на середине. Теперь как оно работает внутри. Читаем данные небольшими порциями, каждую жмём и отправляем в хранилище куском не больше лимита. Получается конвейер из трёх шагов: читаем, жмём, отправляем. И логично, чтобы шаги крутились не по очереди, а разом — пока один кусок улетает в хранилище, следующий уже читается, а средний в это время жмётся. Само сжатие — самое прожорливое место, так

Товарищи, Поступашкам нужны контент мейкеры в основной канал по алгоритмам и другим дисциплинам. Если вы творческая личность, интересующейся алгоритмами (или другим), вам нравится писать посты/ придумывать идеи для контента, то обязательно пишите @vice22821. Оплата сдельная, ориентировочно за один пост от 2 тыс до 15 тыс рублей. Обязательно делитесь с ребятами, которым это может быть интересно.

Полный цикл собесов в Яндекс (Бэкенд 2026) Сейчас студенты наших курсов под чутким сопровождением проходят отборы в Яндекс, поэтому продолжаю радовать вас инсайдами и актуальными вопросами. Далее представлен слегка отредактированный текст нашего студента. Кстати разбор стажировки Яндекс и Яндекс Intern Week Offer по бэкенду уже выложен на наших курсах Бэкенд ПРО, Алгоритмы ПРО. ➡️ Записаться Вступительный контест Началось всё с Яндекс Контеста. На текущем наборе после подачи через yaintern приходит ссылка на пять задач, запустить его можно в любой момент в течение недели. На решение пяти задач дается пять часов, решать можно на любом языке, независимо от того, какой ты указал в анкете. Я решил четыре задачи из пяти. Пятую посмотрел в разборе на курсе и попросил GPT переписать код, чтобы антиплагиат не нашёл совпадения. Четырёх хватило, хотя я часто слышал от ребят в чате, что проходили и с тремя, так что не стоит ставить на себе крест, если контест не закрыт полностью. Также тут стоит отметить, что на контесте включён антиплагиат, и тут я советую следующее, как я сам обходил систему при использовании решения от GPT: - руками вписывать решение, а не копировать из буфера обмена; - не выделять и копировать условие, лучше сделать скрин и его уже отправить нейронке; - не отправлять сразу лучшее решение, если у вас все пять задач с первой посылки решены верно, то либо вы гений, либо мухлюете; - постарайтесь равномерно по времени делать посылки, а не закидывать все сразу, это первый звоночек, что вы решили их нечестно. Что после контеста Если приглашение долго не приходит, можно написать на [email protected], другу это сдвигало процесс. Ещё нюанс: лучше отдельно уточнять у HR город стажировки, ведь информация на сайте и фактический набор могут отличаться. Дальше технические интервью. Их было два, каждое примерно по часу, в Zoom, с камерой и редактором без автокомплита и нельзя запускать код, так будьте к такому готовы, заранее стоит потренироваться писать все р

Новый пост из серии про паттерны на реальном коде. Разбираем штуку, с которой рано или поздно встречается любой сервис, живущий в интернете: в него начинают лить больше, чем он способен переварить. Ситуация простая. У тебя есть сервис, который что-то принимает извне — запросы, события, сообщения. И в какой-то момент поток на входе становится больше, чем ты успеваешь обрабатывать. Причины разные: у клиента выкатили баг, и он спамит одним и тем же по кругу; резкий наплыв пользователей; банальный DDoS. Если просто сидеть и принимать всё подряд, исход один из двух — либо сервис ложится под нагрузкой, либо копит необработанное в памяти, пока она не кончится, и падает уже намертво. Защита от этого называется backpressure: сервис не молча захлёбывается, а сам говорит источникам «э, притормозите». Разберём на Sentry. Если не знаком: это сервис, куда приложения шлют информацию о своих ошибках и падениях — упало что-то в проде, полетел отчёт с деталями, разработчики видят его в удобном интерфейсе, а не роются в логах. Нагрузка у неё дикая: тысячи чужих приложений долбят её событиями безостановочно. На входе у Sentry стоит отдельный компонент — Relay, он первым встречает весь этот поток и решает, что с ним делать. На нём и посмотрим, как грамотно держать удар. Код открыт: https://github.com/getsentry/relay Первое, что там сделано с умом, — ограничение стоит не одним общим рубильником на всё, а раздельно, по типам данных и по каждому проекту. Можно прижать один вид событий у одного клиента, не задев остальной трафик. Клиенту, который упёрся в лимит, прилетает ответ 429 и заголовок с числом: «подожди столько-то секунд». И вот ключевая тонкость: правильный клиент в ответ на это НЕ шлёт то же самое заново — он выбрасывает событие и ждёт. Потому что если в ответ на «перегруз» все дружно начнут повторять запросы, они этим перегруз только усилят. В этом и суть backpressure: смысл ответа — «перестань слать вообще», а не «попробуй ещё разок». Обычная ошибка говорит «повтори», backpr

System Design: backend Эту задачу дают на бэковых собесах в Ozon, и звучит она затрагивает максимально типичную задачу. Есть сервис, который принимает оплату заказа. Когда платёж прошёл, складу нужно узнать, что заказ оплачен и его можно собирать, поэтому сервис отправляет событие в Kafka. Интервьюер описывает ситуацию, в которой платёж уже записан в базу, а Kafka именно в эту секунду недоступна, и просит рассказать, что будет с заказом и как сделать так, чтобы ничего не потерялось. Большинство кандидатов в этот момент рисуют ровно тот код, который потом и разбирают на части. Выглядит он так: сначала коммитим платёж в базу, потом отправляем событие в брокер. Проблема в том, что это две операции в двух разных системах, и между ними может случиться что угодно. Процесс упадёт после коммита или сеть пропадёт на полсекунды, и в итоге деньги у клиента списаны, а склад про заказ так и не узнал. Если поменять порядок и сначала отправить событие, получится зеркальная беда, потому что транзакция в базе может откатиться уже после того, как склад начал собирать заказ, за который никто не заплатил. Хороший кандидат на этом месте останавливается и спрашивает интервьюера, что для бизнеса хуже, потерять событие или получить его два раза. Ответ почти всегда одинаковый. Потерянный заказ обходится дороже, потому что о нём никто не узнает, пока клиент не придёт ругаться в поддержку, а лишнюю копию события получатель может просто отбросить. Раз так, задача сводится к тому, чтобы гарантировать доставку хотя бы один раз и научить получателя спокойно относиться к повторам. Для этого используют приём, который называется Transactional Outbox. В той же базе, где лежат платежи, заводится отдельная таблица для исходящих событий, и строка в неё пишется в той же транзакции, что и сам платёж. База умеет гарантировать атомарность внутри себя, поэтому после коммита у нас либо есть и платёж, и событие о нём, либо нет ни того, ни другого. В Kafka эти строки перекладывает отдельный процесс, его обыч

ШАД и Лаборатории ШАД — это не просто диплом и не просто строчка в резюме. Это еще и доступ к специалистам, которые делают науку и индустрию. Но работают они в разных местах, и далеко не везде ШАД одинаково ценят. Где-то он открывает двери, а где-то на него вообще не смотрят. Мы собрали два списка, чтобы ты понимал, куда идти, если хочешь использовать ШАД как трамплин, а куда — если у тебя другие цели. Где ШАД в плюс - Лаборатория компьютерной графики и мультимедиа ВМК МГУ - её заведующий ведёт в ШАДе компьютерное зрение - AIRI - в ШАДе преподают руководители групп «Пространственный интеллект» и FusionBrain.Robotics, а также старший научный сотрудник института - Группа генеративного ИИ Сколтеха - её руководитель сам выпускник ШАДа и читает там курс по генеративному ИИ вместе с сотрудницей группы - Лаборатория теоретической информатики ФКН ВШЭ - завлаб ведёт в ШАДе теорию информации - Научно-учебная лаборатория Яндекса на ФКН ВШЭ - её сотрудники преподают в совместной с ШАДом магистратуре - Лаборатория ИИ Яндекса - руководитель группы ML-разработки ведёт в ШАДе машинное обучение - Лаборатория машинного интеллекта МФТИ и лаборатория МФТИ-Сбербанк - их руководители приложили руку к развитию ШАДа Где на ШАД не смотрят Лабы по железу и системному ПО от YADRO и Huawei. Ни одного преподавателя ШАДа оттуда нет, и в их материалах для студентов ШАД не упоминается. У них свои каналы: лаборатория YADRO в НГУ, программы Huawei при МФТИ, Бауманке и Сколтехе, Excelsior at Huawei в Новосибирске. Туда берут через свой отбор: задачи, профильная база, публикации Хочешь в ШАД, но не знаешь, с чего начать? Наши курсы закрывают всю базу за 3 месяца, а доступ к материалам и мокам остаётся навсегда. Записывайся с гарантией поступления. ➡ Записаться Подписаться: @codeof_art

Инфра - самый недооценённый трек ШАДа Все сейчас спорят, кого первым заменит ИИ. А есть профессия, где с приходом ИИ людей нужно только больше, - инфраструктура: DevOps, SRE, разработка распределённых систем. В посте обсудим, почему так и почему лучший вход туда - направление «Инфраструктура больших данных» в ШАДе. В инфре платят бабки Если ошибся типичный разработчик, на сайте поедет кнопка/не так отработает отработает бэкенд. Если ошибся инфраструктурщик, то встает весь проект, бизнес, иногда масштабы проблемы уходят даже дальше: - 30 января 2024 года при плановой ротации ключей DNSSEC сломалась подпись зоны .ru, и сайты в рунете массово перестали открываться. На восстановление ушло около двух часов, а эксперты назвали самую вероятную причину - кривые руки - 28 июля 2025 года после хакерской атаки легла IT-инфраструктура «Аэрофлота»: за день отменили 54 пары рейсов, пострадали 75 тысяч пассажиров. Только прямой ущерб от отмен эксперты оценили минимум в 260 млн ₽, а с восстановлением инфраструктуры - в несколько миллиардов. Расписание вернули в норму за пару дней, и сделали это не нейросети, а инженеры - особенно остро эти вопросы возникают сейчас, когда ИИ уже активно делает эти ваши кибер атаки Поэтому инфраструктурщикам и платят столько много. По данным hh.ru, в январе 2026 медианная предлагаемая зарплата DevOps была 216 800 ₽ - топ-5 самых высокооплачиваемых вакансий месяца. И это при том, что зарплаты в IT в целом растут медленнее инфляции. Компания экономит на многом, но не на людях, от которых зависит, работает ли она вообще. Почему туда сложно зайти Раз цена ошибки такая, ответственность дают только тем, кто понимает, как система устроена под капотом. Поэтому джунов в инфре почти не берут, и поэтому DevOps-курсы не спасают: они учат инструментам - Kubernetes, Terraform, CI/CD. А на собесе в сильную команду спросят, что происходит с диском при fsync и почему отстала реплика. Как это решает ШАД На ИБД учат ровно тому, что лежит под инструментами: файло

System Design: frontend На собесе во фронтенд Wildberries на архитектурной секции могут попросить спроектировать аналитику для главной страницы, которая выдерживает 500 тысяч запросов в секунду. Звучит как задача для бэкенда с хранилищами и дашбордами, однако интервьюера в первую очередь интересует браузер. Ему важно, как страница собирает клики, скролл и показы карточек и как доставляет всё это на сервер так, чтобы витрина не начала тормозить от собственной аналитики. Первая версия, которую предлагает почти каждый, отправляет отдельный запрос на каждое событие. На небольшом сайте это сойдёт, но на главной маркетплейса у каждого посетителя за визит набираются десятки событий, а посетителей одновременно сотни тысяч. Запросы аналитики начинают делить канал с картинками товаров, на слабом мобильном интернете страница заметно дольше грузится, и в итоге падает конверсия, то есть ровно та метрика, ради которой аналитику и строили. Поэтому до того как рисовать схему, стоит выяснить у интервьюера, насколько быстро данные должны оказаться на сервере и нужен ли там каждый клик. От ответа зависит многое, потому что для оплаты рекламных показов терять события нельзя, а для тепловой карты главной страницы спокойно хватит части сессий. Дальше разговор строится вокруг буфера. События складываются в память вкладки и уходят на сервер одной пачкой, когда их накопилось несколько десятков или прошло несколько секунд. Общие данные вроде id сессии и модели устройства кладутся в пачку один раз, поэтому каждое событие весит совсем немного, а у буфера есть предел, чтобы при недоступном сервере вкладка не съела всю память. Самое интересное начинается, когда пользователь уходит со страницы, потому что последняя пачка содержит как раз то, что аналитикам нужнее всего, момент, в который человек бросил просмотр. Обычный fetch браузер при закрытии вкладки может оборвать, поэтому для последней отправки используют navigator.sendBeacon, который отдаёт запрос браузеру, и тот доставит его уже после