Чеклист лучших практик для разработки backend-приложений

Удобный и структурированный чеклист для всех, кто разрабатывает backend: от настройки проекта и API-дизайна до тестирования, логирования и деплоя. Можно буквально пройтись по пунктам и улучшить свой текущий сервис

Полезно для pet-проектов и подготовки к собеседованиям 🎁

👉 @BackendPortal

😊

👉 @BackendPortal

Git: шпаргалка для новичков

Working Directory: Рабочая директория, здесь вы редактируете файлы проекта

Команда:

git add - добавить изменения в индекс

Staging (Index) подготовительная область: Содержит изменения, которые будут добавлены в следующий коммит

Команда:

git commit - зафиксировать изменения в локальном репозитории

Local Repository локальный репозиторий: Хранит историю всех коммитов на вашем компьютере

Команды:

git push - отправить коммиты в удалённый репозиторий
git fetch - получить новые коммиты с удалённого репозитория без слияния
git pull - получить и объединить изменения из удалённого репозитория

Stash временное хранилище изменений: Используется, когда изменения нужно временно убрать, но не коммитить

Команды:

git stash - сохранить незавершённые изменения
git stash - apply применить изменения из stash, не удаляя их
git stash pop - применить и удалить сохранённые изменения

Remote Repository удалённый репозиторий: Общий сервер проекта GitHub, GitLab, Bitbucket

👉 @BackendPortal

Backend Checklist — День 1: DNS Resolution

Все описывают DNS как «преобразование доменного имени в IP-адрес». Это действительно так, но такое объяснение скрывает часть, которая на практике и вызывает проблемы:

DNS — это не один lookup, а цепочка кешей, и обновляются они не одновременно.

Как работает lookup: ваше устройство не знает IP-адрес, стоящий за доменным именем, поэтому запрос проходит по цепочке, пока не доберётся до сервера, у которого есть нужный ответ:

• Устройство обращается к resolver
• Resolver обращается к root servers, которые указывают на серверы зоны .com
• Серверы .com указывают на серверы, отвечающие за конкретный домен
• Последний сервер содержит нужный ответ, который затем возвращается обратно на устройство

Где появляется кеширование: на обратном пути ответ кешируется, причём каждый кеш хранит его в течение своего времени. Кеширование происходит не на каждом уровне, но обычно задействованы:

• Браузер и OS
• Локальный DNS forwarder, например домашний роутер
• Recursive resolver, используемый вашей сетью

У каждого из них есть свой TTL (Time to Live), который отсчитывается независимо.

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

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

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

👉 @BackendPortal

Backend Checklist — День 2: TCP Handshake

Все могут повторить: SYN, SYN-ACK, ACK. Три пакета, соединение установлено, идём дальше. Но часто упускается главное — для чего на самом деле нужны эти три пакета.

Это не просто «приветствие». Обе стороны выбирают начальный sequence number, сообщают его друг другу, а затем каждая сторона должна подтвердить, что получила sequence number другой стороны.

• Client отправляет SYN со своим начальным sequence number
• Server отвечает SYN-ACK: отправляет свой начальный sequence number и подтверждает получение номера клиента
• Client отправляет ACK, подтверждая sequence number сервера

Три пакета — это минимум, необходимый обеим сторонам для синхронизации sequence numbers и подтверждения надёжности соединения. Именно поэтому пакетов три, а не два.

Где появляются дополнительные затраты: При обычном TCP handshake ни один из этих пакетов не содержит данные вашего приложения. HTTP request отправляется только после завершения handshake.

Если round trip составляет 200 мс, то 200 мс уже будут потрачены только на установление соединения — ещё до того, как сервер получит HTTP request. Затем TLS добавляет сверху свои round trips.

Именно поэтому существуют keep-alive, HTTP persistent connections и connection pooling. Основные затраты связаны не с созданием самого socket, а с необходимостью совершить ещё один round trip через сеть.

Повторное использование уже установленного соединения позволяет не платить эту цену в виде latency снова.

По этой же причине сервер хранит незавершённые попытки соединения в SYN backlog, пока ожидает финальный ACK. А заполнение этого backlog большим количеством SYN-запросов, которые никогда не завершают handshake, является реальным вектором атаки SYN flood.

👉 @BackendPortal

12 ключевых сетевых протоколов которые должен знать каждый

Без этих протоколов не обходится ни одно сетевое взаимодействие. От передачи веб-страниц и синхронизации времени до защиты соединений и доставки писем это фундамент, на котором строится интернет

Сохраняй пригодится 🕵️‍♂️

👉 @BackendPortal

Backend Checklist — День 3: TLS Handshake

Все знают, что HTTPS шифрует трафик. Но часто упускается, что именно происходит во время TLS handshake. Это ещё не само шифрование, а этап согласования параметров и аутентификации, который должен завершиться до того, как начнётся обычная передача HTTPS-трафика.

Нужно решить две задачи:

> Identity
Сервер отправляет свой TLS certificate. Client проверяет его по доверенной цепочке Certificate Authority (CA). Без аутентификации можно было бы установить зашифрованное соединение не с тем сервером.

> Key exchange
Обеим сторонам нужен общий keying material для symmetric encryption, но сам секрет не передаётся по сети. Вместо этого стороны обмениваются публичными значениями и независимо друг от друга вычисляют один и тот же секрет. Сам секрет при этом никогда не передаётся.

В TLS 1.3 handshake процесс выглядит так:

• ClientHello: поддерживаемые версии TLS, cipher suites и key share
• ServerHello: согласованные параметры и key share сервера
• Certificate: сервер подтверждает свою identity
• Client проверяет certificate
• Обе стороны вычисляют traffic keys
• После этого application data защищаются с помощью symmetric encryption

Самое интересное здесь — latency. TLS выполняется после TCP handshake, а не вместо него. Новое TLS 1.2-соединение может потребовать ещё два дополнительных round trips поверх одного round trip для TCP.

То есть получается три round trips ещё до того, как HTTP request сможет дойти до сервера. В TLS 1.3 полный handshake был сокращён до одного дополнительного round trip. А при использовании session resumption TLS 1.3 также может поддерживать 0-RTT early data.

Именно поэтому просроченный или недоверенный TLS certificate способен полностью сделать сайт недоступным. Шифрование не перестаёт внезапно работать. Client просто не проходит проверку identity — поэтому TLS handshake не завершается.

👉 @BackendPortal

Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий DevOps-проект и добавить его в резюме.

Там 54 практических проекта по AWS, Azure и Kubernetes, Terraform и инфраструктуре как коду, Docker и CI/CD, DevSecOps и безопасности, мониторингу, бессерверным и облачным приложениям.

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

https://github.com/DevCloudNinjas/DevOps-Projects

👉 @BackendPortal

Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий DevOps-проект и добавить его в резюме.

Там 54 практических проекта по AWS, Azure и Kubernetes, Terraform и инфраструктуре как коду, Docker и CI/CD, DevSecOps и безопасности, мониторингу, бессерверным и облачным приложениям.

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

https://github.com/DevCloudNinjas/DevOps-Projects

👉 @BackendPortal

Backend Checklist — День 4: Анатомия HTTP-запроса

Долгое время можно было предполагать, что HTTP request — это какой-то упакованный бинарный формат, который браузер и сервер умеют декодировать. Но это обычный текст. Его буквально можно вручную отправить в socket.

По сети передаются четыре части:

Request line: method, path и version
Headers: вся информация о запросе, которая не является самим запросом
Пустая строка
Body: непосредственно данные, причём body отправляют только некоторые методы

Пустая строка

Она выглядит просто как форматирование. Но именно она сообщает серверу, что headers закончились и следующие bytes — это уже payload. Больше ничто не обозначает эту границу.

Content-Length

После запроса соединение остаётся открытым, поэтому сервер не может определить окончание body просто по тому, что новые bytes перестали поступать. Он считывает ровно столько bytes, сколько указано в Content-Length, и ни одним больше.

Укажите 25, но отправьте 20 — сервер будет ждать ещё пять bytes, которые так и не придут.

Укажите 25, но отправьте 34 — оставшиеся девять bytes останутся в buffer и могут быть прочитаны как начало следующего request.

В Django это не просто абстракция. DATA_UPLOAD_MAX_MEMORY_SIZE напрямую использует значение Content-Length и может вызвать RequestDataTooBig ещё до того, как выполнится ваш view. Значение по умолчанию — 2,5 МБ.

Если хотите увидеть весь HTTP request целиком, используйте curl -v.

👉 @BackendPortal

JOIN как в ORM: можно ли заставить PostgreSQL понимать связи между таблицами?

В статье разбирают интересную идею: вместо того чтобы каждый раз вручную прописывать JOIN ... ON, использовать уже существующие связи FOREIGN KEY как навигацию между таблицами.

Автор показывает, почему стандартный SQL до сих пор не умеет нормально использовать FK при построении JOIN, какие подходы уже существовали и как реализовать подобную навигацию в PostgreSQL уже сейчас — без патчей и новых расширений.

Отдельно рассматривается свежая инициатива 2026 года по добавлению key joins в PostgreSQL и проблема неоднозначности связей и неочевидного fan-out при 1:N JOIN.

https://habr.com/ru/articles/1065684/

👉 @BackendPortal

Backend Checklist — День 5: Анатомия HTTP-ответа

Почему неудавшийся экспорт CSV всё равно скачивается как совершенно обычный файл? Ответ кроется не в том, что содержит response, а в том, в каком порядке отправляются его части.

По сети возвращаются четыре части:

Status line: version, числовой status code и reason phrase
Headers: всё, что нужно client для интерпретации следующих данных
Пустая строка
Body: сами bytes, при этом ответы

204

и

304

вообще не содержат body

Порядок

Это последовательность во времени, а не просто структура. Server записывает каждую часть в socket по мере отправки, и каждая часть становится окончательной в тот момент, когда уходит в сеть. Client уже читает status line, пока server всё ещё формирует body. Поэтому status code выбирается ещё до того, как body полностью сформирован.

Buffered responses

Весь body сначала формируется в памяти и отправляется только после полной готовности. Поэтому до этого момента ничего ещё не отправлено client. Если в процессе возникает exception, server всё ещё может вернуть полноценный 500.

Streaming responses

Сначала отправляется status line, а затем body передаётся частями. Представьте экспорт 200 000 строк. Если соединение с базой данных оборвётся на строке 140 000, отправить 500 уже не получится. Status 200 ушёл несколько минут назад, а браузер всё это время записывал получаемые bytes в файл.

Response — это не просто набор полей, которые можно заполнить и передать целиком. Это последовательность обещаний, отправляемых одно за другим, и каждое из них становится окончательным после отправки.

Status line — первое такое обещание и при этом наименее информированное.

Откройте вкладку Network во время медленного скачивания, и вы увидите, что 200 приходит задолго до того, как файл полностью загрузится.

👉 @BackendPortal

Backend System Design: вопрос

Какая messaging architecture лучше подходит для обработки асинхронных фоновых задач в больших масштабах?

Design A: Apache Kafka
или
Design B: Redis Streams / Queue

👉 @BackendPortal

Backend Checklist — День 6: HTTP/2 Multiplexing

Почему страница по HTTP/2 загружается быстрее, чем по HTTP/1.1, при хорошем Wi-Fi, но может работать медленнее при нестабильном соединении?

Допустим, странице нужно загрузить 40 файлов. HTTP/1.1 отправляет по одному request за раз в рамках одного connection и ждёт response, прежде чем отправить следующий. Поэтому браузеры обходили это ограничение, открывая до шести connections к одному сайту. В итоге одновременно выполняются шесть запросов, а седьмой ждёт, пока освободится один из connections.

HTTP/2 вместо этого открывает один connection и отправляет через него все 40 запросов одновременно. Каждый request получает собственный stream, а части всех 40 запросов передаются вперемешку через одно соединение. Больше не нужно ждать своей очереди.

Это та часть, о которой знают многие. Но у такого подхода есть своя цена.

TCP ничего не знает о streams

Streams — это концепция, которую добавил HTTP/2. На уровне ниже TCP видит только одно connection с непрерывным потоком bytes и понятия не имеет, что эти bytes относятся к 40 разным запросам.

Один поток bytes — одна очередь

TCP передаёт bytes в том порядке, в котором они были отправлены. Поэтому, если один packet потерялся, всё, что пришло после него, ждёт повторной передачи потерянного packet. Это называется head-of-line blocking.

Для HTTP эти 40 запросов независимы, но для TCP — нет, поэтому ждать приходится всем вместе.

В HTTP/1.1 потерянный packet блокирует одно из шести connections, а остальные пять продолжают работать.

В HTTP/2 потерянный packet блокирует единственное connection, через которое идёт весь трафик.

Именно поэтому HTTP/2 выигрывает при хорошем соединении, но может проигрывать при плохом. Он устранил ожидание, вызванное самим HTTP, но не мог устранить ожидание, возникающее на уровне TCP.

nghttp -nv выводит каждый frame вместе с его stream ID, поэтому можно увидеть, как несколько responses одновременно чередуются внутри одного connection.

👉 @BackendPortal

300+ практических задач: бесплатный тренажер по SQL

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

Практика лучший способ освоить SQL, этот сервис идеально подходит чтобы набить руку. Забираем 🥊

👉 @BackendPortal

Шпаргалка по самым частым ошибкам в Python

Эта шпаргалка поможет быстро находить и устранять распространённые ошибки в Python. Вы узнаете, как распознавать SyntaxError, TypeError, NameError и другие исключения, а также разберётесь в их причинах.

В материале есть примеры ошибок и простые способы их исправления, от пропущенных кавычек до проблем с файлами и словарями.

👉 @BackendPortal

Backend Checklist — День 7: HTTP/3 поверх QUIC

HTTP/3 — одна из тех технологий, которые поначалу кажутся странными: зачем строить надёжный transport поверх UDP? Ответ — TCP.

HTTP/2 представил streams, но TCP по-прежнему воспринимал connection как один упорядоченный поток bytes. Один потерянный packet мог задержать всё, что шло следом за ним.

QUIC перенёс управление streams на уровень самого transport. Теперь, если один stream ждёт потерянный packet, остальные могут продолжать передачу данных.

В этом и заключается основная идея HTTP/3: те же HTTP semantics, но transport, который действительно понимает streams.

👉 @BackendPortal