Перейти к основному содержимому
DevScallix

Роудмапы · L3

Senior Backend Developer

Senior backend-разработчик отвечает не только за свою задачу, но и за её влияние на систему. Он решает сложные и неопределённые проблемы, принимает решения о надёжности и изменяемости и помогает расти другим инженерам.

Чем отличается от предыдущего уровня

Middle хорошо работает внутри одного сервиса. Senior учитывает взаимодействие сервисов, сценарии сбоев и долгосрочные последствия. Он не просто решает задачи, а выбирает, какие проблемы стоит решать, и влияет на качество работы других.

Ожидаемые знания

  • Модель сбоев в распределённых системах: таймауты, повторы, backoff, circuit breaker, bulkhead
  • Семантика обмена сообщениями: at-least-once, идемпотентный consumer, transactional outbox
  • Глубина в базах данных: уровни изоляции, блокировки, стратегии миграций
  • Идемпотентность и безопасная обработка повторных запросов
  • JVM: модель памяти, выбор GC, лимиты контейнера, сильные стороны и ограничения virtual threads
  • Observability: логи, метрики, трассы и дизайн алертов по симптомам
  • Границы сервисов, владение данными, выбор между модульным монолитом и микросервисами
  • Безопасность API: авторизация на уровне объектов, rate limiting, управление секретами

Практические навыки

  • Превратить расплывчатое требование в дизайн системы и прямо описать компромиссы
  • Предсказывать и проверять поведение системы под нагрузкой и при сбоях
  • Сужать причину во время инцидента, а затем писать postmortem без поиска виноватых
  • Проводить рискованную миграцию этапами с планом отката
  • Давать аргументированную обратную связь на review кода и дизайна
  • Наставлять junior и middle инженеров конкретной обратной связью

Типичные ошибки

  • Решать любую проблему микросервисом и получать распределённый монолит
  • Считать запись в базу и публикацию сообщения одной атомарной операцией (dual write)
  • Добавлять повторы без backoff и jitter, усиливая сбой
  • Настраивать алерты на каждую мелкую метрику вместо симптомов
  • Принимать все решения лично и не давать команде стать самостоятельной
  • Выбирать технологию раньше, чем понята проблема

Приоритеты обучения

  1. 1Сделать надёжность частью дизайнаС самого начала продумывайте таймауты, политику повторов и поведение при сбое для каждого внешнего вызова.
  2. 2Глубоко знать распределённые данные и обмен сообщениямиOutbox, идемпотентные consumer, порядок и влияние eventual consistency на пользовательский опыт.
  3. 3Системно подходить к system designУточняйте требования, грубо оценивайте, открыто называйте компромиссы и режимы отказа.
  4. 4Observability и операционная культураАлерты по симптомам, runbook и postmortem. Систему нужно уметь понять в три часа ночи.
  5. 5Наставничество и влияниеПоднимать уровень команды через review, обсуждение дизайна и обмен знаниями.

Архитектурная зрелость

На уровне senior архитектурные решения оцениваются по границам, владению данными и атрибутам качества: надёжность, производительность, безопасность, изменяемость. Инженер сравнивает альтернативы, прямо называет цену каждого решения и предусматривает путь назад. Принципы вроде clean architecture или DDD он применяет там, где они решают конкретную проблему, а не ради церемонии.

Примеры вопросов

  • Как обеспечить согласованность записи в базу и сообщения в Kafka?
  • Как возникает шторм повторов и как его предотвратить?
  • Что происходит, когда consumer получает одно сообщение дважды, и как к этому подготовиться?
  • Как защитить остальную систему, когда сторонний API замедлился?
  • Когда вы обоснуете микросервисы вместо модульного монолита?
  • С чего начнёте, если выросли паузы GC?
  • Спроектируйте сервис сокращения ссылок и объясните компромиссы.

Упражнения для самостоятельной работы

  • Публикуйте событие «заказ создан» через transactional outbox и relay; остановите relay и проверьте повторную обработку.
  • Добавьте circuit breaker и bulkhead к внешнему сервису, смоделируйте сбой и измерьте поведение.
  • Добавьте idempotency key в платёжный endpoint и протестируйте одинаковые параллельные запросы.
  • Напишите ADR о выделении одного модуля существующего монолита по его границам.
  • По метрикам и логам реального сервиса определите три алерта по симптомам и runbook.

Статьи для этого уровня

Подходящие программы

Насколько вы близки к этому уровню?

Оценка навыков формирует личный отчёт о пробелах на основе ваших ответов. Это рекомендация, а не сертификат.