15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Краткая шпаргалка по Kotlin
Синтаксис, типы данных, условия, циклы, коллекции, функции, классы, null safety, generics, lambda и другие конструкции.
Сохраняем в закладки 😏
👉 @BackendPortal
Backend Checklist — День 11: API Versioning
Вы выпустили v1. Теперь нужно изменить структуру response, не сломав существующих clients. Где указывать версию API?
Есть три варианта:
• Path: /v1/users
• Header: Api-Version: 2
• Query: /users?api-version=2
Все три подхода работают. Главное различие — какие компоненты системы могут видеть версию.
• Path: версия видна routers, proxies, logs и caches. Простой и широко используемый вариант.
• Header: позволяет сохранить URL чистыми, но cache может не различать версии, если не использовать Vary.
• Query: версия хорошо видна инфраструктуре, но смешивается с параметрами фильтрации и pagination.
Главная опасность — caching
Если версия передаётся через header, а cache формирует ключ только по URL, client с v2 может получить закэшированный response от v1.
Версия API — это обещание о структуре response. Убедитесь, что cache умеет различать разные версии API.
👉 @BackendPortal
Хакатон на космических данных. Санкт-Петербург, Красноярск или онлайн из любой точки страны.
Стартуем 18 сентября.
За выходные участники доводят одну из задач до рабочего решения.
Санкт-Петербург. К 2035 году над Землёй должен работать топливный узел, у которого заправляются корабли, и откуда он будет получать топливо - с Земли, с Луны или из резерва - пока не решил никто. Команде предстоит собрать схему поставок, посчитать резервы и решить, во что вкладываться сразу. Призовой фонд 1,2 млн ₽.
Красноярск. Спутник видит горящий лес раньше любого наземного поста, но вместе с пожаром ловит нагретые крыши, факелы на месторождениях и блики на воде. Команде предстоит научить сервис отличать настоящий очаг от шума, обвести гарь и выдать площадь в гектарах. Призовой фонд 600 тыс. ₽.
Лучшие забирают приз на площадке и билет в московский финал 25–27 сентября, где разыграют ещё 2,4 млн рублей.
Команда 3–5 человек, недостающих можно найти на платформе.
Регистрация по ссылке космохакатон.рф
Backend Checklist — День 10: Status Codes
Request завершился ошибкой. Что вернуть: 400, 401, 403, 404 или 422? Большинство API используют тот status code, который кажется наиболее знакомым. Именно с этой привычки и начинаются незаметные баги.
Первая цифра передаёт основную суть:1xx → request всё ещё обрабатывается2xx → всё прошло успешно3xx → resource перемещён или требуется перенаправление4xx → ошибка на стороне client5xx → server столкнулся с ошибкой при обработке request
А дальше начинаются пары, которые часто путают:
401 vs 403:401 = «Я пока не знаю, кто вы».403 = «Я знаю, кто вы, но доступ вам всё равно запрещён».
400 vs 422:400 = request не удалось корректно разобрать.422 = request разобран, но переданные значения невалидны.
301 vs 307:301 означает постоянный redirect и может кэшироваться.307 сохраняет исходные HTTP method и body.
Главное правило: status code — это обещание о том, что произошло, а не просто label, который добавляется к response постфактум.
Верните 200 с ошибкой в body — и вы только что сообщили всем retry-механизмам, alerts и uptime checks, что всё в порядке.
Выбирайте status code исходя из того, что действительно произошло, а не из того, какой оказался под рукой.
👉 @BackendPortal
Backend Checklist — День 9: Idempotency
Клиенты повторяют запросы. Request может завершиться по timeout, соединение может оборваться, пользователь может снова нажать кнопку — и один и тот же request попадёт на server дважды.
Request считается idempotent, если его повторное выполнение безопасно. Отправите его один раз или десять — server останется в одном и том же состоянии.
Какие методы гарантируют idempotency?GET, PUT и DELETE.
Повторно получите invoice, снова запишите тот же invoice или снова удалите его — итоговое состояние server останется тем же. POST такой гарантии не даёт. Каждый POST — это новая операция, поэтому два запроса могут означать две оплаты, два заказа или две строки в базе данных.
Но одинаковый результат не означает одинаковый response
204. Попробуйте удалить его ещё раз — получите 404.Ваш proxy уже полагается на это
GET, PUT или DELETE на другом server, но не станет автоматически повторять POST. Он ориентируется на HTTP method и доверяет его семантике.Поэтому главная проблема — POST
proxy_next_upstream в конфигурации Nginx. Он уже определяет, какие requests можно повторять при определённых ошибках.
Backend Checklist — День 8: Resource-based URLs
Почему вообще важно, назван endpoint в честь invoice или в честь действия, которое нужно с ним выполнить, если оба возвращают абсолютно одинаковый JSON? Response одинаковый. Но всё, что находится между client и server, работает по-разному.
Два места — одна задача
Path перестаёт разрастаться
Что видит cache
GET или HEAD. POST и PATCH подходят для этого только при наличии freshness information и соответствующего Content-Location header, что практически нигде не реализуется. Поэтому endpoint, названный в честь action, в итоге ничего не сохраняет на edge, и каждый read request проходит весь путь до origin server.Обратная ситуация ещё опаснее
Ничто не обеспечивает это автоматически
URL — это имя, а не инструкция
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
300+ практических задач: бесплатный тренажер по SQL
SQL Climber интерактивный тренажер с сотнями заданий, где можно решать SQL-задачи прямо в браузере и сразу получать проверку решений.
Практика лучший способ освоить SQL, этот сервис идеально подходит чтобы набить руку. Забираем 🥊
👉 @BackendPortal
Backend System Design: вопрос
Какая messaging architecture лучше подходит для обработки асинхронных фоновых задач в больших масштабах?
Design A: Apache Kafka
или
Design B: Redis Streams / Queue
👉 @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
Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий DevOps-проект и добавить его в резюме.
Там 54 практических проекта по AWS, Azure и Kubernetes, Terraform и инфраструктуре как коду, Docker и CI/CD, DevSecOps и безопасности, мониторингу, бессерверным и облачным приложениям.
Можно выбрать проект, собрать его за выходные и получить работу, о которой уже не стыдно рассказать на следующем собеседовании.
https://github.com/DevCloudNinjas/DevOps-Projects
👉 @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
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 снова.
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
Команды нет — это не причина пропустить КосмоХакатон
18–20 сентября, Санкт-Петербург, Красноярск или онлайн из любой точки страны. На платформе есть подбор команды: регистрируетесь один, указываете, что умеете, и находите недостающих
К двум задачам, о которых писали раньше, добавились ещё две.
Санкт-Петербург - космонавт в открытом космосе. Солнечные вспышки, геомагнитные бури, радиация меняются по часам, решение о выходе принимают по прогнозу. Команде предстоит выделить ключевые угрозы и собрать техническое решение для их анализа. Данные, физика, инженерия.
Красноярск - зелёные финансы. Углеродные кредиты продаются под обещание, что где-то растёт лес, и проверить это обещание можно со спутника. Команде предстоит собрать платформу для токенизации и продажи кредитов, привязанных к реальному состоянию лесного массива. Данные, финансы, продукт.
Фонд площадок — 1,2 млн ₽ и 600 тыс. ₽. Лучшие забирают приз и билет в московский финал 25–27 сентября на 2,4 млн рублей.
Подробности и регистрация
Нашёл сокровищницу для новичков в Python
Удобная шпаргалка, где в одном месте собрали всё, что чаще всего приходится вспоминать: типы данных, операции, строки, списки, словари, методы и база конструкции языка.
Хорошая штука, можно держать рядом во время работы, обучения и практики.
Забираем в закладки ❤️
👉 @BackendPortal
AI-агенты и инфраструктура
Вашему coding agent не нужно знать, где именно выполняется команда: локально, внутри Docker или в удалённой sandbox.
Предоставьте каждому execution backend одинаковый интерфейс, а harness пусть работает с ними одинаково.
👉 @BackendPortal
Приоритеты плохого разработчика 😪
👉 @BackendPortal
Эффективное освоение алгоритмов через паттерны LeetCode
Ресурс группирует задачи LeetCode по фундаментальным паттернам решения, превращая разрозненные задачи в понятную систему подходов.
Каждый паттерн объяснён, подкреплён примерами и визуализациями что помогает не просто «зубрить» задачи, а понимать сам подход, который легко переносится на новые задачи.
Есть треки для пошаговой подготовки от новичка до продвинутого. Это экономит время: вместо хаотичного выбора задач вы двигаетесь по структурному пути, который закрывает все ключевые темы для собесов.
👉 @BackendPortal
Самая масштабная шпаргалка для Python-разработчиков
Можно забрать PDF версию в хорошем качестве❤️
👉 @BackendPortal
Вы вообще видели, что сделала команда AvitoTech ко Дню разработчика?!
В честь наступающего праздника вместе со студией FU2RE и 3D-художником Dmitriev Video ребята создали большой портал в прошлое — эмулятор 2006 года будущего разработчика. Внутри — олдскульные игры и викторины, за которые можно лутать баллы и подниматься в рейтинге.
Топ-3 игроков 15 сентября получат суперпак настоящих разрабов, внутри которого салфетка на монитор из коллаборации с Elnik, плед, сумка и плюшевый талисман — кот Б/У. Так что времени сыграть ещё много!
P. S. А ещё в канале AvitoTech до 13 сентября будут каждый день выходить крутые праздничные посты. Не пропустите: может быть, и там они спрятали подарки ❤️
Шпаргалка по самым частым ошибкам в Python
Эта шпаргалка поможет быстро находить и устранять распространённые ошибки в Python. Вы узнаете, как распознавать SyntaxError, TypeError, NameError и другие исключения, а также разберётесь в их причинах.
В материале есть примеры ошибок и простые способы их исправления, от пропущенных кавычек до проблем с файлами и словарями.
👉 @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
Один поток bytes — одна очередь
nghttp -nv выводит каждый frame вместе с его stream ID, поэтому можно увидеть, как несколько responses одновременно чередуются внутри одного connection.
Backend Checklist — День 5: Анатомия HTTP-ответа
Почему неудавшийся экспорт CSV всё равно скачивается как совершенно обычный файл? Ответ кроется не в том, что содержит response, а в том, в каком порядке отправляются его части.
По сети возвращаются четыре части:
Status line: version, числовой status code и reason phrase
Headers: всё, что нужно client для интерпретации следующих данных
Пустая строка
Body: сами bytes, при этом ответы
204и
304вообще не содержат body
500.500 уже не получится. Status 200 ушёл несколько минут назад, а браузер всё это время записывал получаемые bytes в файл.200 приходит задолго до того, как файл полностью загрузится.
Backend Checklist — День 4: Анатомия HTTP-запроса
Долгое время можно было предполагать, что HTTP request — это какой-то упакованный бинарный формат, который браузер и сервер умеют декодировать. Но это обычный текст. Его буквально можно вручную отправить в socket.
По сети передаются четыре части:
Request line: method, path и version
Headers: вся информация о запросе, которая не является самим запросом
Пустая строка
Body: непосредственно данные, причём body отправляют только некоторые методы
Content-Length, и ни одним больше.25, но отправьте 20 — сервер будет ждать ещё пять bytes, которые так и не придут.25, но отправьте 34 — оставшиеся девять bytes останутся в buffer и могут быть прочитаны как начало следующего request.DATA_UPLOAD_MAX_MEMORY_SIZE напрямую использует значение Content-Length и может вызвать RequestDataTooBig ещё до того, как выполнится ваш view. Значение по умолчанию — 2,5 МБ.curl -v.
Нашёл отличный репозиторий для тех, кто хочет за выходные собрать настоящий DevOps-проект и добавить его в резюме.
Там 54 практических проекта по AWS, Azure и Kubernetes, Terraform и инфраструктуре как коду, Docker и CI/CD, DevSecOps и безопасности, мониторингу, бессерверным и облачным приложениям.
Можно выбрать проект, собрать его за выходные и получить работу, о которой уже не стыдно рассказать на следующем собеседовании.
https://github.com/DevCloudNinjas/DevOps-Projects
👉 @BackendPortal
12 ключевых сетевых протоколов которые должен знать каждый
Без этих протоколов не обходится ни одно сетевое взаимодействие. От передачи веб-страниц и синхронизации времени до защиты соединений и доставки писем это фундамент, на котором строится интернет
LeetCode для DevOps — 70+ реальных хардкорных задач
Коллекция практических заданий для DevOps и backend-инженеров. Все задачи основаны на реальных сценариях, имеют разные уровни сложности и авто-проверку решений
Тренируйся легко 💪
👉 @BackendPortal
Git: шпаргалка для новичков
Working Directory: Рабочая директория, здесь вы редактируете файлы проекта
Команда:
git add - добавить изменения в индекс
git commit - зафиксировать изменения в локальном репозитории
git push - отправить коммиты в удалённый репозиторий
git fetch - получить новые коммиты с удалённого репозитория без слияния
git pull - получить и объединить изменения из удалённого репозитория
git stash - сохранить незавершённые изменения
git stash - apply применить изменения из stash, не удаляя их
git stash pop - применить и удалить сохранённые изменения