📎 Смотрите записи докладов с Backend Talks от Яндекс 360

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

➕ Направленный ациклический граф в PostgreSQL: как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей. Малик Минубаев, разработчик в B2B-платформе, рассказал, почему стандартные паттерны хранения иерархий не работают для ориентированного ациклического графа. А также сравнил несколько вариантов Closure Table с бенчмарками на реальной нагрузке

➕ Как Яндекс Диск выдерживает сотни гигабит входящего трафика: устройство балансировки загрузок. Илья Абрамов, разработчик в Диске, разобрал, почему нам не подошёл подход «как у всех», и показал эволюцию алгоритма балансировки загрузок: от наивного Round-Robin до разработки собственного алгоритма

➕ Как формировать технологический стек и не погибнуть в священных войнах: от хаоса к процессам и техрадару. Дмитрий Сафонов, руководитель команды разработки платформы микросервисов, рассказал, как строить стек для промышленной разработки и разрешать споры о технологиях. А также поделился опытом внедрения Техрадара в Яндекс 360

➕ Зачем и как бэкендеру расти в карьере в 2026 году. Дмитрий Соломонов, руководитель группы B2B-разработки бэкенда Диска, рассказал, как развивать команду с помощью индивидуальных планов и выбора узкой специализации для разных уровней разработчиков. И поделился, как связать получение знаний с реальными задачами

➕ Семь раз подумай, один раз пошардируй: как мы начали горизонтально масштабировать метаданные чатов Телемоста. Никита Звонарев, разработчик в Мессенджере, рассказал, что может предпринять команда, когда вертикально масштабироваться уже не получается, а сервису нужно функционировать дальше в условиях возрастающей нагрузки, и как при этом не устроить себе проблемы в будущем

🎤 Плейлист доступен на YouTube и в VK Видео

Один учёный из Дании решил автоматизировать отклики на вакансии через Claude Code. А потом выложил весь проект в open source.

Его зовут Mads Lorentzen. Он PhD-геофизик, а не основатель стартапа. Сделал инструмент для себя и опубликовал его под лицензией MIT.

Как это работает:

Шаг 1
Агент читает вакансию и оценивает, насколько кандидат ей соответствует.
Шаг 2
Создаёт адаптированное CV в LaTeX, оставляя только релевантный опыт.
Шаг 3
Пишет сопроводительное письмо под конкретную позицию.
Шаг 4
Второй AI-агент проводит ревью результата, находит слабые места, после чего первый агент вносит правки.
Шаг 5

Система собирает CV и cover letter в готовые PDF-файлы. Самое интересное не в автоматизации, а в устройстве проекта.

Вся логика хранится в обычных markdown-файлах:
• профиль кандидата
• правила написания текстов
• шаблоны CV
• заметки для подготовки к интервью
• инструкции для агентов

Никакой магии. Всё можно открыть, прочитать и изменить под себя.
Поиск вакансий из коробки заточен под датские job boards, но сам workflow подходит для любой страны.
На момент публикации:
• 489 звёзд
• 270 форков

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

https://github.com/MadsLorentzen/ai-job-search

👉 @BackendPortal

Разработчик пишет такой код для обработки 1000 пользовательских записей:

const users = await db.getAll();

await Promise.all(
  users.map(user => sendEmail(user))
);

console.log('Done');

С 10 пользователями в среде разработки всё работает нормально.

Что произойдёт в продакшене с 1000 пользователями?

A) Всё отработает идеально
Promise.all сам управляет конкурентностью

B) Сработает rate limit почтового сервиса
сотни писем тихо не отправятся

C) Серверу не хватит памяти
1000 одновременно запущенных промисов уронят Node.js

D) И B, и C
проблемы с rate limit и памятью
в зависимости от ограничений почтового сервиса

Какой вариант правильный и как это исправить?

Promise.all() не ограничивает конкурентность.
Node попытается отправить все 1000 писем одновременно.

В зависимости от инфраструктуры вы получите:
• rate limit от почтового провайдера
• таймауты и ретраи
• резкий рост потребления памяти
• падение производительности процесса

Поэтому правильный ответ обычно не B и не C.
Правильный ответ: D.

Promise.all() не является очередью задач.
Для больших объёмов используют ограничение конкурентности:

const limit = pLimit(10);

await Promise.all(
  users.map(user =>
    limit(() => sendEmail(user))
  )
);

👉 @BackendPortal

Tail Call Optimization (TCO) — это оптимизация, которая позволяет не создавать новый стековый кадр (stack frame) для вызова функции, если вызывающая функция просто возвращает результат этой функции.
Чаще всего это встречается при хвостовой рекурсии (tail recursion).
Допустим, у вас есть рекурсивная функция:

const recur = (args) => {
    doSomething(args);
    return recur();
}

Представим, что программа начинает работу с первого вызова recur(). Назовём его Call 1.
Внутри Call 1 происходит ещё один вызов recur(). Назовём его Call 2.
При любом вызове функции компилятор или интерпретатор создаёт стековый кадр для хранения данных текущего вызова.

Стековый кадр нужен для того, чтобы сохранить состояние Call 1 на случай, если после возврата из Call 2 ему ещё понадобится выполнить какую-то работу.
Но каждый новый стековый кадр занимает память и увеличивает размер стека.

Если все рекурсивные вызовы имеют вид:

return recur();

то после завершения Call 2 у Call 1 больше нет никакой работы. Он просто сразу возвращает полученный результат.

Получается, что хранить данные Call 1 в отдельном стековом кадре бессмысленно.
Современные компиляторы могут воспользоваться этим. Вместо создания нового стекового кадра они переиспользуют текущий и заменяют данные Call 1 данными Call 2.

В результате новые кадры стека не создаются, а потребление памяти остаётся постоянным:

O(1)

вместо обычного:

O(n)

для рекурсии.

Важно понимать, что поддержка Tail Call Optimization не гарантируется большинством языков программирования.
Одним из немногих исключений является язык Scheme, где оптимизация хвостовых вызовов является обязательной частью спецификации языка. Поэтому в Scheme хвостовая рекурсия считается полноценной заменой циклам и может выполняться без риска переполнения стека.

👉 @BackendPortal

Open NotebookLM — бесплатная open-source альтернатива NotebookLM.
Генерирует подкасты и позволяет общаться со своими документами через чат.

https://github.com/lfnovo/open-notebook

👉 @BackendPortal

API Design Complete Roadmap
|
| | |-- Fundamentals
| |-- Introduction to APIs
| | |-- What is an API
| | |-- API architecture basics
| | |-- Client-server communication
| |-- Types of APIs
| | |-- REST APIs
| | |-- GraphQL APIs
| | |-- SOAP APIs
| | |-- gRPC APIs
| |-- HTTP Fundamentals
| | |-- Requests and responses
| | |-- HTTP methods
| | |-- Status codes

| | |-- REST API Design
| |-- Resource-Based Design
| | |-- Nouns over verbs
| | |-- Resource naming conventions
| |-- CRUD Operations
| | |-- GET
| | |-- POST
| | |-- PUT/PATCH
| | |-- DELETE
| |-- URI Design
| | |-- Clean URLs
| | |-- Nested resources

| | |-- Request & Response Design
| |-- JSON Best Practices
| | |-- Consistent structures
| | |-- Error responses
| |-- Data Validation
| | |-- Input validation
| | |-- Output formatting
| |-- Pagination
| | |-- Offset pagination
| | |-- Cursor pagination

| | |-- Authentication & Authorization
| |-- API Keys
| |-- JWT Authentication
| |-- OAuth 2.0
| |-- Role-Based Access Control (RBAC)
| |-- Permission Management

| | |-- API Security
| |-- HTTPS
| |-- Rate Limiting
| |-- CORS
| |-- Input Sanitization
| |-- Preventing API Abuse
| |-- Secure Secret Management

| | |-- API Documentation
| |-- OpenAPI Specification
| |-- Swagger UI
| |-- API Reference Docs
| |-- Request Examples
| |-- SDK Documentation

| | |-- API Versioning
| |-- URL Versioning
| |-- Header Versioning
| |-- Semantic Versioning
| |-- Backward Compatibility

| | |-- Performance Optimization
| |-- Caching Strategies
| | |-- Browser caching
| | |-- Server-side caching
| |-- Compression
| |-- Query Optimization
| |-- Response Time Monitoring

| | |-- Advanced API Patterns
| |-- GraphQL Fundamentals
| |-- gRPC Services
| |-- WebSockets
| |-- Event-Driven APIs
| |-- API Gateway Pattern
| |-- Microservices Communication

| | |-- Testing APIs
| |-- Unit Testing
| |-- Integration Testing
| |-- End-to-End Testing
| |-- Postman Testing
| |-- Automated API Testing

| | |-- Monitoring & Observability
| |-- Logging
| |-- Metrics Collection
| |-- Distributed Tracing
| |-- Error Tracking
| |-- API Analytics

| | |-- Deployment & Scalability
| |-- Docker for APIs
| |-- Kubernetes Basics
| |-- Load Balancing
| |-- Horizontal Scaling
| |-- CI/CD for APIs

| | |-- Real World Projects
| |-- Design a RESTful Blog API
| |-- Build an E-commerce API
| |-- Create a Chat Application API
| |-- Develop a Payment Gateway API
| |-- Build a URL Shortener API
| |-- Design a Social Media API

| | |-- Interview Preparation
| |-- REST API Interview Questions
| |-- Authentication Scenarios
| |-- API Security Challenges
| |-- System Design for APIs
| |-- Performance Optimization Questions

| | |-- Community and Growth
| |-- Build Public API Projects
| |-- Publish APIs on GitHub
| |-- Write API Design Articles
| |-- Contribute to Open Source
| |-- Stay Updated with API Standards

👉 @BackendPortal

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

Спустя почти 20 лет его проектом пользуются около 3 миллионов человек из 236 стран каждые два месяца.

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

Calibre бесплатный, open-source и распространяется под GPL-3.0. Работает на Windows, macOS и Linux.

Что умеет:

• читает почти любой формат электронных книг: EPUB, MOBI, AZW, AZW3, KFX, PDF, CBR, CBZ, DOCX, TXT и другие;
• конвертирует книги между форматами в пару кликов;
• редактирует метаданные, обложки и теги;
• управляет библиотеками на тысячи книг;
• отправляет книги напрямую на Kindle, Kobo, Tolino, телефон или планшет;
• умеет поднимать локальный сервер, чтобы читать свою библиотеку через браузер.

Сейчас у проекта почти 25 тысяч звёзд на GitHub и около 2.9 миллиона активных установок за последние 60 дней.

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

Настоящая цифровая библиотека выглядит именно так: книги принадлежат тебе, а не экосистеме устройства.

https://github.com/janeczku/calibre-web

👉 @BackendPortal

Это тот самый гайд, который мне хотелось бы получить в первый день изучения Computer Science.
В нём шаг за шагом объясняется, начиная с одного транзистора, почему компьютер большую часть времени не занимается вычислениями, а просто ждёт данные из памяти. По сути, он гораздо меньше похож на калькулятор, чем кажется.

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

Если вы до сих пор не разобрались, что такое memory wall, то упускаете один из самых сильных моментов «озарения» во всей компьютерной науке.

Автору потребовалось больше 20 дней глубокого ресёрча и много работы, чтобы изложить это максимально просто.
Вот статья: https://abhisheklearn12.github.io/blogs/memory.html

👉 @BackendPortal

Хотите понять, как подключить LLM к реальным рабочим процессам, а не просто гонять промпты в чате?
В этом курсе Ania Kubów показывает, как собрать и задеплоить AI-агента для Slack с нуля.

По ходу курса вы:
• Поднимете Slack-бота на базе GPT-4.
• Настроите Node.js, Express и Slack Bolt.
• Подключите PostgreSQL для хранения данных.
• Развернёте проект через Render.
• Научите агента искать и привлекать новых участников сообщества.
Получается не очередной демо-чатбот, а полноценный агент, встроенный в рабочий процесс команды.

Курс: Build Your Own AI Agent with Node.js and Slack

👉 @BackendPortal