Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий 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

👉 @BackendPortal

Backend Checklist — День 8: Resource-based URLs

Почему вообще важно, назван endpoint в честь invoice или в честь действия, которое нужно с ним выполнить, если оба возвращают абсолютно одинаковый JSON? Response одинаковый. Но всё, что находится между client и server, работает по-разному.

Два места — одна задача

HTTP определяет methods для обозначения цели request, а URI используется для идентификации resource. Если поместить action в path, то path начинает отвечать на вопрос, на который уже должен отвечать method, и две части одной request line могут противоречить друг другу.

Path перестаёт разрастаться

Если называть resource, то все новые действия с invoice будут определяться через method, а не через очередной endpoint. В итоге API растёт вместе с количеством resources, а не с количеством добавленных features.

Что видит cache

Response может кэшироваться, если используется GET или HEAD. POST и PATCH подходят для этого только при наличии freshness information и соответствующего Content-Location header, что практически нигде не реализуется. Поэтому endpoint, названный в честь action, в итоге ничего не сохраняет на edge, и каждый read request проходит весь путь до origin server.

Обратная ситуация ещё опаснее

HTTP method считается safe, если он не изменяет состояние server. Браузеры могут выполнять prefetch, полагаясь на это правило, а crawlers также рассчитывают на него. Если направить их на endpoint, который что-то удаляет, — они это удалят.

Ничто не обеспечивает это автоматически

Nginx не может проверить, что route предназначен только для чтения. Framework тоже не может этого проверить. Это правило соблюдается лишь потому, что handler за конкретным route действительно ведёт себя соответствующим образом.

URL — это имя, а не инструкция

Если path уже говорит, что должно произойти, request сообщает одно и то же дважды. А всё, что находится между client и server, будет ориентироваться на ту часть request, для чтения которой оно было спроектировано.

👉 @BackendPortal