Backend-разработчик: что общего в профессии независимо от языка

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

Данные появляются раньше кода

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

Здесь у новичков возникает характерная ошибка: миграция кажется безобидной, потому что «мы только добавляем столбец». В PostgreSQL команда ALTER TABLE по умолчанию берёт блокировку уровня ACCESS EXCLUSIVE, при которой к таблице не может обратиться никто, — документация оговаривает это прямо. Столбец с постоянным значением по умолчанию добавляется быстро даже на большой таблице: значение записывается в метаданные и подставляется при чтении старых строк. Если же значение вычисляется каждый раз, как clock_timestamp(), переписывается вся таблица вместе с индексами. Разница между двумя вариантами одной миграции — это разница между незаметным обновлением и получасовым простоем магазина.

Контракт: API как письменное обещание

Данными пользуется не сам бэкендер, а мобильное приложение, веб-интерфейс, соседний сервис, партнёрская интеграция. Договорённость о том, по каким адресам, в каком формате и по каким правилам они общаются, называется контрактом API, и задают её машиночитаемо. Этим занимается OpenAPI: спецификация определяет «стандартный, не зависящий от языка интерфейс к HTTP-API», который позволяет и человеку, и программе понять возможности сервиса без доступа к исходному коду — формулировка из текста версии 3.2.1 от 10 сентября 2026 года.

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

Один и тот же запрос дважды

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

В разделе 9.2.2 RFC 9110 метод назван идемпотентным, если предполагаемый эффект на сервере от нескольких одинаковых запросов такой же, как от одного. Идемпотентны PUT, DELETE и безопасные методы — GET, HEAD, OPTIONS, TRACE. И там же сказано, чего нельзя: неидемпотентные методы вроде POST клиент не может повторить автоматически, если не знает, был ли запрос применён. Между тем почти всё, что создаёт деньги и обязательства, — это POST.

Отсюда приём, о котором в обзорах профессии почти не пишут, хотя в платёжных API он давно стандарт. Рабочая группа HTTPAPI в IETF описывает заголовок Idempotency-Key: черновик спецификации называет его средством сделать POST и PATCH устойчивыми к сбоям. Клиент придумывает ключ, сервер запоминает его вместе с результатом, дальше поведение расписано по случаям. Тот же ключ с тем же телом — сервер возвращает результат уже выполненной операции, не выполняя её заново. Запрос с этим ключом ещё обрабатывается — ответ 409. Ключ переиспользовали с другим телом — 422: применять один ключ к разным полезным нагрузкам нельзя.

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

Согласованность: транзакции и то, что между ними

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

У строгих уровней своя цена, описанная явно: приложения на Repeatable Read и Serializable должны быть готовы повторять транзакции из-за сбоев сериализации. База откатывает транзакцию с ошибкой вроде could not serialize access due to concurrent update, и начинать её приходится заново; в документации рекомендуется предусмотреть общий механизм обработки таких сбоев — они всегда возвращают код 40001. Значит, часть кода пишется с расчётом на повторное выполнение, и согласованность смыкается с идемпотентностью.

Учебный пример: бонусы после оплаты

Ситуация вымышленная и нужна, чтобы показать ход работы. Онлайн-школа начисляет бонусные баллы за оплаченный курс, а платёжный сервис после списания отправляет уведомление и повторяет отправку, пока не получит ответ с кодом 200.

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

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

Когда приходит нагрузка

Под реальным трафиком сервис ломается не сразу, а по цепочке. Глава о каскадных отказах в книге Google о надёжности сервисов называет самой частой их причиной перегрузку, и пример там арифметический: два кластера держат по 1000 запросов в секунду, один выходит из строя, второй получает 1200 запросов, исчерпывает ресурсы и начинает падать — в итоге успешно обрабатывается меньше тысячи, то есть меньше, чем он тянул до аварии.

Усугубляют картину повторы: 100 повторных запросов в секунду превращаются в 200, затем в 300. А если повторы настроены на нескольких уровнях сразу — в браузере, во внешнем сервисе и во внутреннем, — они перемножаются: три уровня по три повтора дают до 64 обращений к базе (4³) на одно действие пользователя. Отсюда совет ограничивать число повторов и добавлять экспоненциальную задержку со случайной составляющей.

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

Где проходят границы с соседями

Обязанности пересекаются, но зоны ответственности различаются. Фронтендер отвечает за интерфейс, инженер DevOps или SRE — за среду, где сервис собирается и выкладывается, инженер данных — за хранение данных для аналитики, архитектор — за разбиение системы на части. Бэкендеру остаются сами данные, правила их изменения, контракт и устойчивость сервиса: на соседние территории он заходит, но не живёт на них.

Язык как следствие задачи

В разборе Хабр Карьеры по специализациям за первое полугодие 2026 года к самым востребованным языкам бэкенда отнесены Python, Java, Go и PHP (публикация от 28 августа 2026 года); к ним стоит добавить C# и серверный JavaScript.

Выбор определяется задачей и рынком. Java и C# преобладают в корпоративных системах и банках, где ценятся строгая типизация и зрелые фреймворки. Python держится на веб-сервисах и на всём, что соседствует с аналитикой, Go берут для сетевых сервисов с предсказуемым потреблением памяти, а PHP остаётся языком огромного числа существующих сайтов, и поддержка этого наследия — отдельный оплачиваемый пласт работы. Node.js даёт один язык на клиенте и на сервере, что сокращает вход для пришедших из фронтенда: такой маршрут разобран в обзоре курса по бэкенд-разработке на Node.js от Яндекс Практикума, где за три месяца проходят Express, Nest.js, PostgreSQL и MongoDB.

Первый язык разумно выбирать по вакансиям в своём городе; второй осваивается быстрее, потому что переносится именно то, о чём эта статья.

Сколько платят

Сопоставимые цифры публикует Хабр Карьера. В исследовании за первое полугодие 2026 года от 21 июля 2026-го разобрано 45 226 зарплат, анонимно указанных специалистами в калькуляторе сервиса, — это заявленные оклады работающих людей, а не вилки из объявлений. Медианы бэкенд-разработчиков приведены по городам: 278 тысяч рублей в Москве, 251 тысяча в Петербурге и 220 тысяч в регионах; за полугодие они выросли на 3 %.

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

Что может оказаться трудным

Результата не видно: фронтендер показывает экран, бэкендер — ответ в формате JSON и объяснение, почему он такой. Тем, кому важно видеть сделанное своими руками, это даётся тяжело.

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

С чего начинать

Порядок освоения почти не зависит от выбранного языка.

1. Один язык до уверенного уровня: типы, функции, работа с ошибками, тестирование.
2. SQL и проектирование таблиц: связи, ключи, индексы, транзакции, план запроса.
3. HTTP и API: методы и коды состояния, аутентификация, описание контракта.
4. Один серверный фреймворк — как каркас, а не как магия.
5. Git, контейнеры, выкладка на сервер, логи и метрики.
6. Очереди, кэш и фоновые задачи — когда базовый сервис уже работает.

Первые три пункта реально пройти по документации самому, и это лучший способ проверить, нравится ли вам такая работа, до того как вы за неё заплатите. Дальше помогает программа с проверкой заданий: серверный код бывает формально рабочим и при этом неверным, а сам себе новичок этого не покажет. В обзоре курса «Бекенд-разработчик на Python» от SF Education соотношение видно в цифрах: 214,4 академического часа за три месяца, из них 120 отведено практике, и два сквозных проекта.

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

Как выбирать обучение и показывать результат

При сравнении программ смотрите не на список технологий, а на устройство практики: доводите ли вы проекты до работающего сервиса, проверяет ли кто-то ваш код, есть ли транзакции, миграции и развёртывание. Длительность сама по себе ничего не обещает: курс «Python ПРО + ИИ: бэкенд и автоматизация» от Компьютерной Академии TOP рассчитан на двенадцать месяцев и включает алгоритмы, базы данных и работу с API, но и годовую программу проверяют теми же вопросами, что трёхмесячную.

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

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