Вопросы на собеседовании: Бэкенд-разработчик

REST, это архитектурный стиль для сетевых API поверх HTTP.

• Без состояния: каждый запрос несёт всю нужную серверу информацию.
• Единый интерфейс: согласованное именование ресурсов и стандартные HTTP-методы.
• Разделение клиента и сервера, кэшируемость и многоуровневость, опционально код по требованию.
• На практике: ресурсы как URL вида /users/42, GET для чтения, POST для создания, без серверного состояния сессии.

PUT полностью заменяет ресурс, PATCH обновляет только его часть.

• PUT: отправляете полное представление, сервер перезаписывает всё существующее.
• PATCH: отправляете только поля, которые нужно изменить.
• Пример: обновление email через PUT требует весь объект пользователя, через PATCH, только поле email.
• PATCH защищает от случайного затирания полей, которые клиент не собирался менять.

Выбирайте коды статуса по смыслу, а не возвращайте 200 на всё.

• 201 Created при успешном создании, обычно с новым ресурсом в теле.
• 404 Not Found для отсутствующего ресурса.
• 400 Bad Request при ошибке валидации, с телом, описывающим что не так.
• 500 Internal Server Error при необработанном сбое на сервере.
• Правильные коды позволяют клиентам обрабатывать ошибки программно, не разбирая текст.

Сервер выдаёт подписанный токен после входа и проверяет его на каждом запросе.

• Токен состоит из трёх частей: заголовок, base64-нагрузка с данными вроде ID пользователя и срока действия, и подпись.
• Клиент передаёт его в заголовке Authorization при последующих запросах.
• Сервер проверяет подпись секретным ключом и доверяет нагрузке без обращения к базе данных.
• Поскольку JWT самодостаточны, они подходят для stateless API.

Аутентификация подтверждает, кто вы, авторизация определяет, что вам разрешено.

• Аутентификация: проверка пароля или валидация токена.
• Авторизация: выдача прав после подтверждения личности.
• Пример: проверка JWT, это аутентификация, проверка роли администратора перед удалением, авторизация.
• Частая ошибка, смешивать их, тогда эндпоинты узнают пользователя, но не проверяют права.

Внешний ключ ссылается на первичный ключ другой таблицы и обеспечивает ссылочную целостность.

• Пример: таблица orders имеет user_id, указывающий на таблицу users.
• Он предотвращает осиротевшие записи, например заказ для несуществующего пользователя.
• СУБД отклоняет вставки или обновления, нарушающие ограничение.
• Это надёжнее, чем проверять правило только в коде приложения.

Индекс, это структура данных, находящая совпадающие строки без полного сканирования таблицы.

• Обычно это B-дерево по одному или нескольким столбцам.
• Добавляйте индекс на столбцы, часто используемые в WHERE, JOIN или ORDER BY.
• Каждый индекс замедляет INSERT, UPDATE и DELETE, потому что его тоже нужно обновлять.
• Поэтому создавайте индексы избирательно, где производительность чтения важнее всего.

N+1 возникает, когда вы загружаете N записей и делаете по одному лишнему запросу на каждую для связанных данных.

• Пример: загрузка 100 постов с запросом автора для каждого даёт 101 запрос.
• Решение, загрузить связанные данные одним джойном или одним пакетным запросом.
• Большинство ORM предлагают жадную загрузку, например include в Sequelize или select_related в Django.
• Это сводит работу к одному-двум запросам.

SQL использует таблицы с фиксированной схемой, NoSQL, гибкие схемы и разные модели данных.

• SQL: таблицы с фиксированной схемой и структурированные запросы для джойнов, агрегаций и транзакций.
• NoSQL: документные хранилища вроде MongoDB, «ключ-значение» вроде Redis, колоночные вроде Cassandra.
• SQL подходит для реляционных данных с жёсткими требованиями к согласованности.
• NoSQL часто жертвует частью гарантий ACID ради горизонтальной масштабируемости или гибкости схемы.
• На уровне junior начинайте с реляционной базы, если нет явной причины поступить иначе.

Middleware, это функция в цепочке запроса-ответа, выполняемая до или после обработчика маршрута.

• Она может читать или менять запрос, вызывать следующий middleware или прервать цепочку, отправив ответ.
• Частые сценарии: парсинг JSON-тела, проверка токенов, логирование запросов, обработка CORS.
• В Express она принимает (req, res, next) и должна вызвать next() для продолжения цепочки.

Процесс, это независимая программа со своей памятью, поток разделяет память внутри процесса.

• У процесса своё адресное пространство памяти, управляемое ОС.
• Поток, это более мелкая единица выполнения, разделяющая память с другими потоками того же процесса.
• Потоки легко обмениваются данными через общие переменные, но могут повредить общее состояние без синхронизации.
• Node.js работает на одном потоке, но может порождать рабочие потоки или дочерние процессы для CPU-интенсивных задач.

Асинхронное программирование позволяет запустить операцию, продолжить работу и обработать результат позже без блокировки.

• Синхронная блокирующая модель останавливала бы сервер в ожидании каждого запроса к базе данных.
• Асинхронный I/O позволяет одному потоку обслуживать много запросов, уступая управление во время ожидания сети или диска.
• В Node.js это модель по умолчанию; в Python используется asyncio.

HTTPS, это HTTP поверх TLS: трафик шифруется, а личность сервера проверяется.

• При подключении клиент и сервер выполняют TLS-рукопожатие.
• Сервер предъявляет сертификат, клиент проверяет его через доверенный центр сертификации.
• Они согласовывают симметричный ключ, и все последующие данные шифруются им.
• Это блокирует прослушивание и самозванцев; бэкенд-разработчики настраивают сертификаты через Let's Encrypt или облачный балансировщик.

CORS, это механизм безопасности браузера, управляющий кросс-доменными запросами из JavaScript.

• Он ограничивает JS на одном источнике (домен и порт) от вызова другого источника.
• Браузер отправляет заголовок Origin, а сервер отвечает Access-Control-Allow-Origin с разрешёнными источниками.
• Без него вредоносный сайт мог бы делать аутентифицированные запросы через cookies посетителя.
• Настраивается на бэкенде; небраузерные клиенты вроде Postman его игнорируют.

Кэширование сохраняет результат дорогой операции, чтобы последующие запросы пропускали работу.

• Cache-aside: приложение сначала проверяет кэш, при промахе читает базу данных и записывает результат обратно в кэш.
• Write-through: каждая запись идёт сразу и в кэш, и в базу данных, сохраняя синхронизацию.
• Cache-aside, самый частый паттерн, он хорошо сочетается с Redis для результатов запросов или готовых ответов.

Redis, это хранилище «ключ-значение» в памяти с богатыми типами данных, используемое в основном ради скорости.

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

Миграция, это версионированное изменение схемы базы данных в виде кода, хранящееся в репозитории.

• Примеры: добавление столбца или создание таблицы, записанные как код.
• Инструменты вроде Flyway, Liquibase или Alembic применяют их по порядку и отслеживают выполненные.
• Это делает изменения схемы воспроизводимыми, доступными для ревью и привязанными к коммиту.
• Без миграций ручные изменения трудно воспроизвести в staging, тестовом и production-окружениях.

Транзакция объединяет SQL-операции в один блок, который либо весь фиксируется, либо весь откатывается.

• Используйте её, когда несколько таблиц должны меняться атомарно, например списание с одного счёта и зачисление на другой.
• Начните с BEGIN, выполните запросы, затем COMMIT при успехе или ROLLBACK при сбое.
• Большинство ORM оборачивают логику в try-catch и откатывают изменения при любом исключении.

Операция идемпотентна, если её многократный вызов даёт тот же результат, что и однократный.

• GET, PUT и DELETE идемпотентны по природе; POST по умолчанию нет.
• Это важно, потому что сетевые сбои заставляют клиентов повторять запросы, что грозит двойным списанием или дублями.
• Сделать POST идемпотентным помогает сгенерированный клиентом ключ идемпотентности.
• Перед выполнением операции проверяйте, был ли этот ключ уже обработан.

Тип джойна определяет, какие несовпадающие строки вы сохраняете.

• INNER JOIN возвращает только строки с совпадениями в обеих таблицах.
• LEFT JOIN возвращает все левые строки плюс совпадения справа; при отсутствии совпадения столбцы будут null.
• RIGHT JOIN, зеркало: все правые строки независимо от совпадения слева.
• LEFT JOIN используется чаще всего, например все пользователи, включая тех, у кого пока нет заказов.