15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Бэкпрешер — ключевая вещь для нормально работающей инфраструктуры.
Когда базы данных, очереди сообщений, коннекшн-пулы и другие системы начинают захлёбываться от нагрузки, как они с этим справляются?
Некоторые продукты просто дают ресурсам выгореть до нуля и в итоге падают в креш или фейл-состояние (OOM и так далее). Реализовать такое поведение проще всего, но дальше начинаются каскадные проблемы, которые могут уложить всю систему и даже привести к потере данных. Так себе вариант.
Подход получше — когда каждый компонент сам отдаёт бэкпрешер своим клиентам. Смысл в том, что если сервис видит, что работает на пределе (лимит подключений, забиты все буферы памяти и прочее), он сообщает об этом клиентам: через явные сигналы или, например, отклоняя новые подключения. То есть он сохраняет своё здоровье ценой того, что часть запросов будет замедлена или отклонена.
Если бэкенды спроектированы так, чтобы уважать сигналы бэкпрешера, внезапные пиковые нагрузки приводят только к деградации производительности, а не выключают всю систему целиком.
👉 @BackendPortal
Go-разработчики обсуждают экспериментальный акторный рантайм, через который прогнали 10 млн сообщений и получили около 30 млн операций в секунду. Проект пока не готов для продакшена, но показал, что базовый паттерн работает эффективно.
Автор использует классическую акторную модель, естественно ложащуюся на примитивы Go - - одна горутина владеет своим состоянием, взаимодействие идёт исключительно через канал сообщений. Это позволяет обойтись без локов и исключить доступ к общему мутируемому состоянию.
Схема проста:
один актор = горутина + mailbox, состояния — приватные, остальная программа общается только через Send(msg), а сам актор крутится в цикле обработки входящих сообщений.
https://github.com/anthdm/hollywood
👉 @BackendPortal
Крыса следит за твоими эндпоинтами, чтобы тебе не пришлось 🐁
statui — TUI-дашборд для проверки здоровья API.
Следи за эндпоинтами, латентностью и фейлами в реальном времени прямо из терминала.
Написан на Rust и собран с помощью ratatui
Тестим здесь: https://github.com/Mohamed-Badry/statui
👉 @BackendPortal
Анатомия фрейма WebSockets
Максимальный размер заголовка всего 14 байт, что делает WebSockets более эффективным для двунаправленных сценариев (например, чаты, игры) по сравнению с long polling, где есть накладные расходы из-за HTTP-заголовков.
Максимальный размер сообщения может достигать 2^63 байт.
Разумеется, поскольку WebSockets работает поверх TCP, мы сталкиваемся с проблемой head-of-line blocking.
👉 @BackendPortal
Добавление индексов критично для производительности базы, но не всегда есть смысл индексировать вообще все строки.
Используй частичный индекс. Он даёт более быстрые запросы по сравнению с обычным индексом и при этом экономит место на диске.
Отлично подходит для случаев, когда ты постоянно делаешь запросы с одним и тем же WHERE.
👉 @BackendPortal
⚡️ ВАЙБ-КОДИНГ теперь в Telegram!
Ребята сделали крутейший канал, где на наглядных примерах и понятном языке рассказывают как войти в новую эру разработки с ИИ, делятся полезными фишками и инструментами
Подписывайтесь: @vibecoding_tg
Ты реально можешь превратить свой терминал в текстовый редактор.
Есть open-source тулза под названием Fresh. Ставишь один npm-пакет, запускаешь команду fresh и твой терминал мгновенно превращается в современный редактор.
Можно открывать файлы.
Редактировать папки.
Использовать командную палитру.
И даже получать фичи, очень похожие на VS Code, но прямо внутри окна терминала.
Проект просто дикий. Об этом явно должны знать больше людей.
Пользуемся
👉 @BackendPortal
DDD — это концепция, которую я часто вижу недооценённой, хотя по моему опыту она оказалась реально полезной.
Часто, когда говорят про DDD, сразу думают про bounded contexts, aggregates, сущности, value objects.
И это нормально. Но я считаю, что сердце DDD не в архитектуре, а в языке.
Единый (Ubiquitous) язык — это не красивый словарик и не набор умных терминов.
Это семантическое соглашение между бизнесом и технологиями.
Живой контракт, который определяет, как мы думаем, как называем вещи и как решаем проблемы.
Что такое Единый язык на самом деле
Это набор слов, понятий и правил, которые вся команда использует для описания домена.
Не в теории, не на стикерах, а в коде, в разговорах и в документации.
Например:
Если бизнес говорит «подписка», а в коде у тебя «membership».
Если бизнес говорит «фактическая отмена», а в коде используется «softDelete».
Если бизнес различает «клиента» и «потребителя», а в модели у тебя везде просто «User».
Значит, у тебя нет Единого языка.
У тебя есть ментальные переводы, путаница для всех, кто не технарь, куча неоднозначностей, и эти проблемы коммуникации рано или поздно превращаются в баги.
Как ни крути, софт — это отражение бизнеса.
Если язык в коде не совпадает с тем, как мыслит бизнес, ты увеличиваешь риск построить систему, которая не отражает реальность.
А когда реальность не совпадает с кодом, ты получаешь продукт, который может не соответствовать исходным ожиданиям.
Единый язык как раз и пытается убрать этот разрыв.
Он делает так, чтобы домен существовал и в голове у бизнес-эксперта, и в твоём редакторе кода.
Как это выглядит в реальном проекте
Например, если бизнес говорит:
«Заказ может перейти в статус “Одобрен”, только если платёж подтверждён».
Твоя модель должна отражать это напрямую:
order.approve(paymentConfirmation);
order.validate();
order.setStatus(3);
Когда между идеей и продом — преград нет!
В VK любят решать сложные и масштабные задачи, а ещё — быстро реализовывать идеи. Компания рассказала, каких принципов придерживается команда в работе и какими результатами гордится. Переходите по ссылке, там много интересного!
Когда приложению нужно узнать о чем-то важном, например что пользователь оплатил подписку, у тебя есть два варианта:
1. приложение дергает API раз в пять минут, проверяя, был ли новый платеж;
2. платежная система сама шлет тебе уведомление в момент события.
Первый вариант — это polling: ты спрашиваешь, даже если ничего не произошло. Работает, но медленно и плохо масштабируется.
Второй вариант — webhook: HTTP-коллбек, который срабатывает, когда произошло событие.
Вместо того чтобы опрашивать систему, она сама присылает нужные данные.
Как выглядит поток, если ты используешь вебхук:
1. настраиваешь публичный эндпоинт;
2. твой сервер принимает POST с данными платежа;
3. проверяешь подпись (секретный ключ);
4. выполняешь свою бизнес-логику (платеж подтвержден, подписка активна и так далее).
Типичные проблемы:
- платеж может прийти дважды, поэтому сохраняют обработанные ID (идемпотентность);
- события могут прийти не по порядку, так что на хронологию лучше не рассчитывать;
- запрос может отправить кто угодно, поэтому обязательна проверка подписи.
Вебхуки важны потому, что избавляют приложение от постоянного опроса сторонней системы.
Сегодня их используют везде: платежи, подписки, деплои, интеграции, автоматизации и вообще любые сценарии, где другой сервис узнает о событии раньше тебя.
👉 @BackendPortal
Большинство людей используют grep чтобы искать по файлам. Я использую его чтобы выживать в продовых пожарах в 3 ночи.
grep "error" logfile.txt
→ Ищет "error" в файле.
grep -i "error" logfile.txt
→ Ищет без учета регистра.
grep -r "TODO" /project/
→ Рекурсивный поиск по директориям.
grep -n "function" script.py
→ Показывает номер строки вместе с результатами.
grep -v "debug" logfile.txt
→ Показывает всё, кроме строк с "debug".
grep -c "warning" logfile.txt
→ Считает количество совпадений.
grep -w "cat" animals.txt
→ Совпадение только по целым словам.
grep -C 3 "exception" logfile.txt
→ Показывает 3 строки до и после совпадения.
grep "import" *.py
→ Ищет сразу по нескольким файлам.
grep -E "error|warning|critical" logfile
→ Ищет по нескольким шаблонам сразу.
Тот самый продовый пожар в 3 ночи
Приложение упало. Пользователи бесятся. Телефон разрывается.
grep -rni "exception" /var/log/ | grep "2025-12-02"
Это находит все исключения в логах за сегодня. С номерами строк. По всем файлам.
Тысячи строк сужаются до причины падения за секунды.
Почему это важно
Твой IDE не работает на удалённых серверах. Не тянет гигабайтные логи. И точно не помогает в 3 ночи, когда прод лег.
А grep помогает.
Разница между джуном и сеньором?
Умение пользоваться терминалом, когда это реально нужно.
👉 @BackendPortal
Большинство инженерных команд косячат с архитектурой сообщений, потому что не понимают простую вещь:
Стримы хранят правду.
Очереди выполняют работу.
Когда это путают, система начинает кровоточить.
Я видел проекты, где слили миллионы просто потому, что всё пихали в очередь типа
"Ну просто запушим заказ в очередь, а там обработаем!"
"Мы будем стримить абсолютно всё!"
Если событие меняет состояние бизнеса → стрим.
Если сообщение это действие к выполнению → очередь.
Оптимизация слоев Docker-образа сократила время деплоя с 12 минут до 90 секунд.
Изначальный Dockerfile:
Любое изменение кода пересобирало весь образ
Зависимости ставились каждый раз заново
Кэш слоев никак не использовался
Размер образа был 1.2GB
Проблемный фрагмент:
COPY . /app
RUN pip install -r requirements.txt
COPY requirements.txt /app/
RUN pip install -r requirements.txt
COPY . /app
Уменьшаем время выборки из БД с 2–3 секунд до ~100 мс:
SELECT * FROM transactions
WHERE user_id = 40
ORDER BY created_at DESC
LIMIT 20 OFFSET 10000;
SELECT * FROM transactions
WHERE user_id = 40
AND created_at < '2024-05-01 10:00:00'
ORDER BY created_at DESC
LIMIT 20;
WHERE (created_at, id) < ('2024-05-01 10:00:00', 98765)
ORDER BY created_at DESC, id DESC
Оптимизация SQL в бэкенде
Оптимизация SQL обеспечивает эффективную работу запросов в бэкенде, снижает задержки и повышает общую производительность системы.
Плохо оптимизированный SQL приводит к медленному отклику, высокой загрузке процессора и узким местам в приложениях с высокой нагрузкой.
✓ 1. Изучение планов выполнения запросов
Используйте команды EXPLAIN или EXPLAIN ANALYZE, чтобы понять, как база данных выполняет запрос.
→ Помогает выявить полное сканирование таблиц, неэффективные соединения, отсутствующие индексы или ненужную сортировку.
✓ 2. Индексирование для ускорения поиска
Создавайте индексы для столбцов, которые часто используются в запросах (например, поля поиска, внешние ключи).
Используйте составные индексы при фильтрации по нескольким столбцам.
Избегайте избыточного индексирования: каждый индекс замедляет операции вставки, обновления и удаления.
✓ 3. Избегайте использования SELECT *
Выбирайте только необходимые столбцы с помощью конструкции SELECT столбец1, столбец2.
→ Это сокращает объём передаваемых данных и повышает скорость выполнения запроса.
✓ 4. Оптимизация соединений (JOIN)
Используйте подходящие типы соединений (INNER, LEFT, RIGHT) в зависимости от задачи.
Убедитесь, что столбцы, используемые в соединениях, проиндексированы.
Избегайте объединения слишком многих таблиц в одном запросе — при необходимости разбивайте сложную логику.
✓ 5. Эффективное использование условий WHERE
Применяйте фильтрацию как можно раньше, используя избирательные условия.
По возможности используйте индексированные столбцы в фильтрах WHERE.
Избегайте использования функций в WHERE (например, LOWER(name)), так как они препятствуют использованию индексов.
✓ 6. Ограничение количества возвращаемых строк
Используйте LIMIT или OFFSET для пагинации вместо возврата огромных наборов данных.
→ Это повышает производительность фронтенда, которому не требуется вся информация сразу.
✓ 7. Избегание проблемы N+1 запросов
Возникает при получении связанных данных в циклах.
Вместо этого используйте соединения (JOIN) или эффективные пакетные запросы.
✓ 8. Использование кэширования
Кэшируйте часто выполняемые запросы на чтение с помощью Redis или Memcached.
→ Это снижает нагрузку на базу данных и значительно повышает скорость работы.
✓ 9. Нормализация там, где нужно, денормализация — когда это оправдано
Нормализация уменьшает избыточность и повышает согласованность данных.
→ Денормализация ускоряет операции чтения при высокой нагрузке, если производительность — приоритет.
✓ 10. Оптимизация операций вставки и обновления
Используйте пакетные вставки вместо поочерёдной вставки строк.
Избегайте ненужных обновлений: проверяйте, изменились ли значения, прежде чем выполнять обновление.
✓ 11. Разделение больших таблиц
Разделяйте большие таблицы по дате или региону для ускорения запросов.
→ Полезно для логов, аналитики или данных временных рядов.
👉 @BackendPortal
Заказчик кинул с деньгами? Отправьте его в суд.
Чаще из-за ошибок в договоре правда может быть не на вашей стороне. 8 пунктов для безопасного договора — проверьте прямо сейчас.
В 2026 году требования к IT-компаниям и фрилансерам станут жёстче. Разберитесь с налогами, сайтами и договорами уже сейчас.
Подписывайтесь на LAWLEGKO — канал практикующего юриста Инны Вялковой. Новости от государства и юридические тонкости простым языком.
Или передайте всё юристам: договоры, налоги, реклама — юридическое абонентское сопровождение.
Вы занимаетесь работой, юристы LAWLEGKO — вашим спокойствием.
Подожди, так есть децентрализованная альтернатива GitHub? 😲😲😲
Проект называется Tangled, и его идея в том, чтобы дать тебе полное владение своим кодом, без привязки к центральной платформе.
Можно поднять свои репы через лёгкие узлы knot, либо воспользоваться их управляемым узлом, если не хочется заморачиваться с хостингом.
Функционал привычный: git-воркфлоу, issues, pull requests, комментарии. Но при этом ты контролируешь инфраструктуру и данные.
Если когда-то хотелось GitHub-опыт без единого провайдера сверху, стоит глянуть.
ЗАТЕСТИТЬ
👉 @BackendPortal
Интерактивный гайд о шардировании баз данных, как это работает для реляционных баз.
Каждому инженеру стоит понимать базовые принципы и основные сложности шардирования. Эта статья как раз про это и предназначена.
Читаем здесь
👉 @BackendPortal
Вот так обычно выглядит мой эндпоинт /health
👉 @BackendPortal
freeCodeCamp выкатили бесплатный курс по Git и GitHub для новичков. За 1 час разберёшь базу: ветки, слияния, pull request’ы и базовую командную работу. Отличный быстрый вход для тех, кто откладывал Git «на потом».
Git-курс тут
👉 @BackendPortal
Одна вещь, о которой почти каждый из нас задумывается в какой-то момент карьеры в техе:
Лучше быть дженералистом?
Или лучше быть специалистом?
Правда в том, что ни одна из этих позиций, доведённая до крайности, нормально не работает в реальных командах.
Быть только дженералистом может быть опасно: ты знаешь по чуть-чуть про всё, но не можешь копнуть глубже там, где это реально важно.
Быть только специалистом тоже риск: ты держишь одну область с хирургической точностью, но слишком зависишь от команды во всём остальном.
Вот тут как раз появляется концепция T-образного профиля.
Что такое T-образный профиль?
Буква T описывает две оси.
Горизонтальная перекладина.
Широкий кругозор. Скиллы, которые позволяют тебе ходить по разным областям и не стопориться.
Знать достаточно про frontend, devops, тестирование, архитектуру, базы данных и так далее.
Вертикальная ножка.
Глубина в какой-то конкретной области.
Твоя специализация: например Java, безопасность, базы данных, оптимизация, cloud, предметная область и так далее.
T-образный профиль комбинирует оба измерения.
Достаточная широта, чтобы работать в команде.
Реальная глубина, чтобы давать ощутимую добавочную ценность.
Почему это вообще так важно?
Потому что сейчас системы сложные.
Есть микросервисы, которые завязаны на пайплайны.
Есть frontend, который влияет на решения в backend.
Есть архитектура данных, которая влияет на каждую фичу.
Есть инфраструктурные решения, которые меняют дизайн.
Разработчик, который знает только своё, очень быстро выпадает из общего контекста.
А разработчик, который по верхам про всё, в итоге почти ни на что важное не влияет.
T-образный профиль это как раз точка баланса.
Как T-образный профиль выглядит на практике?
Чистый дженералист говорит:
Я умею пользоваться Spring, NestJS, GitHub Actions, Docker, ну плюс-минус.
Чистый специалист говорит:
Я знаю всё про Spring Boot, но не спрашивай меня про API Gateway или React.
А человек с T-образным профилем говорит:
Моя сильная сторона это backend на Java и Spring. Но я достаточно понимаю во frontend, devops, системном дизайне и observability, чтобы нормально сотрудничать, интегрироваться и принимать более взвешенные решения.
В этом разница между девом, который просто пишет код, и девом, который приносит решения.
Самая частая ошибка, я сам так делал:
Путать быть дженералистом с знать много инструментов.
Или путать быть специалистом с вообще не смотреть за пределы своего стека.
Глубину даёт не фреймворк, на котором ты пишешь,
а твоя способность разруливать сложные задачи внутри своей области.
И широту даёт не установка новых тулз,
а способность понимать систему целиком.
Мой взгляд на то, как этим путём идти.
Как всегда, всё зависит от твоего контекста и целей.
Но в реальности я чаще вижу вот что:
Почти все стартуют как дженералисты.
Потом находят для себя какую-то специализацию.
К моменту, когда становимся сеньорами, как правило уже есть T-образный профиль.
Если идёшь в архитектуру или в tech lead, там уже ждут расширенную T: большая широта и со временем несколько глубин.
Важно вот что.
Не зацикливайся на том, чтобы быть экспертом во всём, это невозможно удержать в долгую,
и не закапывайся в роль гуру по одной теме, потому что так можно слишком себя ограничить.
Старайся потихоньку собирать T-образный профиль:
здоровый микс между широкой картиной и реальной глубиной.
Тогда становится проще коллаборировать, проектировать и принимать решения, которые масштабируются.
👉 @BackendPortal
GitHub теперь в Telegram!
Самый прогерский канал, где за 10 минут ты научишься:
/ Пробив по фото и номеру в ТГ
// Как взломать вебку подруги
/// Мануал по OSINT разведке
Подписывайся, нас уже сотни тысяч: >@GitHub
Этот трюк с GitHub PR надо знать
Просто добавь “0” перед словом “github” в URL любого Pull Request, и у тебя откроется полноценный PR-вьювер, который подсвечивает каждую строку diff’а цветом в зависимости от того, сколько внимания от человека она, скорее всего, требует.
Он ищет не только баги. Он подсвечивает всё, что заслуживает второго взгляда: захардкоженные секреты, странные крипторежимы, подозрительную логику или грязный код.
Очень полезный способ быстрее проводить code review и находить то, что обычно легко пропустить.
👉 @BackendPortal
Раньше у GitHub была монолитная база данных, которая держала 950 000 транзакций в секунду 🤯
Но по мере роста компании эта база превратилась в... сами понимаете что. Логичное решение = развалить монолит на несколько меньших баз. На деле все оказалось гораздо сложнее, чем они думали.
Я как раз нашёл видео, где разбирают весь их процесс: какие шаги они предпринимали, как сделали миграцию без даунтайма и при этом ничего не сломали в существующем функционале.
После просмотра ты поймешь, как в реальных проектах мигрируют базы без простоя, как подходить к таким сложным задачам по шагам, и получишь живой пример того, с какими проблемами сталкиваются при масштабировании баз данных и как их решают.
👉 @BackendPortal
Уроки по ИБ, белый хакинг, вирусы, социальная инженерия, безопасность
ИБ Книга — Более 1660 русскоязычных книг по ИБ и Социальной Инженерии можно найти на канале.
no system is safe // cybersec — один из древнейших ресурсов по информационной безопасности в рунете. Книги, курсы, полезные тулсы, уроки по Linux, новости клирнета и даркнета.
Python и 1000 программ — уроки по Python. Python мы будем использовать для создания хакерского софта.
Этичный Хакер — один из крупнейших ресурсов по информационной безопасности в СНГ.
Бэкап — канал с исходниками популярных проектов. Здесь вы найдёте исходные коды нейросетей, ботов, сайтов и других интересных проектов, которые дадут дополнительные знания
Весь материал на каналах в общем доступе. Ничего лишнего.
Тебя спрашивают на бэкенд-собесе.
Вопрос:
Как бы ты спроектировал распределенную систему cron-планирования, которая гарантирует, что задачи будут запускаться ровно один раз, вовремя, на нескольких нодах, без коллизий и дубликатов?
Я бы построил распределенный cron с централизованным управлением расписаниями, несколькими scheduler-нодами и распределенным локом, чтобы задача триггерилась ровно один раз. Выполнение вынесено в пул воркеров, каждый запуск логируется, ретраи координируются через очередь, и система остаётся консистентной даже при падении нод.
Оказалось, что контейнеры внутри одного Cloud Run инстанса могут общаться по локалке. Например через http://localhost:5000
Если задать контейнерам имена (например sidecar), то можно обращаться уже так: http://sidecar:5000
Полезно, когда нужно подключить sidecar-сервис или поделить задачи между контейнерами.
Репо с примером:
https://github.com/steren/cloud-run-multi-container-communication
👉 @BackendPortal
Крупные компании вроде Reddit перенесли бэкенд комментариев с Python на Go и в результате срезали критическую задержку почти вдвое.
Это хорошо показывает типичный выбор для команд разработки:
Python — быстрее в разработке (прототипы, богатая экосистема библиотек)
Go — быстрее в продакшене (низкая задержка, отлично держит высокую нагрузку)
Кому хочется выучить Go через практику и реальные проекты — можно глянуть это
👉 @BackendPortal
Когда готовишься к собесам в FAANG или просто техинтервью, обычно нужно решать тонну задач.
Но фишка в том, что не надо запоминать все решения.
Важно другое — научиться узнавать паттерны. 💊
Вот 25 основных паттернов, которые реально помогают проходить собеседования спокойно и без паники.
Базовые паттерны для массивов и поиска
1. Two Pointers — когда массив отсортирован или нужно найти пару элементов.
2. Sliding Window — задачи на подстроки и непрерывные подмассивы.
3. Prefix Sum — быстрый подсчет суммы диапазонов.
4. Merge Intervals — работа с пересекающимися интервалами.
5. Binary Search — всё, что касается поиска в отсортированных данных.
Сортировка, рекурсия и связанные списки
6. Sorting-Based — сортировка перед анализом данных.
7. Fast and Slow Pointers — поиск середины или цикла в связном списке.
8. Backtracking — генерация комбинаций, перестановок, рекурсивные обходы.
9. Divide and Conquer — разбиение задачи на подзадачи и объединение результата.
10. Linked List Tricks — разворот списка, удаление узлов, двойные указатели.
Стек, очередь и хеш-структуры
11. Stacks & Queues — задачи на LIFO/FIFO.
12. Monotonic Stack — поиск следующего большего или меньшего элемента.
13. Expression Evaluation — парсинг выражений, калькуляторы, скобки.
14. String Manipulation — палиндромы, анаграммы, работа со строками.
15. Hashmaps — быстрые lookup, подсчеты частот.
Деревья, кучи и продвинутые структуры
16. Binary Trees & BST — обходы, баланс, минимумы, максимумы.
17. Path Sum — поиск валидных путей или сумм в деревьях.
18. K-th Largest (Heaps) — получение k-го по величине элемента.
19. Top-K Frequent — задачи на частотность.
20. Merge K Sorted Lists/Arrays — объединение нескольких отсортированных потоков.
Алгоритмы и системное мышление
21. Dynamic Programming — оптимизация и задачи с пересекающимися подзадачами.
22. Greedy — локально оптимальные шаги для финального результата.
23. Graph Traversal — BFS/DFS, обходы, проверка связности.
24. Graph Algorithms — кратчайший путь, стоимость, маршруты.
25. Design Problems — структуры вроде LRU Cache, Rate Limiter, Trie и т.п.
👉 @BackendPortal
Вот небольшая анимация, которая показывает, как циклы искажают связь между исходным кодом и реально выполняемыми инструкциями. Думаю, новичкам это часто сложно понять, но по моему мнению, умение делать такие выводы — один из ключевых шагов к тому, чтобы научиться действительно хорошо читать код.
👉 @BackendPortal