Backend Portal | Программирование

12 концепций Backend-разработки, которые нужно знать каждому разработчику 1. Клиент–сервер. Понимай, как запрос проходит от клиента к серверу и обратно. Это основа любого веб-приложения. 2. API. Изучи, как системы взаимодействуют друг с другом. HTTP-методы, коды состояния, валидация, обработка ошибок и версионирование API. 3. Базы данных. Научись проектировать структуры данных, хранить и извлекать информацию. Разберись в SQL, индексах, транзакциях, уровнях изоляции и в том, почему неэффективные запросы замедляют приложение. 4. Состояние и сессии. Понимай, где хранится состояние приложения, как сохраняется авторизация пользователя между запросами и почему управление состоянием усложняется при работе нескольких серверов. 5. Конкурентность. Несколько запросов могут одновременно изменять одни и те же данные. Изучи гонки данных, блокировки и уровни изоляции, чтобы конкурентные операции работали корректно. 6. Асинхронная обработка. Некоторые задачи не должны задерживать ответ пользователю. Очереди, фоновые обработчики, повторные попытки и идемпотентность помогают надёжно выполнять задачи за пределами основного цикла обработки запроса. 7. Проектирование систем. Разберись, как компоненты приложения взаимодействуют друг с другом. Кэширование, балансировка нагрузки, репликация, партиционирование и разделение сервисов — архитектурные решения, которые зависят от требований и компромиссов. 8. Безопасность. Аутентификация отвечает на вопрос, кто ты. Авторизация определяет, что тебе разрешено делать. Также важны валидация входных данных, контроль доступа, управление секретами и защита от распространённых уязвимостей. 9. Тестирование. Модульные тесты проверяют отдельные компоненты, интеграционные — их взаимодействие, а E2E-тесты — целые пользовательские сценарии. Все три типа помогают находить регрессии до выхода в production. 10. Производительность. Измеряй задержки, пропускную способность и потребление ресурсов. Профилируй приложение перед оптимизацией, ищи узкие места и помни: ускорение запроса к базе данных не всегда означает ускорение всего приложения. 11. Наблюдаемость. Логи показывают события, метрики помогают выявлять закономерности, а трейсы позволяют отслеживать запросы между сервисами. Вместе они помогают расследовать сбои, которые не удаётся воспроизвести локально. 12. Надёжность. В production-системах неизбежно возникают сбои. Предусматривай тайм-ауты, частичные отказы, повторные попытки, graceful degradation и механизмы восстановления. Оценивай надёжность с помощью SLO, а не предположений. Изучай эти концепции, создавай реальные системы и учись понимать компромиссы, стоящие за архитектурными решениями. 👉 @BackendPortal

Дорожная карта Backend-разработчика (1/11): проектирование API API — основа любого современного приложения. Неправильно выбранный подход может привести к проблемам с производительностью, сложностям при масштабировании и неудобству разработки. В этой части разберём три популярных подхода к проектированию API: • REST — простой и stateless-подход, использующий HTTP-методы. Стандартный выбор для публичных API. • GraphQL — клиент запрашивает только те данные, которые ему нужны. Это помогает избежать избыточной загрузки данных и дополнительных запросов за недостающей информацией. • gRPC — бинарный формат передачи данных и HTTP/2 обеспечивают высокую производительность. Подходит для высоконагруженных микросервисов. Главный навык — не просто знать все три технологии, а понимать, когда какую использовать: REST → публичные API, простые CRUD-операции, удобное кэширование. GraphQL → сложные запросы и приложения с разными клиентами, например вебом и мобильными устройствами. gRPC → взаимодействие внутренних сервисов, потоковая передача данных в реальном времени и низкие задержки. Не ограничивайтесь заучиванием определений — разбирайтесь в компромиссах каждого подхода и выбирайте инструмент под конкретную задачу. 👉 @BackendPortal

Как работает интернет: практический гайд для начинающих Full-Stack-разработчиков Когда интернет работает, всё кажется магией: вводишь URL, нажимаешь Enter — и через пару секунд перед тобой готовая страница. Но за этим простым действием стоит целая цепочка систем: браузер, DNS, маршрутизаторы, серверы, базы данных и сетевые протоколы. Читать статью 👉 @BackendPortal

Приглашаем на Java Jam — бесплатный митап ЮMoney для бэкенд-разработчиков 🔥 ✅ 29 октября, четверг, 19:00 (мск) — приходите на митап в Санкт-Петербурге или смотрите трансляцию.  Спикеры из ЮMoney и Сбера выступят с докладами: 🟣 Один апгрейд — больше сотни сервисов: как мы обновляем Java-стек в компании Обсудим, как обновить Gradle, Spring Boot и Java в 120+ компонентах, не останавливая разработку. Расскажем, как выстраивали процессы на протяжении этого времени: от порядка действий и массовых патчей до взаимодействия с командами и решения трудностей, с которыми столкнулись во время последнего обновления. 🟣 Как я автоматизировал свой проект — и всё сломал Разберём, как выстроить автоматизацию в проекте с помощью ИИ и какие шишки можно набить на пути. Поговорим, как работает длинный контекст в моделях и как организовать работу с учётом этих особенностей. 🟣 Откатить нельзя оставить: мониторинг выкладки релиза на основе Sentry Ошибки случаются. Узнаем, какие из них появляются или возникают чаще после последнего релиза — и достаточно ли этого, чтобы принять решение об откате. Зарегистрируйтесь, чтобы принять участие. Все подробности — на сайте митапа Java Jam👈

CSRF ≠ XSS ≠ SQL-инъекция. Все три уязвимости безопасности, но механизмы атак у них разные CSRF — межсайтовая подделка запроса: Злоумышленник заставляет браузер авторизованного пользователя отправить запрос на действие, которого пользователь не собирался выполнять. XSS — межсайтовый скриптинг: Вредоносный JavaScript внедряется в страницу и выполняется в браузере другого пользователя в контексте сайта. SQL-инъекция: Пользовательские данные изменяют структуру SQL-запроса, позволяя злоумышленнику читать, изменять или удалять данные. Как защищаться: CSRF • Использовать CSRF-токены. • Настроить атрибут SameSite для cookies. • Проверять заголовки Origin/Referer для запросов, изменяющих состояние. XSS • Экранировать данные при выводе с учётом контекста: HTML, атрибуты, JavaScript. • Если пользовательский HTML разрешён — очищать его с помощью санитайзера. • Использовать строгую Content Security Policy (CSP) как дополнительный уровень защиты. • Не вставлять недоверенный HTML напрямую в страницу. SQL-инъекций • Использовать подготовленные выражения и параметризованные запросы. • Не подставлять пользовательский ввод в SQL через конкатенацию строк. • Проверять входные данные и ограничивать права учётной записи БД. Как запомнить: CSRF — нежелательный запрос от вашего браузера. XSS — чужой код в вашем браузере. SQL-инъекция — чужая логика в запросе к базе. 👉 @BackendPortal

ThreadPoolExecutor решает, переживёт ли ваша система резкий всплеск нагрузки. Многие сбои начинаются именно здесь 1. У ThreadPoolExecutor есть 4 ключевых компонента: • Core threads — минимальное количество потоков, поддерживаемых пулом. • Max threads — максимальное количество потоков. • Queue — очередь задач, ожидающих выполнения. • Rejection policy — политика обработки задач, которые пул больше не может принять. 2. Что чаще всего идёт не так: • Очередь не имеет ограничения по размеру. • Количество потоков настроено неправильно. • Отказы в приёме задач игнорируются. 3. Неограниченная очередь приводит к незаметному отказу системы: • Растёт время ожидания ответа. • Потоки надолго блокируются. • Увеличивается потребление памяти. • В итоге система постепенно перестаёт справляться с нагрузкой. 4. Максимальное количество потоков не спасёт ситуацию. Если зависимые сервисы отвечают медленно, увеличение числа потоков может лишь ускорить перегрузку системы. 5. Политика отказа — не опция, а необходимость. Она позволяет системе сообщить: «Я больше не могу принимать новые задачи». 6. Устойчивые системы умеют: • Применять обратное давление (backpressure), ограничивая поступление новых задач. • Быстро отказывать, если обработка невозможна (fail fast). • Быстро восстанавливаться после сбоев. Главное: управление параллелизмом помогает контролировать нагрузку, но не увеличивает реальные вычислительные ресурсы системы. 👉 @BackendPortal

Кэш ускоряет приложение, но неправильное кэширование убивает надёжность Разберём самые распространённые ошибки при работе с кэшем. ❌Кэшировать всё подряд → Устаревшие данные и несогласованность при чтении. ✅ Кэшируйте только часто используемые и относительно стабильные данные. ❌ Не задавать TTL → Данные никогда не устаревают, и пользователи могут бесконечно получать неактуальную информацию. ✅ Устанавливайте время жизни кэша (TTL). ❌ Обновлять кэш и базу данных без стратегии согласования → Частичный сбой может привести к расхождению данных. ✅ Используйте подходящие стратегии синхронизации, например write-through или write-behind, с учётом требований к согласованности. ❌ Использовать единственный экземпляр кэша без резервного сценария → Если кэш станет недоступен, приложение может перестать работать или перегрузить базу данных. ✅ Предусмотрите обработку сбоев и резервный сценарий чтения из БД. ❌ Не продумывать инвалидацию кэша → Классическая ситуация: в DEV всё работает, а в PROD начинаются проблемы. ✅ Заранее определите, когда и каким образом кэш должен обновляться или очищаться. Главное правило: кэш — это инструмент оптимизации производительности, а не источник истины. Храните основные данные в надёжном постоянном хранилище и продумывайте поведение кэша при сбоях. 👉 @BackendPortal

😱 👉 @BackendPortal

Gemini Pro Argon на 1.5 года по цене кофе? Gemini Pro на 18 месяцев можно купить за 6$ (480₽ вместо 30.000₽) - последние 2 дня акции от Jio! > 4.0 Argon топ для вайбкодеров > Nano Banana 2 PRO (картинки) > Видео генерация (видео, нарезки, мувики) > 5 ТБ облака в Google One 🔓Вот бесплатный VPN для работы Gemini и AI Работает акция еще 2 дня по такой цене, дальше будет официальная цена $360 за 18 месяцев Приобрести можно в Магазине с 20.000+ покупок и 2000+ отзывов (есть возвраты и замены).

Load Balancer vs API Gateway: в чём разница? Load Balancer (балансировщик нагрузки). Располагается перед серверами и распределяет входящий трафик между экземплярами приложения. Помогает избежать перегрузки и повышает доступность системы. Что умеет: • Распределять трафик. • Проверять работоспособность серверов (health checks). • Переключать трафик при сбоях (failover). • Поддерживать горизонтальное масштабирование. Чего обычно не делает: • Аутентификация и авторизация пользователей. • Ограничение частоты запросов (rate limiting). • Управление версиями API. • Преобразование запросов. API Gateway (шлюз API). Располагается перед API и микросервисами, выступая единой точкой входа для клиентов. Что умеет: • Аутентификация и проверка JWT-токенов. • Ограничение частоты запросов (rate limiting и throttling). • Маршрутизация запросов к нужным сервисам. • Управление версиями API. • Преобразование запросов и ответов. • Централизованное логирование и мониторинг. Чего не заменяет: Полноценное распределение нагрузки на уровне инфраструктуры, хотя некоторые API Gateway имеют встроенные возможности балансировки. Главное различие: • Load Balancer решает задачи распределения нагрузки и отказоустойчивости инфраструктуры. • API Gateway отвечает за управление доступом к API, маршрутизацию и контроль запросов. Как это выглядит в production: Client → API Gateway → Load Balancer → Microservices API Gateway проверяет доступ, ограничивает частоту запросов и выбирает маршрут. Load Balancer распределяет трафик между доступными экземплярами сервисов. Эти компоненты решают разные задачи и могут дополнять друг друга, помогая строить масштабируемые и отказоустойчивые системы. 👉 @BackendPortal

🔥 Открытый урок «Микросервисы на практике» Когда монолит становится сложно развивать, хочется разделить его на микросервисы, но вместе с этим появляются новые вопросы: где провести границы, как организовать взаимодействие сервисов и что делать, если один из них перестал отвечать. 29 октября в 19:00 МСК разберём, когда стоит переходить к микросервисам и как проектировать их с учётом сбоев и роста нагрузки. На уроке ты узнаешь: ➖ чем микросервисная архитектура отличается от монолита и когда переход оправдан ➖ какие проблемы возникают при взаимодействии микросервисов ➖ какие паттерны помогают сделать систему надёжнее и как применять идемпотентность На продакшен кейсе сервисов заказов и платежей разберём, как потерянный ответ приводит к двойному списанию и как от этого защититься. Урок проведёт Станислав Клоков, тимлид финтех-проекта с нагрузкой 100k RPS, который раньше разрабатывал ядро платформы микросервисов в Яндексе. 👉 Регистрируйся, чтобы разобраться в микросервисах на практическом примере

Асинхронный код НЕ делает ваш API быстрее Он меняет способ использования потоков, а не скорость выполнения самой работы. Что на самом деле означает «быстрее»? • Меньшая задержка (latency) — время обработки одного запроса. • Большая пропускная способность (throughput) — количество запросов, которые система обрабатывает за определённое время. Асинхронность помогает увеличить пропускную способность, но не обязательно уменьшает задержку отдельного запроса. Синхронная модель (блокирующая) → Поток ждёт ответа от базы данных, сети или файловой системы. → Пока идёт ожидание, поток занят, но не выполняет полезную работу. → При высокой нагрузке потоки в пуле могут закончиться. → Запросы начинают ждать своей очереди и могут завершаться по тайм-ауту. Асинхронная модель (неблокирующая) → Поток запускает операцию ввода-вывода и может заняться другими задачами. → Во время ожидания ответа поток не заблокирован этой операцией. → То же оборудование может обслуживать больше одновременных запросов. → Система лучше справляется со всплесками нагрузки. Важный нюанс, который часто упускают: Если узкое место — процессор (CPU), асинхронность сама по себе практически не поможет ускорить вычисления. Если узкое место — ввод-вывод (I/O), асинхронность может существенно повысить эффективность использования ресурсов. Как это реализовано в разных технологиях? • Spring MVC — традиционная модель с блокирующим вводом-выводом. • Spring WebFlux — поддерживает неблокирующую обработку запросов. • Node.js — использует событийный цикл (event loop) и асинхронные операции ввода-вывода. Главное: асинхронность — это инструмент масштабирования, а не магический способ ускорить код. 👉 @BackendPortal

Большинство разработчиков изучают Spring Boot, создавая CRUD API. Но для работы с backend в production этого далеко не достаточно. В шпаргалке по Spring Boot, в которой собраны ключевые концепции, которые должен знать каждый backend-разработчик. Что внутри: • Архитектура Spring Boot • Жизненный цикл HTTP-запроса • Структура проекта • Основные аннотации • Подходы к построению REST API • JPA и слой Repository • Валидация данных • Обработка исключений • JWT и Spring Security • HTTP-статусы • Команды Docker • Лучшие практики для production Главная ошибка начинающих. Они сосредотачиваются только на связке: Controller → Service → Repository Но упускают из виду: • Валидацию данных • Безопасность • Логирование • Транзакции • Мониторинг • Обработку ошибок • Масштабируемость Именно здесь начинается настоящая backend-разработка. Важный момент о производительности в production. Большинство проблем с производительностью вызваны не самим Spring Boot. Чаще всего узкие места находятся в других компонентах системы: • Медленные запросы к базе данных • Отсутствие необходимых индексов • Исчерпание пула соединений • Сериализация больших объёмов данных • Блокирующие внешние API • Проблемы N+1 при выполнении запросов к базе данных В каком порядке изучать Spring Boot. Начальный уровень: • REST API • Контроллеры • Внедрение зависимостей • CRUD API • Основы JPA Средний уровень: • Валидация • Обработка исключений • JWT и безопасность • Транзакции • Docker Продвинутый уровень: • Kafka • Redis • Микросервисы • Распределённая трассировка (Distributed Tracing) • Kubernetes • Событийно-ориентированная архитектура (Event-Driven Architecture) Мой любимый раздел — жизненный цикл запроса. Когда понимаешь, как запрос проходит через приложение, отлаживать ошибки становится гораздо проще: Клиент ↓ Tomcat ↓ DispatcherServlet ↓ Controller ↓ Service ↓ Repository ↓ База данных Совет от опытных инженеров. Не ограничивайся изучением синтаксиса. Разбирайся в том: • Почему системы выходят из строя. • Где возникают узкие места производительности. • Как работает масштабирование. • Как искать и устранять проблемы в production. Именно это отличает разработчиков, которые просто повторяют примеры из обучающих материалов, от настоящих backend-инженеров. 👉 @BackendPortal

Индексы не делают базу данных быстрее во всём. Они ускоряют конкретные запросы — и за это приходится платить. Как работает индекс? Индекс — отдельная структура данных, чаще всего B-Tree. Он хранит значения столбцов и ссылки на соответствующие строки таблицы. Вместо полного сканирования таблицы база данных может быстро найти нужные записи через индекс. Чтение ускоряется за счёт того, что приходится просматривать меньше данных. Что происходит при INSERT и UPDATE? • Запись добавляется или изменяется в таблице. • База данных находит нужную позицию в индексе. • Обновляются узлы индексной структуры. • При необходимости дерево перестраивается или балансируется. • Изменения фиксируются с использованием механизма журналирования, например WAL или redo log. Каждый дополнительный индекс увеличивает объём работы при записи данных. Стоимость операций: • Чтение по индексу — обычно (O(\log n)) для поиска в B-Tree. • Обновление индекса — обычно (O(\log n)) на одну изменяемую индексную структуру. Чем больше индексов нужно обновлять, тем выше нагрузка на запись. Однако это не означает, что 10 индексов автоматически замедляют запись ровно в 10 раз. Почему избыток индексов вредит системам с высокой нагрузкой на запись? • Повышенная нагрузка на CPU. • Дополнительные операции ввода-вывода. • Конкуренция за блокировки и другие ресурсы. • Более длительные транзакции и фиксация изменений. Поэтому в системах с интенсивной записью индексы проектируют особенно тщательно. Типичные ошибки при проектировании индексов • Создавать индекс для каждого столбца. • Индексировать поля с низкой кардинальностью без оценки их полезности. • Игнорировать порядок столбцов в составных индексах. • Не учитывать характер операций записи. Главное правило для production: проектируйте индексы исходя из реальных запросов и сценариев нагрузки, а не только из структуры таблиц. 👉 @BackendPortal

Steampipe: SQL-запросы к облачной инфраструктуре Какие ресурсы остались без обязательных тегов? Есть ли публично доступные S3-бакеты? В каких Kubernetes namespaces отсутствуют NetworkPolicies? Для ответа необязательно переключаться между консолями и писать отдельные скрипты. Steampipe — open-source инструмент, который позволяет запрашивать данные из AWS, Kubernetes и других сервисов с помощью SQL. Через плагины он обращается к API сервисов и представляет данные в виде таблиц. Можно фильтровать ресурсы, объединять результаты и проверять инфраструктуру привычными запросами. Полезен для инвентаризации, поиска ошибок конфигурации и разовых проверок безопасности. Руководство по Steampipe 👉 @BackendPortal

Большая коллекция из практических рекомендаций по защите приложений. Внутри: SQL Injection, XSS, JWT, OAuth2, Kubernetes, Docker, API Security, а теперь ещё и безопасность агентов MCP и RAG. https://cheatsheetseries.owasp.org 👉 @BackendPortal

Бесплатная база по работе с данными Книга создателя pandas с подробным разбором NumPy, pandas, очистки данных, визуализации и временных рядов. Весь материал сопровождается практическими примерами, исходники и датасеты доступны на GitHub. https://wesmckinney.com/book/ 👉 @BackendPortal

Партиционирование и шардинг: в чём разница? Оба подхода делят данные на части, но решают разные задачи. Партиционирование — разделение одной логической таблицы на секции. В типичном случае они находятся в одной СУБД и используют ресурсы одного сервера. Основные способы: • Range — по диапазонам, например заказы по годам. • List — по заданным значениям, например регионам US, EU и APAC. • Hash — по хешу ключа распределения. Если условия запроса позволяют, СУБД исключает ненужные секции из обработки — это называется partition pruning. Вместо всей таблицы читается только подходящая часть. Партиционирование упрощает обслуживание, загрузку и удаление старых данных. Но ускорение зависит от запросов и ключа разбиения: само по себе оно не делает любой запрос быстрее. Устройство индексов тоже зависит от СУБД: они могут быть локальными или глобальными. Шардинг — распределение данных между несколькими узлами или базами. Каждый шард использует собственные вычислительные ресурсы и хранилище. Например, клиентов распределяют по хешу customer_id. Приложение, прокси или сама распределённая СУБД определяет, куда отправить запрос. Если ключ шарда неизвестен, может потребоваться обращение к нескольким шардам. Шардинг позволяет распределить нагрузку и объём данных, но усложняет: • JOIN между шардами; • транзакции, затрагивающие несколько узлов; • перераспределение данных; • борьбу с перегруженными шардами; • маршрутизацию и эксплуатацию. Эти подходы можно сочетать: таблицы внутри каждого шарда тоже могут быть партиционированы. Обязательной цепочки «одна БД → партиции → реплики → шардинг» нет. Решение выбирают по узкому месту: объёму данных, нагрузке на чтение и запись, требованиям к задержкам и обслуживанию. 👉 @BackendPortal

Вертикальное и горизонтальное масштабирование: в чём разница? Когда системе не хватает ресурсов, можно усилить существующий сервер или распределить нагрузку между несколькими. Вертикальное масштабирование — Scale Up. Добавляем ресурсы одной машине: CPU, RAM, более быстрые диски. Например, переходим с 4 ядер на 32. Это позволяет обрабатывать больше работы на одном узле и обычно требует меньше изменений в архитектуре. Но результат зависит от узкого места: дополнительные ядра не ускорят код, который не умеет их использовать. Ограничения: предел оборудования, стоимость мощных серверов и возможный простой при обновлении. Единственный сервер также остаётся точкой отказа. Горизонтальное масштабирование — Scale Out. Добавляем экземпляры приложения или узлы и распределяем работу между ними. Так можно увеличить пропускную способность, гибко менять количество ресурсов и повысить отказоустойчивость. Но дополнительные серверы сами по себе не гарантируют доступность: нужны проверки состояния, переключение при сбоях и достаточный запас мощности. Что приходится продумывать: • Распределение запросов или задач. • Хранение сессий и общего состояния. • Согласованность данных и кэшей. • Безопасные повторные запросы и идемпотентность. • Ограничения БД и других зависимостей. Stateful-системы тоже масштабируются горизонтально, но требуют механизмов репликации, разделения данных и координации. Реплики БД обычно помогают с чтением, а масштабирование записи требует отдельных решений. Универсальной последовательности «мощнее сервер → реплики → шардинг» нет. Выбирайте подход по измеренному узкому месту, бюджету и требованиям к доступности — часто оба способа используются вместе. 👉 @BackendPortal

AI Agent, Workflow и Chatbot: в чём разница? Не каждое приложение с ИИ — агент. Одни отвечают на сообщения, другие выполняют заданный процесс, третьи сами выбирают следующий шаг для достижения цели. Chatbot — общается с пользователем. Отвечает на вопросы, используя инструкции, контекст и доступные данные. Например, на вопрос «Где мой заказ?» получает статус из бэкенда и объясняет его клиенту. Подходит для FAQ, поддержки и поиска ответов в базе знаний. Workflow — выполняет заранее спроектированный процесс. Порядок действий, условия и ветвления задаёт разработчик. ИИ может участвовать в отдельных шагах: например, классифицировать обращение или подготовить письмо. Пример: проверить заказ, уточнить наличие товара, обработать оплату и отправить подтверждение. AI Agent — выбирает действия для достижения цели. Получает задачу, использует инструменты, оценивает результат и решает, что делать дальше в пределах заданных правил. Например, на просьбу «Выясни, почему задерживается заказ» агент проверяет доставку, остатки и данные перевозчика. Чувствительные действия выполняет с необходимым подтверждением. Эти подходы можно объединять. Чатбот принимает запрос на подбор перелёта, агент исследует варианты, а workflow оформляет одобренную бронь. Чатбот описывает интерфейс общения; workflow и агент — способы организации работы. Для предсказуемой задачи workflow часто проще тестировать и контролировать. Агент полезен там, где следующий шаг зависит от полученных результатов. 👉 @BackendPortal