15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Тема: Стратегии кеширования — Cache-Aside, Write-Through и Write-Back
Как снизить нагрузку на базу данных и ускорить работу приложения? Кеширование позволяет хранить часто запрашиваемые данные в более быстром хранилище, обычно в оперативной памяти, чтобы повторные запросы не обращались каждый раз к базе данных.
1. Cache-Aside (ленивая загрузка)
Как работает:
• Приложение проверяет наличие данных в кеше.
• Если данные найдены, возвращает их.
• Если данных нет, загружает их из базы данных.
• Сохраняет результат в кеше и возвращает его.
Пример: при первом запросе страница товара загружает информацию из базы данных, а при последующих — получает её из Redis.
Лучше всего подходит: для приложений с преобладанием операций чтения, где не все данные запрашиваются регулярно.
Компромисс: первый запрос выполняется медленнее, а закешированные данные могут устареть.
2. Write-Through (сквозная запись)
Как работает:
• Приложение записывает данные в кеш.
• В рамках операции записи кеш обновляет базу данных.
• Запись считается успешной в соответствии с правилами согласованности данных и обработки ошибок в системе.
Пример: при обновлении профиля пользователя одновременно обновляются кеш и база данных.
Лучше всего подходит: для приложений, которым важно, чтобы недавно записанные данные сразу были доступны в кеше.
Компромисс: операции записи могут выполняться медленнее, поскольку необходимо обновить и кеш, и базу данных.
3. Write-Back (отложенная запись)
Как работает:
• Приложение записывает данные в кеш.
• Кеш подтверждает успешную запись.
• База данных обновляется позже асинхронно.
Пример: сохранение часто изменяющихся счётчиков или метрик в кеше с последующей периодической записью изменений в постоянное хранилище.
Лучше всего подходит: для сценариев с большим количеством операций записи, где важна минимальная задержка.
Компромисс: данные могут быть потеряны, если кеш выйдет из строя до того, как ожидающие записи попадут в надёжное хранилище. Для надёжной реализации нужны механизмы вроде персистентности, очередей или журналов записи.
4. Краткое сравнение
Cache-Aside: кеш загружает данные по мере необходимости.
Write-Through: кеш и база данных обновляются в рамках одной операции записи.
Write-Back: кеш сначала принимает запись, а база данных обновляется позже.
5. Популярные вопросы на собеседованиях
• Что происходит, когда закешированные данные устаревают?
• Как инвалидировать записи в кеше или настроить время их жизни?
• Что произойдёт, если Redis выйдет из строя? Как предотвратить Cache Stampede (одновременную массовую загрузку одних и тех же данных)?
• Как обрабатывать конкурентные обновления?
Главный вывод для FAANG-собеседований
Кеширование — это не только ускорение работы приложения. Это поиск баланса между задержками, нагрузкой на базу данных, согласованностью и надёжностью.
Выбирайте стратегию с учётом соотношения операций чтения и записи, а также того, насколько допустимы устаревшие или потерянные данные.
👉 @BackendPortal
Каждый младший бэкенд-разработчик, которого я собеседую, спотыкается об один и тот же вопрос по Postgres.
«В чём разница между кластеризованным и некластеризованным индексом?»
Интересный момент:
в Postgres на самом деле нет «кластеризованных индексов» в том смысле, как это реализовано в SQL Server.
В Postgres индексы — это отдельные структуры данных, которые указывают обратно на строки в heap (куче).
Но есть команда CLUSTER.
Она физически переупорядочивает таблицу на диске в соответствии с порядком индекса.
Один раз выполняется. Автоматически не поддерживается. В основном полезно в аналитических нагрузках.
Но обычно это не то, что проверяет интервьюер.
На самом деле хотят понять:
- понимаешь ли ты, что такое индекс
- для каких запросов он помогает
- и для каких не работает
Многие заучивают ответы про базы данных.
Очень немногие могут объяснить B-tree человеку без инженерного бэкграунда.
Эта разница и проявляется на собеседованиях.
Не стоит изучать факты про базы данных изолированно.
Сделай что-то.
Запусти EXPLAIN.
Посмотри, как запросы ведут себя с индексами и без них.
Такое понимание закрепляется.
👉 @BackendPortal
DevOps-инструмент недели: Kubeshark
Логи Kubernetes могут показать, какой сервис завершился с ошибкой, но не всегда объясняют, что именно происходило при взаимодействии между сервисами.
Чтобы разобраться, приходится переключаться между логами подов и трассировками. Здесь помогает Kubeshark — своего рода Wireshark для Kubernetes.
Это open-source инструмент, который перехватывает сетевой трафик всего кластера с помощью eBPF и отображает его с учётом контекста Kubernetes.
Что умеет Kubeshark:
• Показывает API-запросы и ответы между сервисами.
• Поддерживает HTTP, gRPC, GraphQL, Redis, Kafka, DNS и другие протоколы.
• Расшифровывает TLS-трафик с помощью eBPF без использования sidecar-контейнеров и прокси.
• Позволяет фильтровать трафик по Pod, namespace, node, IP и параметрам API.
• Визуализирует взаимодействие сервисов и сохраняет снимки трафика в формате PCAP.
• Предоставляет данные о сетевом трафике через MCP для AI-инструментов, например Claude.
https://github.com/kubeshark/kubeshark
👉 @BackendPortal
7 основных временных сложностей Big O, которые нужно знать перед собеседованием по программированию.
Понимание Big O необходимо для решения задач по DSA (структурам данных и алгоритмам) и написания эффективного кода.
Вот 7 временных сложностей, которые должен знать каждый разработчик:
O(1) — константная: доступ к элементу массива по индексу.
O(log n) — логарифмическая: бинарный поиск.
O(n) — линейная: перебор массива.
O(n log n) — линейно-логарифмическая: сортировка слиянием (Merge Sort).
O(n²) — квадратичная: вложенные циклы, пузырьковая сортировка (Bubble Sort).
O(2ⁿ) — экспоненциальная: генерация всех подмножеств.
O(n!) — факториальная: генерация всех перестановок.
Как запомнить:O(1) — размер входных данных не влияет на время выполнения.O(log n) — размер задачи уменьшается на каждом шаге.O(n) — объём работы растёт пропорционально размеру входных данных.O(n log n) — линейная работа на каждом из логарифмических уровней.O(n²) — каждый элемент может сравниваться с каждым другим.O(2ⁿ) — каждый элемент создаёт два возможных варианта выбора.O(n!) — количество возможных комбинаций быстро растёт с увеличением входных данных.
Совет для собеседования: не ограничивайтесь заучиванием сложностей. Учитесь определять их по циклам, рекурсии, алгоритмам сортировки и используемым структурам данных.
Сохраните эту шпаргалку для повторения DSA перед собеседованием.
👉 @BackendPortal
Что такое Low-Level Design (LLD)?
Low-Level Design — это низкоуровневое проектирование, которое определяет, как устроены отдельные компоненты программной системы и как они взаимодействуют друг с другом.
LLD охватывает классы, объекты, интерфейсы, методы, связи между ними и логику их взаимодействия.
Пример: система управления парковкой (Parking Lot System) Прежде чем писать код, нужно определить:
• Какие классы нам понадобятся?
• Как представить парковочные места и транспортные средства?
• Как система будет назначать автомобилю парковочное место?
• Как рассчитывать стоимость парковки?
• Как поддержать разные типы транспортных средств?
Все эти решения относятся к LLD. HLD vs LLD: в чём разница?
High-Level Design (HLD) — высокоуровневое проектирование, которое описывает общую архитектуру системы. Например: сервисы, базы данных, балансировщики нагрузки, API и взаимодействие между компонентами.
Low-Level Design (LLD) — низкоуровневое проектирование, которое описывает внутреннюю реализацию компонентов. Например: классы, интерфейсы, методы, связи между объектами и паттерны проектирования.
Проще говоря:
• HLD определяет, какие компоненты нужны системе.
• LLD определяет, как эти компоненты устроены и взаимодействуют внутри.
Что оценивают на техническом собеседовании?
• Знание основ ООП.
• Грамотное проектирование классов и интерфейсов.
• Понимание принципов SOLID.
• Уместное применение паттернов проектирования.
• Расширяемость и удобство поддержки кода.
• Обработку граничных случаев и требований.
• Умение объяснять компромиссы и обосновывать решения.
Как подходить к LLD-собеседованию?
Шаг 1. Уточните требования. Определите основные функции, ограничения и граничные случаи.
Шаг 2. Выделите сущности. Найдите основные объекты, из которых будет состоять система. Например, для парковки: Vehicle, ParkingSpot, Ticket, ParkingFloor и ParkingLot.
Шаг 3. Определите связи. Решите, как объекты взаимодействуют друг с другом и за какие обязанности отвечает каждый из них.
Шаг 4. Спроектируйте интерфейсы и классы. Распределите ответственность между компонентами и определите необходимые методы.
Шаг 5. Примените принципы проектирования. Используйте SOLID и паттерны проектирования там, где они действительно решают проблему. Не нужно внедрять паттерны ради самих паттернов.
Шаг 6. Продумайте граничные случаи. Учтите отсутствие свободных ресурсов, некорректные операции, сбои и параллельные запросы.
Шаг 7. Объясните компромиссы. Расскажите, почему выбрали именно такую архитектуру и как её можно будет развивать в будущем.
Распространённая ошибка: Начинать писать код сразу, не разобравшись в требованиях. Хорошее LLD-проектирование начинается с понимания задачи, а не с создания как можно большего количества классов.
Главная мысль: хорошее LLD — это правильное распределение ответственности, управление зависимостями и создание программного обеспечения, которое можно изменять и расширять, не нарушая существующее поведение.
👉 @BackendPortal
18 практических работ по DevOps
Docker, Kubernetes, CI/CD, Terraform, Ansible, Helm, GitOps, мониторинг через Prometheus и Grafana, а также управление секретами и progressive delivery. Курс рассчитан на 16 недель.
В финале у вас будет не просто набор выполненных заданий, а собственный кластер с автоматизированным развёртыванием и мониторингом.
👉 @BackendPortal
Современные возможности Python, такие как структурное сопоставление с образцом (match/case) и lru_cache, позволяют избавиться от большого количества шаблонного кода.
👉 @BackendPortal
GitHub: от новичка до профи
Сохрани эту подборку как чек-лист для изучения GitHub и проходи каждый этап последовательно, шаг за шагом.
👉 @BackendPortal
Поиск узких мест в базе данных
Когда приложение начинает тормозить, первой под подозрение часто попадает база данных. Но высокая задержка на стороне БД не означает, что пора покупать более мощный сервер. Причина может быть в неэффективном запросе, блокировках, исчерпании пула соединений, дисковом I/O или нехватке ресурсов.
Разберёмся, как найти настоящую причину.
1. Найдите симптомы. Проверьте время выполнения запросов (особенно p95), количество активных соединений, число медленных запросов, загрузку CPU и дисковый I/O. Сопоставьте эти показатели с задержками приложения, всплесками трафика и недавними деплоями, чтобы понять, когда началась проблема.
2. Определите узкое место. Выясните, что именно происходит: база медленно выполняет запросы, ожидает снятия блокировок, исчерпала доступные соединения или упёрлась в ограничения ресурсов. Также важно различать время выполнения запроса и время ожидания свободного соединения или завершения другой транзакции.
3. Соберите данные. В PostgreSQL для диагностики пригодятся следующие инструменты:pg_stat_statements — поиск ресурсоёмких запросов.pg_stat_activity — просмотр активных запросов и сессий, ожидающих выполнения.pg_locks — анализ блокировок.EXPLAIN (ANALYZE, BUFFERS) — изучение плана выполнения запроса и активности буферов. Будьте осторожны: ANALYZE действительно выполняет запрос.
4. Найдите первопричину.
Медленные запросы: отсутствующие индексы, неэффективные JOIN, полное сканирование таблиц или неудачные планы выполнения.
Блокировки: долгие транзакции или одновременные обновления данных.
Исчерпание соединений: неправильная настройка пулов, простаивающие или утёкшие соединения.
Высокая дисковая нагрузка: интенсивное чтение и запись, большие сканирования или ограничения хранилища.
Нехватка ресурсов: ограничения по CPU, памяти или дисковой ёмкости.
5. Примените подходящее решение. Оптимизируйте запросы и индексы, сокращайте время транзакций, устраняйте блокировки, настраивайте пулы соединений или повышайте производительность хранилища.
Масштабируйте базу только тогда, когда данные подтверждают, что проблема именно в нехватке ресурсов. Увеличение числа соединений или добавление реплик без устранения первопричины может лишь усугубить ситуацию.
6. Убедитесь, что проблема решена. Сравните задержки запросов, использование соединений, загрузку CPU, дисковый I/O и частоту ошибок приложения с показателями до инцидента. Проверьте, сохраняется ли улучшение при типичной нагрузке.
Последовательность диагностики:
Наблюдение → Локализация → Исследование → Диагностика → Исправление → Проверка
Примеры в этом материале основаны на PostgreSQL, но сам подход применим и к MySQL, SQL Server и Oracle. При этом диагностические инструменты и команды будут отличаться.
Не гадайте, в чём проблема с базой данных. Соберите доказательства, устраните причину и измерьте результат.
👉 @BackendPortal
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
Как работает интернет: практический гайд для начинающих Full-Stack-разработчиков
Когда интернет работает, всё кажется магией: вводишь URL, нажимаешь Enter — и через пару секунд перед тобой готовая страница. Но за этим простым действием стоит целая цепочка систем: браузер, DNS, маршрутизаторы, серверы, базы данных и сетевые протоколы.
Читать статью
👉 @BackendPortal
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
Кэш ускоряет приложение, но неправильное кэширование убивает надёжность
Разберём самые распространённые ошибки при работе с кэшем.
❌Кэшировать всё подряд
→ Устаревшие данные и несогласованность при чтении.
✅ Кэшируйте только часто используемые и относительно стабильные данные.
❌ Не задавать TTL
→ Данные никогда не устаревают, и пользователи могут бесконечно получать неактуальную информацию.
✅ Устанавливайте время жизни кэша (TTL).
❌ Обновлять кэш и базу данных без стратегии согласования
→ Частичный сбой может привести к расхождению данных.
✅ Используйте подходящие стратегии синхронизации, например write-through или write-behind, с учётом требований к согласованности.
❌ Использовать единственный экземпляр кэша без резервного сценария
→ Если кэш станет недоступен, приложение может перестать работать или перегрузить базу данных.
✅ Предусмотрите обработку сбоев и резервный сценарий чтения из БД.
❌ Не продумывать инвалидацию кэша
→ Классическая ситуация: в DEV всё работает, а в PROD начинаются проблемы.
✅ Заранее определите, когда и каким образом кэш должен обновляться или очищаться.
Главное правило: кэш — это инструмент оптимизации производительности, а не источник истины. Храните основные данные в надёжном постоянном хранилище и продумывайте поведение кэша при сбоях.
👉 @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 месяцев
🔥 Открытый урок «Микросервисы на практике»
Когда монолит становится сложно развивать, хочется разделить его на микросервисы, но вместе с этим появляются новые вопросы: где провести границы, как организовать взаимодействие сервисов и что делать, если один из них перестал отвечать.
29 октября в 19:00 МСК разберём, когда стоит переходить к микросервисам и как проектировать их с учётом сбоев и роста нагрузки.
На уроке ты узнаешь:
➖ чем микросервисная архитектура отличается от монолита и когда переход оправдан
➖ какие проблемы возникают при взаимодействии микросервисов
➖ какие паттерны помогают сделать систему надёжнее и как применять идемпотентность
На продакшен кейсе сервисов заказов и платежей разберём, как потерянный ответ приводит к двойному списанию и как от этого защититься.
Урок проведёт Станислав Клоков, тимлид финтех-проекта с нагрузкой 100k RPS, который раньше разрабатывал ядро платформы микросервисов в Яндексе.
👉 Регистрируйся, чтобы разобраться в микросервисах на практическом примере
TLS termination звучит просто, но это один из ключевых элементов современной инфраструктуры.
Вместо того, чтобы каждый бэкенд сам занимался шифрованием и расшифровкой, всю TLS-нагрузку берет на себя балансировщик на границе сети.
Когда клиент подключается, TLS-handshake происходит между браузером и балансировщиком. Балансировщик использует свой сертификат, устанавливает защищенный канал и расшифровывает входящий HTTPS-трафик.
Дальше он общается с бэкендами уже по обычному HTTP внутри приватной сети.
В результате сервера приложений не тратят CPU на криптографию, им не нужны сертификаты, и они занимаются только бизнес-логикой.
Плюс обновление сертификатов становится проще — все лежит в одном месте, а не разбросано по десятку сервисов.
Важно помнить:
незашифрованный трафик живет только внутри доверенной внутренней сети. Снаружи все остается зашифрованным до самого балансировщика.
Cache-Aside vs Read-Through vs Write-Through vs Write-Back
Где должна находиться логика кеширования и когда данные следует записывать в базу данных? Эти четыре стратегии кеширования помогают найти баланс между производительностью, согласованностью данных и надёжностью системы.
1. Cache-Aside (Lazy Loading — ленивая загрузка). Проблема: приложение самостоятельно управляет загрузкой данных в кеш.
Как работает:
• Приложение сначала проверяет кеш.
• Если данных нет (Cache Miss), оно запрашивает их из базы данных.
• Полученный результат сохраняется в кеше.
Пример: страница товара загружает информацию из базы данных только в том случае, если её нет в кеше.
Лучше всего подходит: для приложений с преобладанием операций чтения, где не все записи базы данных нужно кешировать.
Компромисс: первый запрос после Cache Miss выполняется медленнее. Кроме того, устаревшие данные могут оставаться в кеше, если их своевременно не инвалидировать.
2. Read-Through Cache. Проблема: приложение не должно самостоятельно управлять ситуациями Cache Miss.
Как работает:
• Приложение запрашивает данные из кеша.
• Если данных нет, кеш самостоятельно загружает их из базы данных.
• Кеш сохраняет результат и возвращает его приложению.
Пример: сервис пользовательских профилей обращается к кеширующему слою, который автоматически загружает отсутствующие профили.
Лучше всего подходит: для приложений, которые хотят упростить логику чтения данных.
Компромисс: требуется кеширующий слой, поддерживающий автоматическую загрузку данных из основного хранилища.
3. Write-Through Cache. Проблема: при записи необходимо одновременно обновлять кеш и базу данных.
Как работает:
• Приложение записывает данные в кеш.
• Кеш записывает эти данные в базу данных.
• Подтверждение записи возвращается только после успешного выполнения обеих операций.
Пример: обновление цены товара через кеширующий слой с поддержкой Write-Through.
Лучше всего подходит: для систем, где важно поддерживать согласованность данных в кеше и базе данных.
Компромисс: операции записи могут выполняться дольше, поскольку необходимо обновить и базу данных.
4. Write-Back (Write-Behind) Cache. Проблема: запись в базу данных может стать узким местом производительности.
Как работает:
• Приложение записывает данные в кеш.
• Кеш подтверждает успешную запись.
• База данных обновляется асинхронно, часто пакетами.
Пример: регистрация часто обновляемых счётчиков или событий аналитики с последующей пакетной записью в постоянное хранилище.
Лучше всего подходит: для систем с большим количеством операций записи, где важна минимальная задержка.
Компромисс: сбой кеша до сохранения данных в базе может привести к их потере, если отложенные записи не защищены надёжным журналированием или репликацией.
5. Краткое сравнение.
• Cache-Aside: приложение самостоятельно обрабатывает Cache Miss и обновляет кеш.
• Read-Through: кеш самостоятельно загружает отсутствующие данные.
• Write-Through: кеш и база данных обновляются синхронно.
• Write-Back: сначала данные записываются в кеш, а база данных обновляется позже.
6. Совет для собеседования
• При выборе стратегии кеширования задайте себе следующие вопросы:
• Преобладают операции чтения или записи?
• Насколько актуальными должны быть данные?
• Может ли приложение допускать использование устаревших данных?
• Что произойдёт, если кеш выйдет из строя до того, как запись попадёт в базу данных?
Главный вывод: Универсально лучшей стратегии кеширования не существует. Правильный выбор зависит от характера нагрузки на чтение и запись, требований к согласованности данных, допустимых задержек и обработки сбоев.
👉 @BackendPortal
Рейтинг сложности DSA выглядит пугающе, пока не поймёшь, что изучать все темы одновременно не нужно.
Правильная стратегия — двигаться постепенно, от простого к сложному.
1. Начните с категорий A+/A
Массивы → Хеширование → Строки → Связные списки → Стек → Очередь → Сортировка → Два указателя → Скользящее окно.
2. Переходите к категории S
Бинарный поиск → Деревья/BST → Интервалы → Префиксные суммы → Рекурсия.
3. Затем переходите к SS
Графы → Кучи (Heap) → Жадные алгоритмы → Монотонный стек → Монотонная очередь → Слияние K отсортированных последовательностей.
4. Сложные темы оставьте напоследок
Префиксные деревья (Trie) → Система непересекающихся множеств (Union Find) → Алгоритм Дейкстры → Поиск с возвратом (Backtracking) → Динамическое программирование (DP) → Продвинутые алгоритмы на графах.
Самое главное:
Не изучайте DSA просто ради того, чтобы пройти весь список тем.
Вместо этого придерживайтесь последовательности:
- Изучите алгоритмический паттерн.
- Решите несколько простых задач.
- Перейдите к задачам средней сложности.
- Разберитесь с различными вариациями паттерна.
- Возвращайтесь к темам, в которых допускаете ошибки.
Цель не в том, чтобы сделать DSA проще, а в том, чтобы сложность возрастала постепенно.
👉 @BackendPortal
5 паттернов обмена сообщениями, которые должен знать каждый кандидат на собеседовании по System Design
1. Point-to-Point (точка-точка)
Одно сообщение отправляется одному обработчику.
2. Publish/Subscribe (публикация/подписка)
Подписчики получают сообщения по темам, на которые они подписаны.
3. Fan-out (широковещательная рассылка)
Одно событие копируется и отправляется нескольким очередям или потребителям.
4. Request-Reply (запрос-ответ)
Клиент отправляет запрос и получает ответ.
5. Event Streaming (потоковая передача событий)
События сохраняются, чтобы потребители могли обрабатывать их или воспроизводить повторно.
Каждый паттерн решает свою задачу обмена данными между компонентами системы.
Важно понимать, когда использовать каждый из них на собеседованиях по HLD (High-Level Design).
👉 @BackendPortal
Sharding, Partitioning и Replication: в чём разница?
В системном дизайне эти три понятия часто путают, хотя каждое решает свою задачу.
1. Partitioning (партиционирование)
Разделение большой таблицы на более мелкие части. Это помогает оптимизировать выполнение запросов и упростить управление данными.
2. Sharding (шардирование)
Распределение частей данных между несколькими серверами. Позволяет масштабировать хранилище и увеличить пропускную способность операций записи.
3. Replication (репликация)
Создание копий данных на нескольких серверах. Повышает доступность системы и позволяет распределять нагрузку на чтение.
Как запомнить разницу:
• Partitioning = разделить данные.
• Sharding = распределить данные.
• Replication = скопировать данные.
Понимание того, когда использовать каждый из этих подходов, — важная часть проектирования масштабируемых баз данных.
👉 @BackendPortal
Освойте проектирование API с помощью одного поста.
👉 @BackendPortal
Как находить причины высокой задержки (High Latency)
Ваш API отвечает медленно. Прежде чем увеличивать мощность CPU, добавлять индексы в базу данных или масштабировать сервис, выясните, на что именно уходит время.
Разберём, как к такой проблеме подходит инженер, работающий с production-системами.
1. Начните с перцентилей задержки. Среднее время ответа может скрывать серьёзные проблемы. Например, большинство запросов выполняется за 100 мс, но небольшая часть — за 2 секунды. Среднее значение при этом может выглядеть вполне приемлемо, хотя некоторые пользователи сталкиваются с заметными тормозами.
Основные перцентили:
p50 (медиана) — 50% запросов выполняются за это время или быстрее. Показывает типичную задержку.
p95 — 95% запросов выполняются за это время или быстрее. Оставшиеся 5% работают дольше.
p99 — 99% запросов выполняются за это время или быстрее. Оставшийся 1% — самые медленные запросы.
Сравнивайте эти показатели в динамике, а при необходимости разбивайте их по эндпоинтам, регионам, версиям сервиса и группам пользователей.
Если p50 остаётся стабильным, а p99 резко растёт, ищите причину, которая замедляет только часть запросов. Если растут все перцентили — вероятно, проблема затрагивает систему в целом.
2. Проследите путь медленного запроса. Метрики показывают, что задержка выросла. Распределённые трассировки (Distributed Tracing) помогают понять, где именно теряется время.
Представим, что запрос проходит через API Gateway, сервис пользователей, сервис товаров и базу данных. Трассировка разбивает весь путь на отдельные операции — spans — и показывает их продолжительность и взаимосвязи.
Ищите самые медленные этапы, повторные вызовы зависимых сервисов, ретраи и время ожидания внешних компонентов.
Важный нюанс: не складывайте длительность всех spans напрямую. Родительские операции часто включают время дочерних, а параллельные операции могут выполняться одновременно. Используйте временную шкалу трассировки, чтобы определить реальный критический путь (critical path).
3. Найдите настоящий источник задержки. Когда вы определили медленный компонент, выясните причину.
Приложение: проверьте загрузку CPU, нехватку потоков или рабочих процессов, работу сборщика мусора и медленные внешние вызовы.
База данных: отделите время выполнения запроса от ожидания получения соединения. Изучите медленные запросы, планы выполнения, блокировки и загрузку пула соединений.
Сеть и зависимости: проверьте DNS, установление соединений, таймауты, повторные попытки и задержки зависимых сервисов.
Кэширование: изучите долю попаданий в кэш, промахи, вытеснение данных и время ответа кэша.
Не стоит автоматически считать, что медленный участок трассировки с базой данных означает медленный SQL-запрос. Приложение может ожидать свободное соединение, снятие блокировки или ответ по сети.
Используйте логи для контекста конкретного запроса, метрики — для понимания поведения системы, а трассировки — чтобы связать отдельные этапы. Сопоставляйте данные по временным меткам, trace ID и событиям деплоя.
4. Проверьте гипотезу, прежде чем что-либо менять. Представим ситуацию: после деплоя p99 вырос с 300 мс до 2,4 секунды, но количество ошибок осталось прежним. Трассировка показывает, что основная часть дополнительного времени уходит на ожидание соединения с базой данных.
Метрики пула подтверждают, что все соединения заняты, при этом время выполнения SQL-запросов не изменилось. Теперь у вас есть подтверждение проблемы с исчерпанием пула соединений (connection pool exhaustion), а не с медленными SQL-запросами.
Разберитесь, почему пул оказался переполнен, устраните конкретную причину и сравните показатели до и после изменений. Убедитесь, что задержка вернулась к норме, а нагрузка на базу данных и количество ошибок не выросли.
Главный принцип: Наблюдайте за симптомом. Находите источник задержки. Проверяйте гипотезу. Подтверждайте результат.
Опытные инженеры не перебирают все возможные решения наугад. Они опираются на данные и последовательно исключают варианты, пока не находят настоящую причину проблемы.
👉 @BackendPortal
Инструмент недели: Kubetail
Разбирать логи в Kubernetes бывает непросто: приходится переключаться между подами, запускать kubectl logs и искать причину ошибки среди множества реплик приложения.
Kubetail open-source инструмент для просмотра логов Kubernetes в реальном времени. Он собирает логи из нескольких подов в одном интерфейсе, упрощая отладку приложений.
Что умеет:
• Показывать логи нескольких подов и контейнеров одновременно.
• Обновлять временную шкалу при появлении, остановке и замене подов.
• Фильтровать логи по временному диапазону, зоне доступности, архитектуре CPU и узлу.
• Переключаться между несколькими кластерами через десктопное приложение.
Полезный инструмент для тех, кто работает с Kubernetes и хочет тратить меньше времени на поиск ошибок в логах.
GitHub: https://github.com/kubetail-org/kubetail
👉 @BackendPortal
На Stepik вышла программа «DevOps с нуля в эпоху AI: от Linux до Kubernetes [2026]»
Это комплексная программа из 5 практических курсов по ключевым технологиям DevOps: Linux, Git, Docker, GitLab CI/CD, Kubernetes
Полный путь от основ до продакшена: вы научитесь настраивать Linux, упаковывать приложения в Docker, автоматизировать деплой через GitLab CI/CD и управлять контейнерами в Kubernetes.
Что вы изучите:
• работу с Linux и командной строкой
• Git и контроль версий в реальных проектах
• создание Docker-образов и запуск контейнеров
• автоматизацию сборки, тестирования и деплоя в GitLab CI/CD
• развёртывание и управление приложениями в Kubernetes
• сети, хранилища, конфигурации и секреты
• диагностику инфраструктуры и автоматизацию рутинных задач
... и многое другое
PYTHON20 стоимость всей программы составит 10 392 ₽.
Дорожная карта Backend-разработчика (1/11): проектирование API
API — основа любого современного приложения. Неправильно выбранный подход может привести к проблемам с производительностью, сложностям при масштабировании и неудобству разработки.
В этой части разберём три популярных подхода к проектированию API:
• REST — простой и stateless-подход, использующий HTTP-методы. Стандартный выбор для публичных API.
• GraphQL — клиент запрашивает только те данные, которые ему нужны. Это помогает избежать избыточной загрузки данных и дополнительных запросов за недостающей информацией.
• gRPC — бинарный формат передачи данных и HTTP/2 обеспечивают высокую производительность. Подходит для высоконагруженных микросервисов.
Главный навык — не просто знать все три технологии, а понимать, когда какую использовать:
REST → публичные API, простые CRUD-операции, удобное кэширование.
GraphQL → сложные запросы и приложения с разными клиентами, например вебом и мобильными устройствами.
gRPC → взаимодействие внутренних сервисов, потоковая передача данных в реальном времени и низкие задержки.
Не ограничивайтесь заучиванием определений — разбирайтесь в компромиссах каждого подхода и выбирайте инструмент под конкретную задачу.
👉 @BackendPortal
Приглашаем на Java Jam — бесплатный митап ЮMoney для бэкенд-разработчиков 🔥
✅ 29 октября, четверг, 19:00 (мск) — приходите на митап в Санкт-Петербурге или смотрите трансляцию.
Спикеры из ЮMoney и Сбера выступят с докладами:
🟣 Один апгрейд — больше сотни сервисов: как мы обновляем Java-стек в компании
Обсудим, как обновить Gradle, Spring Boot и Java в 120+ компонентах, не останавливая разработку. Расскажем, как выстраивали процессы на протяжении этого времени: от порядка действий и массовых патчей до взаимодействия с командами и решения трудностей, с которыми столкнулись во время последнего обновления.
🟣 Как я автоматизировал свой проект — и всё сломал
Разберём, как выстроить автоматизацию в проекте с помощью ИИ и какие шишки можно набить на пути. Поговорим, как работает длинный контекст в моделях и как организовать работу с учётом этих особенностей.
🟣 Откатить нельзя оставить: мониторинг выкладки релиза на основе Sentry
Ошибки случаются. Узнаем, какие из них появляются или возникают чаще после последнего релиза — и достаточно ли этого, чтобы принять решение об откате.
Зарегистрируйтесь, чтобы принять участие. Все подробности — на сайте митапа Java Jam👈
ThreadPoolExecutor решает, переживёт ли ваша система резкий всплеск нагрузки. Многие сбои начинаются именно здесь
1. У ThreadPoolExecutor есть 4 ключевых компонента:
• Core threads — минимальное количество потоков, поддерживаемых пулом.
• Max threads — максимальное количество потоков.
• Queue — очередь задач, ожидающих выполнения.
• Rejection policy — политика обработки задач, которые пул больше не может принять.
2. Что чаще всего идёт не так:
• Очередь не имеет ограничения по размеру.
• Количество потоков настроено неправильно.
• Отказы в приёме задач игнорируются.
3. Неограниченная очередь приводит к незаметному отказу системы:
• Растёт время ожидания ответа.
• Потоки надолго блокируются.
• Увеличивается потребление памяти.
• В итоге система постепенно перестаёт справляться с нагрузкой.
4. Максимальное количество потоков не спасёт ситуацию. Если зависимые сервисы отвечают медленно, увеличение числа потоков может лишь ускорить перегрузку системы.
5. Политика отказа — не опция, а необходимость. Она позволяет системе сообщить: «Я больше не могу принимать новые задачи».
6. Устойчивые системы умеют:
• Применять обратное давление (backpressure), ограничивая поступление новых задач.
• Быстро отказывать, если обработка невозможна (fail fast).
• Быстро восстанавливаться после сбоев.
Главное: управление параллелизмом помогает контролировать нагрузку, но не увеличивает реальные вычислительные ресурсы системы.
👉 @BackendPortal
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
Асинхронный код НЕ делает ваш API быстрее
Он меняет способ использования потоков, а не скорость выполнения самой работы.
Что на самом деле означает «быстрее»?
• Меньшая задержка (latency) — время обработки одного запроса.
• Большая пропускная способность (throughput) — количество запросов, которые система обрабатывает за определённое время.
Асинхронность помогает увеличить пропускную способность, но не обязательно уменьшает задержку отдельного запроса.
Синхронная модель (блокирующая)
→ Поток ждёт ответа от базы данных, сети или файловой системы.
→ Пока идёт ожидание, поток занят, но не выполняет полезную работу.
→ При высокой нагрузке потоки в пуле могут закончиться.
→ Запросы начинают ждать своей очереди и могут завершаться по тайм-ауту.
Асинхронная модель (неблокирующая)
→ Поток запускает операцию ввода-вывода и может заняться другими задачами.
→ Во время ожидания ответа поток не заблокирован этой операцией.
→ То же оборудование может обслуживать больше одновременных запросов.
→ Система лучше справляется со всплесками нагрузки.
Важный нюанс, который часто упускают: Если узкое место — процессор (CPU), асинхронность сама по себе практически не поможет ускорить вычисления.
Если узкое место — ввод-вывод (I/O), асинхронность может существенно повысить эффективность использования ресурсов.
Как это реализовано в разных технологиях?
• Spring MVC — традиционная модель с блокирующим вводом-выводом.
• Spring WebFlux — поддерживает неблокирующую обработку запросов.
• Node.js — использует событийный цикл (event loop) и асинхронные операции ввода-вывода.
Главное: асинхронность — это инструмент масштабирования, а не магический способ ускорить код.
👉 @BackendPortal