Вы когда-нибудь задумывались, на что база данных на самом деле тратит своё время?

Большинство из нас предполагает, что она в основном занимается чтением и записью строк. Реальность куда интереснее.

Есть классическая статья Майка Стоунбрейкера, в которой производительность традиционной транзакционной СУБД анализировалась вплоть до отдельных инструкций процессора.

Вывод оказался неожиданным: менее 10% инструкций выполняют действительно полезную работу. Остальные 90%+ уходят на накладные расходы, которые почти поровну распределяются между четырьмя задачами:

1. Работа с буферами (перемещение страниц между буферным пулом и диском).

2. Блокировки (row-level locks для координации параллельных транзакций).

3. Защёлки (latches — облегчённые блокировки, обеспечивающие целостность внутренних структур данных).

4. Журналирование (запись операций до их выполнения, чтобы обеспечить возможность восстановления).

Сначала это выглядит удручающе. Нет какого-то одного узкого места, которое можно устранить. Все четыре механизма критически важны для работы традиционной базы данных. Но если посмотреть на это с другой стороны, получается один из самых интересных выводов в проектировании СУБД.

Если именно эти четыре источника накладных расходов потребляют процессорное время, что будет, если необходимость в них исчезнет?

- нет буферов → база данных полностью хранится в памяти;
- нет блокировок и защёлок → однопоточная архитектура;
- нет журналов → репликация вместо логирования.

Именно на этом строилась идея H-Store, а позже и VoltDB. Вы жертвуете частью гибкости, но взамен получаете производительность, в которую сложно поверить.

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

https://15721.courses.cs.cmu.edu/spring2016/papers/hstore-lookingglass.pdf

👉 @BackendPortal

Вы арендуете собственный код у Microsoft.

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

И никаких ежемесячных платежей. Называется Gitea

Закидываете один файл на сервер — и получаете свой GitHub. Pull Request'ы, Issues, Wiki, реестр пакетов и даже CI-систему, которая умеет запускать ваши существующие GitHub Actions без переписывания конфигурации.
→ Поставляется одним файлом. Никакой боли с настройкой.
→ Работает на 256 МБ ОЗУ. Можно хостить даже на Raspberry Pi.
→ Совместим с GitHub Actions из коробки.
→ Умеет импортировать репозитории, Issues и Pull Request'ы.
→ Поднимается менее чем за 15 минут через Docker.

Более 55 000 звёзд на GitHub.

Полностью открытый исходный код. Лицензия MIT. Бесплатен навсегда.

👉 @BackendPortal

Плейлист по RAG

Что вы изучите:

* Retrieval-Augmented Generation (RAG)
* Document Loaders в LangChain
* Text Splitters в LangChain
* Vector Stores в LangChain
* Retrievers в LangChain
* Создание чат-бота для YouTube с помощью LangChain
* Реализация RAG на базе LangGraph
* Продвинутый RAG: как Corrective RAG (CRAG) решает проблемы классического RAG
* Self-RAG: как заставить ИИ самостоятельно проверять достоверность своих ответов и выполнять фактчекинг своих выводов

👉 @BackendPortal

Подборка бесплатных ресурсов для изучения Go 😢

— Набор интерактивных практических заданий, которые нужно выполнять прямо в браузере: https://tour.golang.org

— Руководство-шпаргалка по основным темам языка. На каждую тему есть полноценная программа, для каждой строчки которой подготовлено подробное пояснение: https://gobyexample.com

— Ресурс, по содержанию похожий на предыдущий. Здесь тоже для каждой из тем языка представлены практические примеры с объяснениями: https://gowebexamples.com

👉 @BackendPortal

FastAPI получил встроенную поддержку фронтенда.

В версии FastAPI 0.138.0 появился метод app.frontend(), который позволяет раздавать готовое фронтенд-приложение напрямую из FastAPI, включая поддержку client-side routing.

Подходит для:
React + TanStack Router
Astro static builds
приложений на Vite
других SPA и статических фронтендов

Теперь вместо отдельной настройки Nginx или дополнительного сервера можно подключить собранную папку одной строкой:

from fastapi import FastAPI

app = FastAPI()

app.frontend("/", directory="dist")

По словам разработчиков, это упрощает деплой full-stack приложений, где FastAPI отвечает и за API, и за раздачу фронтенда. Поддержка client-side routing уже встроена.

Также в релизе появился встроенный skill для AI-агентов. Теперь Claude Code, Codex и другие агенты могут изучить новую функциональность FastAPI через:

uvx library-skills

Это позволяет агентам использовать возможности FastAPI и актуальные паттерны без ручного объяснения через промпты

👉 @BackendPortal

Нашёл интересный инструмент для поиска и устранения дублирующегося кода.

Называется Deslop. Написан на Rust, но работает не только с Rust-проектами — поддерживает Python, Dart и C#.
Инструмент анализирует кодовую базу, находит дубликаты и помогает избавиться от повторяющихся фрагментов. Автор предлагает просто установить его в VS Code или любой другой форк редактора и использовать прямо в процессе разработки.

Автор проекта также собрал отдельную подборку статей и исследований, которые легли в основу алгоритмов Deslop.

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

👉 @BackendPortal

Репозитории на GitHub, которые научат вас большему, чем многие платные курсы:

30-Days-of-Python
Структурированная программа на 30 дней с ежедневными уроками и практическими заданиями на Python Shell. Помогает пройти путь от полного новичка до написания собственных скриптов.

project-based-learning
Огромная коллекция Python-проектов: веб-приложения, парсеры, небольшие игры и многое другое. Каждый проект сопровождается пошаговым разбором процесса разработки.

Build-your-own-X
Сборник проектов, которые можно реализовать самостоятельно по готовым руководствам. Настоящая находка с более чем 500 тысячами звёзд на GitHub.

ML-for-Beginners
Бесплатный курс по машинному обучению от Microsoft. Включает объяснения теории, тесты и практические задания. Отлично подходит для изучения основ ML.

500 AI/ML/DL Projects
С этим репозиторием идеи для проектов не закончатся. Внутри собрано более 500 проектов по AI, машинному обучению, глубокому обучению, компьютерному зрению и обработке естественного языка.

👉 @BackendPortal

Многие разработчики путают WebSocket и HTTP Polling, хотя это два принципиально разных подхода к организации обмена данными между клиентом и сервером.

HTTP Polling

HTTP Polling основан на периодическом опросе сервера. Клиент через заданные промежутки времени отправляет запросы, чтобы проверить, появились ли новые данные.

Даже если на сервере ничего не изменилось, запросы продолжают выполняться. Из-за этого увеличивается количество сетевого трафика и возникает дополнительная задержка между появлением события и его получением клиентом.

Например, клиент может каждые пять секунд отправлять запрос:

Клиент → Сервер: «Есть обновления?»

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

Преимущество Polling заключается в простоте реализации. Недостатками являются лишняя нагрузка на сервер и менее оперативная доставка обновлений.

WebSocket

WebSocket использует постоянное двустороннее соединение между клиентом и сервером. После установки соединения оно остаётся открытым до тех пор, пока одна из сторон его не закроет.

Благодаря этому сервер может отправлять данные клиенту сразу после возникновения события, не дожидаясь нового запроса.

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

Такой подход обеспечивает минимальную задержку и значительно уменьшает количество лишних запросов.

Области применения

HTTP Polling обычно используют в системах, где обновления происходят редко и требования к скорости доставки данных невысоки. Этот подход часто встречается в простых дашбордах и устаревших системах.

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

Простое сравнение

HTTP Polling можно представить как человека, который постоянно спрашивает:

«Появилось что-нибудь новое?»

WebSocket больше похож на подписку на уведомления:

«Когда произойдёт событие, меня сразу об этом сообщат».

Выбор между этими подходами зависит от требований приложения к скорости обмена данными, нагрузке на сервер и объёму передаваемого трафика.

👉 @BackendPortal

Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:

COPY . .
RUN npm install

должно быть:

COPY package*.json ./
RUN npm install
COPY . .

почему это важно?

docker кэширует каждую инструкцию как отдельный слой
исходный код меняется с каждым коммитом
поэтому COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.

👉 @BackendPortal

Компоненты Docker

Dockerfile
Файл-инструкция, который описывает шаги сборки Docker-образа.

Image (Образ)
Шаблон только для чтения, содержащий код приложения, зависимости, библиотеки и конфигурацию среды выполнения.

Container (Контейнер)
Запущенный экземпляр образа, внутри которого фактически выполняется приложение.

Docker Daemon
Фоновая служба, отвечающая за управление объектами Docker: образами, контейнерами, сетями и томами.

Docker Engine
Платформа, которая запускает и управляет контейнерами через Docker Daemon, API и CLI.

Volumes (Тома)
Постоянное хранилище данных, которое сохраняет информацию независимо от жизненного цикла контейнера.

👉 @BackendPortal

3 популярных паттерна для мультимодального RAG.

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

1. Общее векторное пространство (Shared Vector Space)

* Позволяет выполнять поиск между разными модальностями без конвертации форматов.
* Например, можно искать изображения по текстовому запросу.
* Требует больших объёмов мультимодальных данных для обучения.
* При недостаточно разнообразных данных возможен semantic drift — снижение качества соответствия между модальностями.

2. Одна базовая модальность (Single Grounded Modality)

* Все данные сначала переводятся в текст через OCR, captioning или транскрипцию.
* Легко интегрируется в существующие текстовые RAG-системы.
* Теряются пространственные связи и визуальный контекст изображений.
* Качество поиска напрямую зависит от качества распознавания и описания контента.

3. Раздельные пайплайны поиска (Separate Retrieval Pipelines)

* Для каждой модальности используется собственный индекс и механизм поиска.
* Обычно обеспечивает лучшую точность извлечения данных.
* Сложнее объединять и ранжировать результаты из разных источников.
* Требует больше вычислительных ресурсов, поскольку поиск выполняется отдельно для каждого типа данных.

Большинство «мультимодальных» RAG-систем сегодня фактически используют второй подход — сначала преобразуют данные в текст, а затем работают как обычный текстовый RAG. Выбранная архитектура напрямую определяет, какие запросы система сможет обрабатывать и какая часть исходной информации будет потеряна по пути.

👉 @BackendPortal

Небольшой совет для CI:
На Node.js 22+ используйте node --run <script> вместо pnpm run <script> для запуска простых package-скриптов в GitHub Actions.
Небольшое изменение, которое экономит 200–400 мс на каждом вызове.

👉 @BackendPortal

Исторический момент. Новый HTTP-метод в стандарте.

QUERY. Альтернатива GET и POST.

Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.

Только что повышен до Proposed Standard.

👉 @BackendPortal

Если вы уезжаете в отпуск в середине июля — сочувствуем 😭

AvitoTech анонсировал новый IT-рейв АвитоТехно — тусовку для тех, кто хочет отдохнуть от созвонов и вот этого всего корпоративного. Прошлая вечеринка была полгода назад в онлайне — сейчас же коллеги наконец зовут всех офлайн 😎 Если кратко — надо идти!

Собирают всех 17 июля в ДК «Кристалл». Лайнап следующий:
— THE DAWLESS;
— LAVBLAST;
— BÖRIS REDWÄLL;
— SALAMÉ;
— диджей-сеты от разрабов из AvitoTech, а ещё от команд Ozon и Т-Банка;
— РЕСПЕКТ АГЕНТСТВО (диджей-сет);
— BiiCLA (в глубине души пищим от восторга).

Ну огонь же! Только не забудьте зарегистрироваться по ссылке.

Ближайший релиз PostgreSQL 19 получит поддержку графовых запросов.

С помощью SQL/PGQ можно будет работать со связями напрямую через SQL:

→ социальные сети
→ рекомендательные системы
→ выявление мошенничества
→ графы зависимостей

PostgreSQL больше не ограничивается ролью реляционной базы данных.

Он постепенно превращается в универсальную платформу для хранения и обработки данных любых типов.

👉 @BackendPortal

Один запрос. Четыре разных кэша. Большинство разработчиков думает только об одном.

Browser Cache — складирует статику (CSS, JS, картинки) на устройстве пользователя. Самый быстрый ответ. Никаких сетевых вызовов.

CDN Cache — держит контент на граничных узлах рядом с пользователем. Пользователь в Токио получает данные с ближайшего CDN, а не с твоего сервера. Меньше задержка, меньше трафика на origin.

Redis Cache — хранит часто запрашиваемые данные в памяти. Вместо того чтобы ходить в базу каждый раз: приложение → Redis. Если мимо — в базу. Отлично подходит для сессий, каталогов, API-ответов, rate limiting.

База данных — источник правды. Если данных нет в Redis, приложение идёт в базу. И часто пишет их обратно в Redis на будущее.

Типичный путь запроса: пользователь → Browser Cache → CDN → приложение → Redis → база.

Как запомнить: Browser — кэш на твоём устройстве. CDN — кэш рядом с тобой. Redis — кэш в памяти приложения. База — постоянное хранилище.

Самый быстрый запрос к базе — тот, который никогда не выполняется.

👉 @BackendPortal

Идём на AI Hardcore Day в офис Авито на Лесной 11 июля! 🤩

Будем слушать доклады о Spec-Driven Development, разработке и тестировании MCP, атаках на GenAI-агентов.
А после — нетворкать на террасе.

⚡ Регистрация и подробности — по ссылке.

Кстати, доклады будут не под запись — советуем не пропускать!

Слишком много сообщений в логах и ищете ошибки?

Попробуйте:

journalctl -p err -b

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

Здесь:
- -p err = показывать только сообщения об ошибках
- -b = показывать логи с текущей загрузки

👉 @BackendPortal

Cloudflare потратила 6 недель на охоту за багом в HTTP-библиотеке hyper на Rust. Исправление — 4 строки. 🦀

Симптом: ответы с изображениями возвращали HTTP 200, но с обрезанными данными: ответ на 14.9 МБ приходил как 219 КБ, и никаких ошибок нигде не логировалось.

Корневая причина: один let _ = в диспетчерском цикле hyper отбрасывал сигнал Poll::Pending от операции flush. Буфер сокета заполнился, flush вернул Pending, но hyper проигнорировал это и всё равно вызвал shutdown, молча сбросив оставшиеся данные.

Что сделало поиск таким сложным:
→ Проявлялось только в продакшене, никогда через curl
→ Срабатывало только на больших изображениях при реальной конкурентности
→ Исчезало при расширении strace (замедление немного смещало тайминги)
→ Все логи на уровне приложения сообщали об успехе

Прорыв наступил с strace — трассировкой системных вызовов на уровне ядра, которая показала, что shutdown вызывался после всего одной записи, хотя в буфере оставалось ещё 14.8 МБ.

Баг существовал в hyper на протяжении нескольких мажорных версий (0.14 — 1.8). Он был незаметен, потому что большинство читателей выгружают данные достаточно быстро, и буфер сокета никогда не заполняется. Новый, более быстрый промежуточный сервер создал ровно столько обратного давления, чтобы проявить баг.

Исправление уже вмержено в upstream: hyperium/hyper PR #4018.

Мастер-класс по отладке асинхронного Rust на системном уровне.

http://blog.cloudflare.com/hyper-bug

#RustLang #AsyncRust #Hyper #SystemsProgramming #Debugging #OpenSource #Cloudflare

👉 @BackendPortal

Лучшие практики безопасности API

Большинство взломов API происходят из-за сломанной авторизации, утёкших секретов или отсутствия ограничения скорости запросов. Рассмотрим основы.

- Используйте современный OAuth/OIDC + MFA: PKCE для публичных клиентов, короткоживущие токены и step-up MFA для всего чувствительного. Implicit и password гранты уже пора похоронить.
- Применяйте детальную авторизацию: Проверяйте права на уровне объекта, функции и поля на каждом запросе. BOLA всё ещё остаётся главной уязвимостью API.
- Минимизируйте скоупы и данные: Выдавайте каждому клиенту минимальный токен и минимум необходимых данных. Возвращайте только те поля, которые действительно нужны вызывающей стороне.
- Шифруйте каждый прыжок: TLS для внешнего трафика и mTLS между сервисами. Если данные пересекают сетевую границу — шифруйте.
- Защищайте секреты и ключи: Храните ключи подписи в хранилищах на базе HSM. Ротируйте их.
- Валидируйте запросы через схемы: Отбрасывайте неизвестные поля, слишком большие payloads и подозрительные URL на шлюзе. Не допускайте плохие входные данные до бизнес-логики.
- Ограничивайте частоту запросов и ресурсы: Квоты на пользователя, лимиты на размер payload и таймауты выполнения. Без этого один некорректный клиент положит всю систему.
- Защищайте чувствительные бизнес-процессы: Оборачивайте логин, оформление заказа и OTP в антибот, идемпотентность и step-up аутентификацию.
- Контролируйте исходящие и сторонние вызовы: Создайте белый список, куда ваш API может обращаться наружу, и блокируйте внутренние metadata-эндпоинты. Ваша безопасность настолько сильна, насколько сильно самое слабое интеграционное звено.
- Ужесточайте конфигурацию и обработку ошибок: Deny-по-умолчанию на CORS, методы и debug-эндпоинты. Возвращайте общие ошибки, никогда — stack trace.
- Инвентаризируйте API и версии: Отслеживайте каждый эндпоинт, версию и shadow API. Нельзя защитить то, о существовании чего вы не знаете.
- Логируйте, обнаруживайте и реагируйте: Отправляйте решения об авторизации и аномалии в SIEM. Сигнализируйте о всплесках 401 до того, как они станут инцидентами.

👉 @BackendPortal