❤️ Конференция Backend Talks от Яндекс 360 — место встречи опытных бэкенд-разработчиков

Обсудим лучшие практики в разработке высоконагруженных систем и разберём реальные рабочие кейсы на примере сервисов с аудиторией в 100+ миллионов пользователей.

Когда: 16 мая, 12:00 мск
Где: офлайн в Москве и онлайн

В программе — два зала с докладами и решением практических задач.

🈲 Расписание зала №1:

«Направленный ациклический граф в PostgreSQL: как мы научили реляционную базу хранить оргструктуру на 500 тыс. пользователей»
//Спикер: Малик Минубаев, разработчик в B2B-платформе

«Как Яндекс Диск выдерживает сотни гигабит входящего трафика: устройство балансировки загрузок»
//Спикер: Илья Абрамов, разработчик в Диске

«Как формировать технологический стек и не погибнуть в священных войнах: от хаоса к процессам и техрадару»
//Спикер: Дмитрий Сафонов, руководитель команды разработки платформы микросервисов

«Зачем и как бэкендеру расти в карьере в 2026 году»
//Спикер: Дмитрий Соломонов, руководитель группы B2B-разработки бэкенда Диска

«Семь раз подумай, один раз пошардируй: как мы начали горизонтально масштабировать метаданные чатов Телемоста»
//Спикер: Никита Звонарев, разработчик в Мессенджере

🚀«Марс: великое противостояние»
//Спикер: Владимир Сурдин, астроном, кандидат физико-математических наук, доцент

Параллельно будут работать зоны открытого общения — можно в любой момент подключиться к обсуждениям с инженерами Яндекс 360 и провести время с пользой!

📌 Узнать подробнее и зарегистрироваться можно на сайте мероприятия

Перед тем как добавлять индекс в Постгрес (ускоряющий доступ к данным механизм), ответь на 4 вопроса.

Я вижу эту ошибку в ревью кода каждую неделю.
Появляется медленный запрос → добавляют индекс → считают, что проблема решена.

Но в половине случаев становится хуже.

Перед добавлением индекса проверь:

1. Используется ли колонка в ГДЕ, СОЕДИНЕНИЯХ или СОРТИРОВКЕ ПО
Если она встречается только в ВЫБРАТЬ, индекс почти не даст эффекта.

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

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

4. Какая кардинальность колонки
Индексы лучше работают, когда сильно сужают выборку.
Колонки с малым числом уникальных значений (низкая кардинальность, например перечисления или булевы поля) сами по себе плохо фильтруют, но могут помогать в комбинации.

Сначала запускай план выполнения запроса (объяснение плана выполнения).
Потом запускай снова после изменений.

Если стоимость не падает — индекс не помогает.

Удаляй его.

Индексы не бесплатные.
Это всегда компромисс.

Большинство добавляет индексы чтобы “починить” запросы.
Более сильный подход — чинить сами запросы, чтобы индексы не требовались.

👉 @BackendPortal

Я просмотрел 50+ бэкенд-проектов за этот год.

Одинаковые 3 ошибки повторяются постоянно.

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

1. Структура папок по слоям, а не по фичам

/controllers, /services, /models хорошо работают в учебных примерах.

но в реальном коде это разрывает связанную логику.

Чтобы понять одну фичу вроде “биллинг”, приходилось прыгать по нескольким папкам.
И всё равно без поиска по коду не находилось целиком.

На малом масштабе работает.
На большом даёт лишнее трение при навигации по коду.

2. Один общий обработчик ошибок, который всегда возвращает 500

И внезапно всё становится “внутренней ошибкой сервера”.

Это убивает полезный сигнал.

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

Разные случаи должны обрабатываться отдельно:
400 → некорректный ввод
404 → ресурс не найден
500 → ошибка системы

3. Чтение конфигурации прямо в бизнес-логике

Вызовы получения переменных окружения по всему коду выглядят удобно в начале.

Со временем это создаёт скрытые зависимости.

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

Загрузка и валидация конфигурации один раз при старте убирает большую часть этих проблем.

Ничего из этого не относится к сложной архитектуре.
Поэтому такие ошибки и встречаются так часто.

Они не ломают систему сразу.
Они ухудшают изменяемость, отладку и понимание кода со временем.

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

👉 @BackendPortal

Раньше казалось, что включение HTTP/2 автоматически ускорит систему.

В большинстве случаев — нет.

HTTP/2 — не про общий прирост производительности.

Он решает конкретную проблему.

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

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

Это имеет значение только если узкое место — соединения.

Не решает:
медленные запросы к базе данных
плохую индексацию
N+1 запросы
большие ответы API
синхронные код-пути

Частый кейс: включили HTTP/2 на балансировщике, ждут ускорения — изменений нет.
С конфигурацией всё ок. Просто запрос тратит ~500 мс в базе данных.

HTTP/2 помогает, когда упираешься в соединения.
Большинство систем — нет.

Если задержка приходит из базы или логики приложения, смена протокола незаметна.

Что реально даёт эффект:
Найти, куда уходит время.
Фикс не того слоя создаёт ощущение прогресса.
На результат это не влияет.

👉 @BackendPortal

Перейдите в свой проект на FastAPI и выполните:

uvx library-skills

Обучите свои ИИ-агенты для разработки корректной работе с FastAPI. 😎

https://library-skills.io

👉 @BackendPortal

Open-source GitHub-дашборд, который агрегирует данные из репозиториев, задач, пул-реквестов, трафика, Actions, контрибьюторов и других источников в одном интерфейсе через REST и GraphQL API, с Kanban-режимом и ежедневными сводками.

gh-dashboard забирает данные через GitHub REST и GraphQL API и разделяет их на несколько представлений: сетка репозиториев с оценкой здоровья, кросс-репозиторные списки задач и пул-реквестов, страница аналитики с тегированием репозиториев по статусам, ежедневные сводки (опционально генерируются через OpenAI), а также Kanban-доска.

Бэкенд на Node.js обрабатывает OAuth Device Flow и проксирование запросов к API, при этом токены не попадают в браузер. Фронтенд — одностраничное приложение на React 19 и Vite.

Развёртывание через Docker, требуется только GitHub OAuth Client ID, OpenAI-ключ опционален.

👉 @BackendPortal

Лёгковесный настольный клиент с открытым исходным кодом, который позволяет подключаться к разным базам данных через единый инструмент: MySQL, PostgreSQL, SQLite, Redis, MongoDB, ClickHouse и другие. Не нужно ставить отдельные клиенты под каждую СУБД.

DBX собран на Tauri 2 + Vue.js 3 + Rust, размер установщика около 15 МБ, без бандла Chromium.

Поддерживает подключение к десяткам баз данных, включая OceanBase и openGauss. SQL-редактор содержит AI-ассистента для генерации и оптимизации запросов на естественном языке; таблицы поддерживают inline-редактирование, сортировку и поиск; для Redis и MongoDB есть отдельные браузеры.

https://github.com/t8y2/dbx

👉 @BackendPortal

Go часто выигрывает у Node.js на бэкенде не из-за бенчмарков, а из-за практики разработки.

В типичном Node.js-проекте старт начинается с набора решений: какой фреймворк, логгер, валидация, тесты. До первой бизнес-ручки уже собирается стек: Express, body-parser, helmet, cors, dotenv, winston, jest, ts-node.

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

В Go ситуация другая. Используются net/http, encoding/json, log, testing, и этого достаточно для запуска сервиса. Базовые задачи уже закрыты стандартной библиотекой, поэтому фокус смещается на бизнес-логику, а не на сборку инфраструктуры.

Это не про производительность, а про модель проектирования. Go уводит больше в стандартную библиотеку, Node.js — в экосистему пакетов.

Со временем это даёт накопительный эффект: больше зависимостей → больше конфликтов версий → больше времени на обновления и разбор несовместимостей.

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

Node.js оптимизирует гибкость. Go — ограничение вариантов. Эти подходы равнозначны, но дают разную операционную нагрузку в долгую.

👉 @BackendPortal

TypeScript официально отказывается от JavaScript. Грядущая версия (7.0) полностью переписана на Go, и скорость компиляции выросла в 10 раз.

Годами основной компилятор (tsc) был написан на самом TypeScript и выполнялся в среде Node.js. С точки зрения стратегии это было отличным решением для привлечения разработчиков, но с инженерной стороны — серьёзная проблема для крупных проектов. JavaScript по своей природе однопоточный и сильно ограничен в задачах с интенсивной нагрузкой на процессор.

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

Переход на Go (нативный порт) полностью устраняет эту проблему. Ключевой момент — многопоточность.
Компилятор теперь использует все ядра процессора через горутины. Большой код разбивается на части и анализируется параллельно. Накладные расходы V8 больше не участвуют в процессе.

Эффект не только в удобстве разработки. В корпоративной среде это означает более быстрые пайплайны CI/CD на серверах и заметное снижение затрат на облачные сборки.

👉 @BackendPortal

emailflare

Самостоятельно хостируемая платформа для отправки email на базе Cloudflare Email Sending: REST API + админка + шаблоны + управление доменами — всё в одном контейнере.

EmailFlare — лёгкая self-hosted платформа для отправки почты, использует Cloudflare Email Sending для исходящих писем и SQLite как хранилище.
Бэкенд — API на Hono, фронтенд — админка на React с поддержкой шаблонов и управлением доменами; всё упаковано в один Docker-образ.

Деплой: one-click на Railway или локальный запуск через Docker Compose.

👉 @BackendPortal

Минимальный набор знаний о concurrency, который нужен каждому разработчику 👆

Все знания о конкурентности, которые у вас есть, наверняка получены из множества разных источников.

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

👉 @BackendPortal

«UUIDv7 везде» начинает звучать как новый дефолт.

Скепсис оправдан.

UUIDv7 действительно решает проблему БД. UUIDv4 случайный, вставки разлетаются по B-дереву, появляются page split’ы, cache miss’ы, write amplification и деградация скорости по мере роста таблицы.

UUIDv7 упорядочен по времени. Новые записи ложатся в хвост индекса, вставки становятся предсказуемыми.

Но вместе с этим идентификатор начинает нести таймстамп. Это не даёт прямого перебора будущих ID, но раскрывает метаданные: примерное время создания, порядок событий, окна активности, пики трафика, паттерны нагрузки.

Для внутренних систем это обычно ок. Для публичных API, инвойсов, заказов, пользовательских URL и чувствительных ресурсов — уже вопрос.

Практическое правило:

- BIGINT — когда генерация централизована в одной БД
- UUIDv4 или NanoID — когда ID публичный и должен оставаться непрозрачным
- UUIDv7 / ULID / KSUID — когда важны порядок и распределённая генерация

Частый паттерн в SaaS:

internal_id BIGINT PRIMARY KEY
public_id UUIDv4 UNIQUE

Один идентификатор под перформанс БД, второй — под безопасность и внешние контракты.

UUIDv7 — полезный инструмент, но универсальный дефолт превращает архитектурное решение в автопилот.

👉 @BackendPortal

В Postgres 18 появилась поддержка аутентификации пользователей через OAUTH 2.0

👉 @BackendPortal

Чувак собрал HTTP-прокси для отладки, который работает прямо в терминале.

Представляю httpmon — терминальный интерфейс для мониторинга HTTP с возможностями:

- фильтрация в стиле vim
- скрипты-интерсепторы на JavaScript
- отладка запросов gRPC-Web
- экспорт HAR
- сервер MCP для доступа ИИ-моделей к перехваченному трафику

https://httpmon.dev/

👉 @BackendPortal

POST не идемпотентен.
PUT — идемпотентен.
PATCH — зависит от реализации.

Ошибка в этих свойствах ломает ретраи.

Идемпотентность означает: один и тот же запрос даёт один и тот же результат.

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

GET — идемпотентен.
PUT — идемпотентен.
DELETE — идемпотентен.
POST — не идемпотентен.
PATCH — зависит (инкремент vs установка значения).

Для неидемпотентных эндпоинтов используют идемпотентные ключи:
клиент отправляет уникальный ключ,
сервер сохраняет ключ и ответ,
повтор с тем же ключом возвращает тот же результат.

Так устроены платёжные системы.
Без этого ретраи превращаются в дублирование операций.

👉 @BackendPortal

🎓 Бесплатный ИИ-сервис, который собирает полноценный курс по любой теме за пару минут.

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

У каждой статьи — свой чат и контекст, чтобы вопросы не смешивались. Прогресс сохраняется.

По сути, это ИИ-репетитор, который ведет по теме от начала до конца, подробно отвечая на любые вопросы.

✅ Курсы создаются бесплатно, без лимитов и без подписки.
➡️ Попробовать можно тут — gurufy.ru

Каждый младший бэкенд-разработчик, которого я собеседую, спотыкается об один и тот же вопрос по Postgres.

«В чём разница между кластеризованным и некластеризованным индексом?»

Интересный момент:
в Postgres на самом деле нет «кластеризованных индексов» в том смысле, как это реализовано в SQL Server.

В Postgres индексы — это отдельные структуры данных, которые указывают обратно на строки в heap (куче).

Но есть команда CLUSTER.

Она физически переупорядочивает таблицу на диске в соответствии с порядком индекса.
Один раз выполняется. Автоматически не поддерживается. В основном полезно в аналитических нагрузках.

Но обычно это не то, что проверяет интервьюер.

На самом деле хотят понять:

- понимаешь ли ты, что такое индекс
- для каких запросов он помогает
- и для каких не работает

Многие заучивают ответы про базы данных.
Очень немногие могут объяснить B-tree человеку без инженерного бэкграунда.

Эта разница и проявляется на собеседованиях.

Не стоит изучать факты про базы данных изолированно.

Сделай что-то.
Запусти EXPLAIN.
Посмотри, как запросы ведут себя с индексами и без них.

Такое понимание закрепляется.

👉 @BackendPortal

На Stepik вышел курс Вайбкодинг Telegram ботов, Сайтов и Mini Apps с Claude | Гайд

32 урока — и ты знаешь все, что нужно для создания реальных проектов через ИИ.
📶 Научишься:

— Создавать Telegram-ботов с UI, базой данных и рассылками
— Строить лендинги и сайты-визитки без знания вёрстки
— Собирать полноценные Mini Apps (frontend + backend) прямо в Telegram
— Деплоить проект на сервер за 20 минут — и он работает 24/7
— Монетизировать ботов: подписки, платный функционал, ограничения доступа
— Связывать бот + сайт + Mini App + AI в единую систему

Бонусом — детальная инструкция по получению Claude Opus 4.6/4.7 на безлимитное количество токенов, лучшей модели для кодинга на рынке прямо сейчас.
К концу курса у тебя будет живой продукт, который можно использовать как портфолио или сразу запускать в работу.

✔️ Действует скидка 35% в течении 48 часов

Разработчик собрал хардкорный, но при этом практичный фулстек-шаблон на базе Cloudflare + Next.js: fullstack-next-cloudflare. Подходит для быстрого старта проектов и мгновенного входа в разработку.

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

Ключевые возможности:

- Next.js 15 + React Server Components — современная модель разработки для более удобного DX;
- Cloudflare D1 edge-база данных + R2 object storage — глобальный доступ с низкой задержкой;
- Better Auth + Google OAuth — готовая аутентификация пользователей из коробки;
- Cloudflare Workers AI — прямые вызовы open-source моделей для быстрой интеграции ИИ-функциональности;
- Полноценный CI/CD: preview-деплои, автоматические релизы и единый пайплайн;
- Сквозная типобезопасность на TypeScript — надёжная связка от базы данных до UI по всей цепочке.

Документация и девелоперские воркфлоу тоже проработаны достаточно глубоко. Хорошо подходит как для быстрого запуска MVP, так и для системного изучения фулстек-архитектуры внутри экосистемы Cloudflare.

👉 @BackendPortal

Только услышал, что Microsoft выкатили BOC.

Давно не следил за развитием языков программирования.

Все знают, что CSP (как в языке Go) явно передаёт указатели, а BOC — передаёт их неявно. Интересный момент в том, что традиционные акторы имеют одномерную топологию блокировок, а здесь получается двумерный ориентированный ациклический граф. За счёт этого гранулярность блокировок можно зажимать максимально тонко, теоретическая пропускная способность получается очень высокой.

Дальше возникает классический вопрос. С глобальной блокировкой интерпретатора в Python нормальная реализация BOC почти неизбежно упирается в копирование памяти. Когда BOC передаёт указатель из потока A в поток B, а внутри него лежат нативные структуры Python, без копирования это либо развалится, либо уйдёт в сегфолт.

Чтобы сделать удобный zero-copy переход указателей, вероятно придётся поднимать собственные примитивные структуры данных на куче на уровне C — классическая логика из эпохи межъязыкового интерфейса.

Про совместимость с Python 3.13 тоже вопрос открытый.

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

👉 @BackendPortal