Art of Code

Инфра - самый недооценённый трек ШАДа

Все сейчас спорят, кого первым заменит ИИ. А есть профессия, где с приходом ИИ людей нужно только больше, - инфраструктура: 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 и почему отстала реплика.

Как это решает ШАД
На ИБД учат ровно тому, что лежит под инструментами: файловые системы, диски, сети, процессы, распределённые системы. Инструменты потом подтягиваются за пару месяцев, а понимание систем набирается годами, и платят именно за него.

И учат этому люди, которые сами держат инфру Яндекса и учат на реальных проектах: руководитель ИБД возглавляет в Яндексе отдел технологий распределённых вычислений, надёжность распределённых систем ведёт лид динамических таблиц YTsaurus, алгоритмы - контрибьютор PostgreSQL. То есть два года тебя видят те, кто потом нанимает в эти команды. Плюс формальная льгота: если закрыл в ШАДе алгоритмы на «хорошо» или «отлично», алгоритмической секции на собесе в Яндекс нет.

Конечно Яндекс не всегда привлекателен для специалистов старших грейдов из-за "среза грейда" на собесах, но для начинающих специалистов — это отличный вариант для старта в айти, где ты растешь и развиваешься в кругу сильных специалистов с возможность заниматься непростыми проектами с современным стеком. Особенно Яндекс становится интересен инфраструктурщикам на фоне новостей об объединении с ВК для создания конторы по производству ИИ-агентов для бизнесов.

Короче, ШАД - твоя инвестиция в будущее, понял? Даже если не получится поступить, ты заботаешь алгоримты и математику — фундамент, который затем пригодиться для карьеры и продолжения образования, если захочешь поступать в магу. А с нашими курсами у тебя вообще действует гарантия поступления: если не поступишь, возвращаем деньги. Записывайся с гарантией поступления.
➡ Записаться

Подписаться: @codeof_art

ШАД и Лаборатории

ШАД — это не просто диплом и не просто строчка в резюме. Это еще и доступ к специалистам, которые делают науку и индустрию. Но работают они в разных местах, и далеко не везде ШАД одинаково ценят. Где-то он открывает двери, а где-то на него вообще не смотрят. Мы собрали два списка, чтобы ты понимал, куда идти, если хочешь использовать ШАД как трамплин, а куда — если у тебя другие цели.

Где ШАД в плюс
- Лаборатория компьютерной графики и мультимедиа ВМК МГУ - её заведующий ведёт в ШАДе компьютерное зрение
- AIRI - в ШАДе преподают руководители групп «Пространственный интеллект» и FusionBrain.Robotics, а также старший научный сотрудник института
- Группа генеративного ИИ Сколтеха - её руководитель сам выпускник ШАДа и читает там курс по генеративному ИИ вместе с сотрудницей группы
- Лаборатория теоретической информатики ФКН ВШЭ - завлаб ведёт в ШАДе теорию информации
- Научно-учебная лаборатория Яндекса на ФКН ВШЭ - её сотрудники преподают в совместной с ШАДом магистратуре
- Лаборатория ИИ Яндекса - руководитель группы ML-разработки ведёт в ШАДе машинное обучение
- Лаборатория машинного интеллекта МФТИ и лаборатория МФТИ-Сбербанк - их руководители приложили руку к развитию ШАДа

Где на ШАД не смотрят
Лабы по железу и системному ПО от YADRO и Huawei. Ни одного преподавателя ШАДа оттуда нет, и в их материалах для студентов ШАД не упоминается. У них свои каналы: лаборатория YADRO в НГУ, программы Huawei при МФТИ, Бауманке и Сколтехе, Excelsior at Huawei в Новосибирске. Туда берут через свой отбор: задачи, профильная база, публикации

Хочешь в ШАД, но не знаешь, с чего начать? Наши курсы закрывают всю базу за 3 месяца, а доступ к материалам и мокам остаётся навсегда. Записывайся с гарантией поступления.
➡ Записаться

Подписаться: @codeof_art

System Design: backend

Эту задачу дают на бэковых собесах в Ozon, и звучит она затрагивает максимально типичную задачу. Есть сервис, который принимает оплату заказа. Когда платёж прошёл, складу нужно узнать, что заказ оплачен и его можно собирать, поэтому сервис отправляет событие в Kafka. Интервьюер описывает ситуацию, в которой платёж уже записан в базу, а Kafka именно в эту секунду недоступна, и просит рассказать, что будет с заказом и как сделать так, чтобы ничего не потерялось. Большинство кандидатов в этот момент рисуют ровно тот код, который потом и разбирают на части.

Выглядит он так: сначала коммитим платёж в базу, потом отправляем событие в брокер. Проблема в том, что это две операции в двух разных системах, и между ними может случиться что угодно. Процесс упадёт после коммита или сеть пропадёт на полсекунды, и в итоге деньги у клиента списаны, а склад про заказ так и не узнал. Если поменять порядок и сначала отправить событие, получится зеркальная беда, потому что транзакция в базе может откатиться уже после того, как склад начал собирать заказ, за который никто не заплатил. Хороший кандидат на этом месте останавливается и спрашивает интервьюера, что для бизнеса хуже, потерять событие или получить его два раза. Ответ почти всегда одинаковый. Потерянный заказ обходится дороже, потому что о нём никто не узнает, пока клиент не придёт ругаться в поддержку, а лишнюю копию события получатель может просто отбросить. Раз так, задача сводится к тому, чтобы гарантировать доставку хотя бы один раз и научить получателя спокойно относиться к повторам.

Для этого используют приём, который называется Transactional Outbox. В той же базе, где лежат платежи, заводится отдельная таблица для исходящих событий, и строка в неё пишется в той же транзакции, что и сам платёж. База умеет гарантировать атомарность внутри себя, поэтому после коммита у нас либо есть и платёж, и событие о нём, либо нет ни того, ни другого. В Kafka эти строки перекладывает отдельный процесс, его обычно называют реле. Он берёт из таблицы то, что ещё не отправлено, публикует в брокер и только после подтверждения помечает строку как отправленную. Если реле упадёт между публикацией и пометкой, после перезапуска оно отправит те же строки повторно, и здесь становится понятно, зачем вопрос про дубли задавали в самом начале. Когда экземпляров реле несколько, строки удобно разбирать через SELECT FOR UPDATE SKIP LOCKED, чтобы два процесса не схватили одну запись, а ключом сообщения лучше делать id заказа, тогда все события одного заказа попадут в одну партицию и склад получит их в правильном порядке.

Раз повторы стали нормальной частью системы, получатель обязан с ними справляться. Склад хранит идентификаторы уже обработанных событий и просто пропускает те, что видел раньше. Если про это забыть, Outbox решит проблему у отправителя и тут же создаст новую у склада, где один и тот же заказ начнут собирать дважды. Обычно после этого интервьюер переходит к эксплуатации. Опрашивать таблицу раз в секунду можно, но это нагружает базу и добавляет задержку, поэтому в больших системах изменения часто читают прямо из журнала транзакций с помощью CDC вроде Debezium. Отправленные строки со временем нужно чистить, иначе таблица событий разрастётся быстрее самих платежей. Для мониторинга хватает одной метрики, возраста самой старой неотправленной строки. Если он начал расти, значит реле встало или брокер лежит, и лучше узнать об этом от алерта, чем от склада.

По сути интервьюер проверяет, замечаешь ли ты, что запись в базу и отправка в брокер по умолчанию никак не связаны между собой, и можешь ли собрать схему, в которой событие гарантированно доедет, а его повтор никому не навредит.

Подписаться: @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

Новый пост из серии про паттерны на реальном коде. Разбираем штуку, с которой рано или поздно встречается любой сервис, живущий в интернете: в него начинают лить больше, чем он способен переварить.

Ситуация простая. У тебя есть сервис, который что-то принимает извне — запросы, события, сообщения. И в какой-то момент поток на входе становится больше, чем ты успеваешь обрабатывать. Причины разные: у клиента выкатили баг, и он спамит одним и тем же по кругу; резкий наплыв пользователей; банальный 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

Полный цикл собесов в Яндекс (Бэкенд 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

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

Обязательно делитесь с ребятами, которым это может быть интересно.

System Design: backend

Сегодня разберём задачу, которую мне давали на собесе в Яндекс. Штука на стыке проектирования и алгоритмов: мало накидать красивую схему на доске — надо ещё нормально объяснить, как данные поедут через систему. И вот тут сразу видно, шаришь ты или просто заучил модные слова.

Условие такое. Надо забэкапить данные — до терабайта. При сжатии они ужмутся где-то в полтора-три раза. Хранилище, куда мы всё складываем, принимает файлы не больше 100 мегабайт за раз. Нужно собрать конвейер: прочитать данные, сжать, записать. И главный подвох, вокруг которого вся задача: целиком в память это не влезет.

Первое, что приходит в голову, — «читаем файл, жмём, отправляем». И это ловушка. Терабайт в оперативку просто не поместится, так что про «прочитать файл целиком» надо забыть сразу. Задача с самого начала не про файл, а про поток: данные текут через тебя, ты хватаешь их по кусочку, обрабатываешь и отпускаешь — и никогда не держишь всё разом.

Но прежде чем что-то проектировать, я бы задал интервьюеру один вопрос. Как по мне, ради него задачу и придумали. Что делать, если данные сожмутся хуже обещанного, и очередной сжатый кусок всё равно вылезет за 100 мегабайт? Полтора-три раза — это как средняя температура по больнице, а не гарантия. Попадётся кусок, который жмётся плохо (уже сжатое видео, случайный мусор), — и он не влезет в лимит. Если ты сам спотыкаешься об этот момент, до того как тебя носом ткнули, — считай, полдела сделал: дальше этот вопрос всё равно вылезет. Заодно спроси, нужна ли параллельность и надо ли уметь продолжить с места обрыва, если всё грохнется на середине.

Теперь как оно работает внутри. Читаем данные небольшими порциями, каждую жмём и отправляем в хранилище куском не больше лимита. Получается конвейер из трёх шагов: читаем, жмём, отправляем. И логично, чтобы шаги крутились не по очереди, а разом — пока один кусок улетает в хранилище, следующий уже читается, а средний в это время жмётся. Само сжатие — самое прожорливое место, так что его можно раскидать на несколько потоков и жать куски параллельно.

И вот тут вылезает тонкость, которую многие упускают. Читать почти всегда быстрее, чем отправлять по сети. Если читать на полной скорости, а отправка не поспевает, то непрожатые куски начнут копиться в памяти — и привет, мы вернулись ровно к той беде, от которой бежали: память забита под завязку. Поэтому между шагами ставим очередь ограниченного размера. Забилась — чтение притормаживает и ждёт, пока отправка разгребёт накопленное. По сути система сама себя придушивает под нагрузкой и не даёт быстрой части захлебнуть медленную.

Вернёмся к главному вопросу — про плохое сжатие. Ответ «ну возьмём кусок поменьше» не катит: это отмашка, а не решение. По-нормальному — не фиксить размер куска намертво, а подстраивать. Не влез после сжатия — уменьшаем входную порцию и пробуем ещё раз. Или наоборот: сразу берём порцию с запасом, с расчётом на самый паршивый случай, чтобы результат влез при любом раскладе. Оба варианта живые, суть в том, что ты вообще про это подумал, а не понадеялся, что «да обычно нормально жмётся».

И ещё пара штук, которые отличают продуманное решение от учебного. Первая — контрольная сумма на каждый кусок. Иначе бэкап может тихо побиться, а узнаешь ты об этом в самый неподходящий момент — когда полез восстанавливаться, а там каша. Вторая — уметь продолжить с последнего нормально записанного куска, а не гнать терабайт по новой из-за обрыва на 90%. Для этого достаточно отмечать, что уже доехало.

Если коротко: тут смотрят, думаешь ли ты про неудобные случаи заранее, и дошло ли до тебя, что «не влезает в память» — это про потоковую обработку, а не про поиск хитрого способа всё равно запихнуть всё целиком. Разложил историю с плохим сжатием на конкретное решение — задача твоя.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

System Design: frontend

Сегодня разберём задачу с собеса в геодезическую компанию — из тех, где приложение для полевых работ должно работать там, где связи нет в принципе. Спроектируй фронт, который живёт без интернета: специалист видит данные, что-то в них меняет, а когда сеть возвращается — всё уезжает на сервер и синхронизируется.

Почему такое вообще спрашивают. Геодезист выезжает на объект — поле, стройка, лес за городом, — и связи там может не быть весь день. А работать надо: открыть карту участка, занести замеры, отметить точки, что-то поправить. Если приложение при потере сети показывает белый экран, им попросту нельзя пользоваться в поле. Значит, оно должно работать так, будто интернет и не нужен, а сеть подхватывать само, когда специалист вернётся в зону покрытия.

Первое, что хочется ляпнуть, — «закешируем данные и всё». И вот это ловушка. Как только ты разрешаешь не только читать офлайн, но и менять данные, ты, по сути, строишь маленькую распределённую систему: у тебя появляется две копии правды (на устройстве и на сервере), и они умеют разъезжаться. Все классические боли распределёнки — конфликты, рассинхрон, порядок операций — теперь твои. Не подумал про них — решение развалится на первом же реальном сценарии.

Поэтому до того как проектировать, спроси интервьюера две вещи. Первая: что именно должно пахать офлайн — только чтение или запись тоже? Это небо и земля по сложности. Чисто чтение — задачка на кэш. Запись — уже та самая распределёнка. Вторая, и это гвоздь всей задачи: что делать, если геодезист поменял данные офлайн, а на сервере их за это время тоже кто-то поменял — например, коллега в офисе? Пока ты не ответил, как разруливать такой конфликт, — задача не закрыта.

Теперь как устроено внутри. Данные храним прямо на устройстве. Для структурированных данных — IndexedDB (это встроенная в браузер база; localStorage не годится — он крохотный и синхронный, тормозит всё вокруг). Картинки, стили, саму оболочку приложения кладём через Service Worker — это прослойка между приложением и сетью, которая отдаёт сохранённое, когда интернета нет. Читаем офлайн — берём из локальной базы. А с записью интереснее: когда человек что-то меняет без сети, мы не пытаемся тут же достучаться до сервера, а складываем изменение в локальную очередь. Появилась сеть — по очереди, в том же порядке, отправляем всё накопленное.

И вот мы уперлись в главное — в конфликты. Тут надо не просто сказать «ну разрулим», а назвать конкретный подход и объяснить, почему он. Самый простой — кто последний записал, того и правда. Работает, но молча затирает чужие изменения, а для замеров по объекту это чревато: перезатёр чью-то правку — и на объект поедут неверные координаты. Честнее — версии: у каждой записи есть номер версии, и если геодезист пытается сохранить поверх данных, которые на сервере уже обновились, сервер такое отклоняет, и мы решаем, что делать. Самый аккуратный, но и самый муторный вариант — сливать изменения по отдельным полям: один поправил координаты точки, другой — её описание, оба изменения выживают. Важно не назвать «правильный» ответ (его нет), а показать, что ты понимаешь разницу и осознанно выбираешь под ситуацию.

Ещё пара вещей, без которых разбор неполный. Синхронизацию лучше делать в фоне — есть Background Sync, который сам достучится до сервера, когда связь вернётся, даже если вкладку уже закрыли. И обязательно — честно показывать статус. Если человек поменял что-то офлайн, а на экране всё выглядит как «сохранено», он уйдёт довольный, а изменения висят в очереди и могут вообще не уехать. Маленькая плашка «изменения ещё не отправлены» снимает кучу боли.

Если совсем коротко: тут проверяют, понял ли ты, что offline-first — это не «кэш прикрутить», а полноценная распределёнка со своими конфликтами и с тем, что данные какое-то время живут несогласованными. Назвал конкретную стратегию разрешения конфликтов и вспомнил про честный статус для пользователя — значит, в теме.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

Второй пост серии про паттерны на реальном коде. В прошлый раз говорили, почему «сохранилось» и «точно сохранилось» — не одно и то же. Сегодня — про идею, на которой держится половина софта вокруг нас, хотя мало кто задумывается про нее.

Если тебе приходится запускать чужой код, которому ты не доверяешь, — держи его от себя подальше, в отдельном процессе. Причина простая: чужой код умеет падать, зависать намертво и течь по памяти. Пусти его внутрь своего приложения — и однажды он утащит тебя за собой на дно. А отдельный процесс работает как стена: за ней хоть потоп, а на твою сторону вода не дойдёт. Поэтому одна упавшая вкладка в браузере не роняет остальные, и поэтому же плагины в редакторах живут отдельно от самого редактора.

Посмотрим, как это сделано в VS Code — там всё честно и наглядно. Расширения крутятся не внутри редактора, а в собственном процессе, у него и название есть — extension host. Замысел в одну строчку: что бы ни стряслось с расширениями, редактор обязан устоять.

И он выдерживает. Процесс с расширениями рухнул целиком — а редактор даже бровью не повёл: курсор мигает, текст на месте, файл спокойно сохраняется. Разработчики так и ставили задачу — пусть расширения хоть все разом отвалятся, но ни строчки твоей работы пропасть при этом не должно. Когда процесс падает, сверху выезжает плашка «расширения отключились, перезапустить?», жмёшь — и он поднимается заново. На то он и отдельный, что пересоздать его можно, ничего вокруг не задев.

А теперь то, из-за чего у людей годами пригорает. Стена стоит между редактором и расширениями — но между самими расширениями никакой стены нет. Все они набиты в один общий процесс и делят на всех единственный поток выполнения. А в JavaScript поток ровно один. И получается некрасивое: стоит одному расширению уйти в тяжёлые вычисления и занять поток надолго — как замирают вообще все расширения сразу. Не только виновник, а все соседи по процессу. Человек видит, что редактор целиком отупел и не реагирует, ругает VS Code последними словами — а нашкодило одно расширение, просто остальные заперты с ним в одной комнате.

Показательно, что и сама команда эту штуку архитектурно не победила — пошла в обход. VS Code теперь приглядывает за процессом с расширениями, и если тот перестал отвечать, тихонько включает профайлер: выясняет, кто съел весь поток, находит виновника и предлагает написать его автору. Проблему не убрали — её хотя бы вытащили на свет.

Тут есть тонкость, которую легко проскочить. Отдельный процесс спасает ровно от одного: сломанное расширение не утянет за собой редактор. Но заставить расширения не мешать друг другу он не может — это не входит в его задачу. Чтобы одно зависшее расширение не морозило соседей, пришлось бы городить следующий этаж защиты: свой процесс под каждое, тяжёлые задачи в фоновые потоки, лимиты по времени. И всё это не бесплатно — лишняя память, возня с общением между частями, более медленный запуск. В VS Code прикинули цену и решили, что оно того не стоит: одна общая крыша над всеми расширениями — осознанный размен между надёжностью и расходами.

Чему тут стоит научиться, даже если ты никогда не будешь писать редактор кода. Когда проектируешь что-то, что запускает не свой код — плагины, пользовательские скрипты, обработчики от сторонних команд, — заранее спроси себя: от чего именно я тут защищаюсь. «Чтобы чужое не уронило моё» и «чтобы одно чужое не мешало другому чужому» — две разные задачи, и вторая решается дороже. Их легко перепутать и поставить границу не там: думаешь, что защитился, а закрыл только половину. И второе: если задачу нельзя решить чисто — не грех сделать её хотя бы заметной. VS Code не смог развести расширения по-настоящему, но научился показывать пальцем на виновника, и это уже куда лучше, чем молча тормозить. Иногда честная диагностика ценнее красивого, но недостижимого решения.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

Как стать миддлом

По стеку джуна и мидла сегодня спрашивают почти одно и то же. Открой любые вакансии - знание своего ЯП/фреймворка, SQL, Docker, Kafka/Redis, везде одно и то же. Так за что мидлу платят вдвое больше? Разбираемся на актуальных вакансиях Т-Банка и Ozon.

Джуну дают задачу. Мидлу — проблему
Джуну пишут конкретно, например, написать API под новый микросервис для техподдержки. Задача с границами: понятно, что на входе, что на выходе, когда готово. Бери и делай.

Мидлу пишут абстрактные вещи, для примера, рефакторить интеграционные решения и обеспечивать стабильность работы сервисов. Границ нет, не особо понятно, а какой конечный результат вообще и с чего начать-то. Тебе дают проблему, а задачу из неё ты достаёшь сам. И отвечаешь за результат, если твои микросервисы упадут в разгар рабочего дня и заказчик потеряет деньги, тут уже другой уровень отвественности по сравнению с джуном.

Вот и вся граница: джуна берут за умение закрывать задачи, мидла — за умение отвечать за систему. Всё остальное — следствие.

Стек тот же — уровень владения разный
В вакансиях джуна и мидла — одни и те же технологии. Разница в том, что от тебя с ними ждут.

Джуну: «знать Python», «понимать архитектуру ETL». Знать и понимать.

Мидлу: «проектировать микросервисы», «оптимизировать запросы», «самому работать с Docker». Не слышал про Kubernetes, а крутил руками.

Что конкретно учить, чтобы стать мидлом
«Бери больше ответственности и качай харды» - совет ни о чём. Ниже дам несколько конкертных советов, они не зависят от языка - работают хоть на Go, хоть на Python, хоть на Java.

System design. Главный навык мидла. Спроектировать сервис с нуля: где узкое место, что реплицировать, где кэш, что будет под нагрузкой в 10 раз больше. Это спрашивают почти на каждом собесе на мидла — и именно тут валятся вчерашние джуны.

Базы на уровне оптимизации. Не «умею писать SELECT», а читать план запроса, ставить индексы, понимать, почему запрос тупит на проде под реальными данными.

Docker и Kubernetes. Не теория — собрать образ, написать манифест, задеплоить, разобраться, почему под падает и рестартится в цикле.

Событийная архитектура. Kafka, очереди, как сервисы общаются асинхронно и что происходит с системой, когда один из них отваливается.

CI/CD. Как код доезжает до прода и как сделать так, чтобы релиз не положил систему.

Освоишь эти пять — и на собесе тебе будет что показать. Не строчку в резюме, а умение собрать работающую систему.

Коротко
Джун сидит в своей зоне и пишет задачи внутри неё. Мидл смотрит на проект целиком: как деплоится, как сервисы общаются, что упадёт под нагрузкой, почему вчерашний релиз положил прод. Архитектура для него — не то, что понимаешь, а то, что строишь.

За это и платят: по медиане backend-вакансий 2026 года джун получает около 135 тысяч, мидл — порядка 225. Почти вдвое.

Хочешь дорасти до мидла — не гонись за очередным фреймворком. Учись проектировать системы и отвечать за них. Ровно этому мы учим на нашем курсе бэкенд про.
➡️ Записаться.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art