15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
⚡️💬 Оригинальный Claude API от $0.40 за 1M токенов
Без VPN, дорогих подписок и подмены модели под капотом.
ClaudeHub — для тех, кто использует ИИ в коде, учёбе, работе, ботах и своих проектах.
выбираете Claude — получаете Claude
Платите только за фактическое использование токенов и быстро начинаете через Telegram-бота.
Подходит для Cursor, Claude Code, Cline, Roo, Continue и любых проектов через API.
🆓 Первые 100 пользователей получают 50₽ на баланс по промокоду: FIRST100
✨ Быстрый старт: @claudehub_bot
🔗 Регистрация: app.claudehub.fun/register
💬 Поддержка: t.me/claudehub_support
Нужно заглянуть внутрь образа контейнера, не запуская его?
Один из самых практичных способов:
docker create --name tmp my-image
docker export tmp | tar -C rootfs -xf -
rootfs, который корректно сохранит все права доступа, владельцев файлов и расширенные атрибуты (xattrs), например, capabilities, sticky bits и т. д. — всё быстро становится гораздо сложнее.
Учебный проект бэкенд системы управления рестораном на Go
Проект построен с упором на продакшен-подходы и хорошо задокументирован с помощью swaggo/swag.
В бэкенде реализованы событийно-ориентированная архитектура, Redis Streams, фоновые воркеры и Outbox Pattern для надёжной доставки email. Для защиты от повторной обработки используются распределённые блокировки и идемпотентные сценарии оплаты и возвратов.
Также проект поддерживает отслеживание заказов в реальном времени через WebSocket, автоматизацию складского учёта, уведомления о низких остатках и автоматическое обновление доступности позиций в меню.
Для поиска используется PostgreSQL Full Text Search с взвешенным tsvector, а производительность запросов оптимизируется с помощью индексов и EXPLAIN ANALYZE.
https://github.com/AboloreDev/geritcht-restaurant
👉 @BackendPortal
Вот что нашёл: AITMPL — это огромная open-source-коллекция компонентов для Claude Code: skills, агенты, команды, хуки, MCP, плагины, циклы, настройки и многое другое — всё аккуратно распределено по категориям.
👉 @BackendPortal
Новый сервис, для конверта документов в Markdown: https://docs.context.dev/api-reference/utility/parse
Достаточно сделать один API-запрос: отправить содержимое файла и получить на выходе Markdown с сохранённой структурой, ссылками и порядком текста.
Сервис поддерживает PDF, Word, Excel, PowerPoint, HTML, CSV, изображения, исходный код и многие другие форматы. Если документ представляет собой скан или фотографию, встроенный OCR автоматически распознает текст.
👉 @BackendPortal
Как мигрировать монолит на микросервисы без полного переписывания системы?
Одна из широко используемых стратегий — Strangler Pattern.
Вместо того чтобы заменять всё приложение целиком, вы переносите функциональность поэтапно — по одному модулю за раз.
Например, уведомления.
Сейчас уведомления обрабатываются внутри монолита.
Вы создаёте микросервис, который берёт эту функциональность на себя.
С этого момента отправка уведомлений выполняется новым сервисом, а остальная часть приложения продолжает работать в монолите.
После того как вы убедились, что всё работает корректно, вы удаляете эту функциональность из монолита и повторяете процесс со следующим модулем.
Как это обычно реализуют?
Один из самых распространённых вариантов — разместить перед приложением API Gateway или Reverse Proxy.
Этот компонент принимает запросы и решает, куда их направить:
в монолит;
в новый микросервис.
Так старая и новая системы могут сосуществовать на протяжении всей миграции.
👉 @BackendPortal
А кто-о-о это сделал: они полностью переписали PostgreSQL на Rust и он уже проходит 100% официальных тестов PostgreSQL 😔
Важно: это не форк, а полностью новая реализация с нуля на Rust, которая на данный момент:
• Проходит все 46 066 запросов из regression suite PostgreSQL 18.3.
• Совместима на уровне диска (можно запустить её напрямую с вашим текущим каталогом данных).
• Имеет рабочее демо в браузере.
Цель проекта — сделать одну из самых сложных баз данных в мире значительно проще для модификации, расширения и оптимизации изнутри, используя Rust и AI-assisted programming.
И самое безумное: уже существует WIP-версия (пока не опубликована), которая обещает быть на 50% быстрее на транзакционных нагрузках и примерно в 300 раз быстрее на аналитических нагрузках.
РЕПО 👇
https://github.com/malisper/pgrust
👉 @BackendPortal
Чёрт… Это может перевернуть всё представление об эмуляторах AWS.
Команда разработчиков отказалась от привычного подхода к созданию эмуляторов AWS и представила Floci.
Это один исполняемый файл на Go размером всего 13 МиБ, который менее чем за 1 секунду запускает 45 сервисов AWS (S3, Lambda, DynamoDB, SQS, SNS, IAM, CloudFormation, Step Functions и другие). Никакого Docker. Никакого LocalStack. Никаких счетов за AWS. Никаких 4 ГБ оперативной памяти, занятых контейнерами. Никакого ожидания по 30 секунд.
Достаточно скачать исполняемый файл, запустить его — и у вас локально работает практически вся инфраструктура AWS.
https://github.com/floci-io/floci
👉 @BackendPortal
Golang: Можно было бы ожидать, что лёгкий мьютекс Go окажется быстрее реализации на основе pthread, но на практике всё наоборот.
Solod — подмножество Go, которое транслируется в C, — использует мьютексы pthread. В бенчмарке, где восемь потоков многократно захватывают и освобождают один и тот же мьютекс, реализация на pthread показала производительность почти в три раза выше, чем мьютекс Go.
👉 @BackendPortal
🇷🇺 Разбираешься в радиочипах, оптике и связи? Забери до 1 000 000 рублей за свои инженерные навыки на турнире «Дронкон» 🇷🇺
«Сталинские Соколы» открывают регистрацию на 4-й Всероссийский турнир «Дронкон», который пройдет с 22 по 26 августа.
Турнир пройдет по направлению:
- Инженерное дело: навыки программирования, сборка электронного оборудования, беспроводная связь, оптические системы + стратегия «Битва Дронов»;
Призовой фонд для победителей:
🥇место – 1 000 000 рублей
🥈место – 700 000 рублей
🥉место – 500 000 рублей
Награда за 4-8 места - 100 000 рублей
Пройди заочный онлайн-этап и получи путевку на очный этап турнира в Республику Татарстан!
Перелет, питание, проживание - за счет организаторов.
🇷🇺 Подать заявку и узнать подробности 🇷🇺
Немного разобрался с тем, как работают блокировки в PostgreSQL. Главный вывод: разные SQL-команды захватывают разные режимы блокировок, и многие из них специально сделаны совместимыми друг с другом, чтобы минимизировать конкуренцию за блокировки.
Даже обычный SELECT захватывает блокировку, которая препятствует выполнению некоторых «тяжёлых» операций (например, VACUUM FULL, REINDEX и т. п.). Оказалось, существует удивительно много сочетаний SQL-команд, которые могут или не могут выполняться одновременно.
И ещё: вот отличный сайт, который наглядно показывает в виде графа, какие SQL-команды могут выполняться параллельно.
👉 @BackendPortal
Инсайд: Я думал, что довольно хорошо знаю PostgreSQL, пока не наткнулся на это.
Оказывается, PostgreSQL способен заменить гораздо больше, чем просто базу данных:
* очереди;
* cron-задачи;
* Redis;
* MongoDB;
* векторные базы данных;
* журналы аудита;
* и даже некоторые сценарии использования Kafka.
Я не говорю, что нужно заменить Postgres'ом каждый инструмент в вашем стеке.
Но мне кажется, что большинство стартапов начинают использовать Redis, Kafka, MongoDB и ещё десяток других сервисов гораздо раньше, чем в них действительно возникает необходимость.
Определённо стоит прочитать, если вы разрабатываете backend-системы. Этот материал заставил меня пересмотреть многие свои представления.
👉 @BackendPortal
Хайлоад: производительность и планирование мощностей
Приглашаем на практический курс для Middle/Senior-разработчиков, техлидов, архитекторов, EM и CTO, которые хотят не просто “знать про хайлоад”, а руками разобраться, как работают производительность, нагрузочное тестирование и масштабирование.
Будем выжимать 20–100K RPS из своих сервисов на своей инфраструктуре, строить latency/RPS-диаграммы, искать ограничения в стеке и использовать эти данные для capacity planning. В программе: Linux-инфраструктура, nginx, Prometheus/Grafana, нагрузочное тестирование через wrkx, тюнинг производительности, планирование мощностей.
Вас жду живые онлайн-сессии и практические домашние задания, в ходе которых вы прокачаетесь в вопросах хайлоада, инфраструктуры и переосмыслите архитектурные подходы в более прагматичном, экономичном и инженерном ключе.
📌 Старт потока 13 июля.
Кто мы: R&D-центр Devhands, основатель и автор курса Алексей Рыбак, ex-СТО Badoo и Yum! Brands, член программного комитета Highload.
Изучайте программу и записывайтесь.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzquZx6p5
Если вы давно хотели интуитивно разобраться, как работает KV Cache в LLM, то это, пожалуй, одна из лучших статей на эту тему.
saad.ahmed1926q/kv-cache-explained-intuitively-2b425a36dfc7" rel="nofollow">https://medium.com/@saad.ahmed1926q/kv-cache-explained-intuitively-2b425a36dfc7
👉 @BackendPortal
НОВИНКА: Устойчивые функции (Durable Functions) в PostgreSQL 🤯
pg_durable — это расширение PostgreSQL. Состояние рабочего процесса, очередь, повторные попытки и восстановление хранятся в Postgres, и оно использует устойчивость Postgres / высокую доступность / резервное копирование / восстановление.
https://techcommunity.microsoft.com/blog/adforpostgresql/introducing-durable-functions-in-postgresql/4526821
👉 @BackendPortal
Сис. дизайн: Балансировщик нагрузки
Балансировщик нагрузки равномерно распределяет входящий трафик между веб-серверами, объединёнными в балансируемую группу.
- Пользователь подключается напрямую к публичному IP-адресу балансировщика нагрузки. При такой схеме клиенты больше не могут обращаться к веб-серверам напрямую.
- Это повышает безопасность: для взаимодействия между серверами используются приватные IP-адреса, недоступные из интернета.
- Балансировщик нагрузки взаимодействует с веб-серверами через приватные IP-адреса.
Добавив второй веб-сервер, мы устранили проблему отсутствия отказоустойчивости и повысили доступность веб-уровня.
- Если сервер 1 выйдет из строя, весь трафик будет перенаправлен на сервер 2. Это не позволит сайту стать недоступным.
- Если трафик сайта резко вырастет и двух серверов окажется недостаточно, балансировщик нагрузки позволит корректно решить эту проблему. В пул можно добавить дополнительные веб-серверы, после чего балансировщик автоматически начнёт направлять запросы и на них.
Вертикальное и горизонтальное масштабирование
Вертикальное масштабирование, также называемое scale up, — это процесс увеличения мощности серверов: добавления CPU, оперативной памяти и других ресурсов.
Горизонтальное масштабирование, также называемое scale out, позволяет масштабировать систему за счёт добавления новых серверов в пул ресурсов.
При низкой нагрузке вертикальное масштабирование может быть хорошим вариантом, а его главное преимущество — простота.
Ограничения вертикального масштабирования
- Невозможно бесконечно добавлять CPU и память одному серверу.
- Отсутствует отказоустойчивость. Если сервер выходит из строя, сайт или приложение полностью перестаёт работать.
Для крупномасштабных приложений горизонтальное масштабирование обычно предпочтительнее из-за ограничений вертикального масштабирования.
Если множество пользователей одновременно обращаются к веб-серверу и нагрузка достигает его предела, пользователи сталкиваются с увеличением времени ответа или вообще не получают ответ.
Эта проблема решается с помощью горизонтального масштабирования и балансировщика нагрузки.
👉 @BackendPortal
Ingress-nginx уходит в прошлое. С марта 2026 поддержка прекратилась. А что вместо него? Предлагаем посмотреть на Gateway API, новый стандарт Kubernetes SIG.
23 июля в 17:00 старший SRE-инженер MWS Cloud Евгений Макеев на практике покажет:
⚫️ чем маршрутизация Gateway API отличается от Ingress
⚫️ как выбрать контроллер
⚫️ как установить Gateway API в Managed Kubernetes
⚫️ как настроить безопасное подключение через TLS-сертификат
Будет полезно для DevOps, платформенным инженерам и разработчикам.
Регистрируйтесь по ссылке
AvitoTech Go&Grill в СПб 22 июля 🔥
22 июля AvitoTech собирает Go-разработчиков на свой фирменный и максимально кайфовый формат Go&Grill. Ивент будет в баре «Юнион». В программе никакой корпоративной духоты:
— Fast food System Design — в командах соберёте архитектуру для мемного проекта;
— Go-бинго;
— зона для отдыха, бар и, конечно, вкусная еда с гриля!
Ждут Go-разработчиков и тех, кто хочет перейти в Go из другого бэкенд-стрима.
Скорее регистрируйтесь, пока есть места! Говорят, их очень мало 🤓
Системный дизайн: База данных
По мере роста числа пользователей одного сервера, на котором размещены веб-уровень и уровень данных, становится недостаточно. Поэтому нам потребуется несколько серверов:
- один для обработки веб- и мобильного трафика — веб-уровень (web tier);
- другой для базы данных — уровень данных (data tier).
Разделение серверов, обрабатывающих веб- и мобильный трафик, и серверов базы данных позволяет масштабировать эти уровни независимо друг от друга.
Какую базу данных использовать?
Можно выбрать между традиционной реляционной базой данных — RDBMS, или SQL-базой данных — и нереляционной базой данных — NoSQL.
Реляционные базы данных представляют и хранят данные в виде таблиц и строк. С помощью SQL можно выполнять операции JOIN между различными таблицами базы данных.
Нереляционная база данных может быть подходящим выбором, если:
- приложению требуется сверхнизкая задержка;
- данные неструктурированы или не имеют связей;
- требуется только сериализация и десериализация данных — JSON, YAML и т. д.;
- необходимо хранить огромные объёмы данных.
👉 @BackendPortal
Системный дизайн: Архитектура с одним сервером
Проектирование системы, способной обслуживать миллионы пользователей, — сложная задача. Это долгий путь, требующий постоянной доработки и непрерывного улучшения.
Обычно всё начинается с простого варианта: все компоненты работают на одном сервере.
Посмотрим, как проходит запрос:
> Пользователь обращается к api.mysite.com через веб-приложение или мобильное приложение.
> DNS преобразует доменное имя в IP-адрес 27.220.30.232.
> Запрос поступает на единственный веб-сервер.
> Сервер выполняет всё самостоятельно:
обрабатывает API-запрос;
выполняет бизнес-логику;
обращается к базе данных.
> Сервер отправляет пользователю HTML-страницу или JSON-ответ для дальнейшего отображения.
👉 @BackendPortal
Rate Limiting ≠ Throttling ≠ Backpressure
Эти три термина часто используют как взаимозаменяемые…
Но на самом деле они решают совершенно разные задачи масштабирования.
Вот самый простой способ их запомнить:
- Rate Limiting → ограничивает количество запросов, которые клиент может отправить.
- Throttling → ограничивает скорость обработки запросов системой, когда она находится под высокой нагрузкой.
- Backpressure → позволяет медленному потребителю сигнализировать быстрому производителю, чтобы тот снизил скорость и не перегружал систему.
Простая шпаргалка
- Rate Limiting = ограничение количества запросов.
- Throttling = замедление обработки.
- Backpressure = управление потоком данных.
Где используется каждый из подходов?
Rate Limiting
Используется в:
- API Gateway
- Публичных API
- Эндпоинтах авторизации
- Защите от злоупотреблений и DDoS-атак
Типичный ответ сервера:
HTTP/1.1 429 Too Many Requests
> Допустили ошибку в коммите? Вот как понять, что делать дальше.
Задайте себе вопрос: «Этот коммит уже попал в общий репозиторий?»
Если ДА → используйте git revert
- git revert создает новый коммит, который отменяет изменения предыдущего.
- Исходный коммит остается в истории.
- Команда всегда может увидеть, что именно было отменено и когда.
Если НЕТ → используйте git reset
- git reset удаляет коммиты так, будто их никогда не существовало.
- Переписывает историю проекта, перемещая указатель HEAD.
- Позволяет сохранить чистую и понятную историю Git до того, как изменения будут опубликованы.
👉 @BackendPortal
Создавайте первоклассную документацию для своего API или проекта.
Starlight предлагает всё необходимое: высокую скорость благодаря Astro, встроенную оптимизацию для SEO, доступность и поиск, а также поддержку Markdown, MDX и нескольких языков.
→ http://starlight.astro.build/es
👉 @BackendPortal
Прикол: большинство разработчиков до сих пор не знают, что такое вообще существует.
Буквально полноценный браузер Chromium можно запустить прямо в терминале 🤯
Он поддерживает WebGL и WebGPU, запускается примерно за секунду, работает с частотой до 60 FPS и практически не потребляет ресурсы процессора в режиме простоя. Браузер также работает по SSH без необходимости в оконном сервере, а ещё в нём можно смотреть YouTube прямо из терминала.
Да, YouTube действительно можно смотреть прямо в терминале.
https://github.com/fathyb/carbonyl
👉 @BackendPortal
Git: merge vs rebase
А что предпочитаете вы ?
👉 @BackendPortal
Ребят, тут Авито регистрацию на свой первый CTF открыл с призами до 300 000 рублей на команду 📍
AvitoTech устраивает CTF онлайн с денежным призовым фондом, мерчем и интересными тасками!
Регистрация команд уже открыта по ссылке, а ниже собрали инфу, что предстоит делать во время HoneyBadger CTF AvitoTech.
Возьмите на себя роль медоеда, проверьте защиту пчелиного улья и найдите все скрытые уязвимости в сотах.
Чего ждать от турнира: тасков на веб-уязвимости, инфраструктурных мисконфигов, анализа скомпилированного кода, расследования инцидентов, слабостей шифров, всего, что требует хакерской смекалки. И розыгрыша мерча, помимо основного призового фонда.
Важно: CTF не только для спецов по кибербезопасности — есть отдельная лига для всех, кто любит разбираться, как устроены IT-системы 🐝
Fable 5 монстр: чуваки создали невероятно лёгкий бэкенд, совместимый с Supabase, который работает как единый бинарный файл размером всего около 57 МБ!
Да, внутри уже есть полноценный PostgreSQL с RLS (Row-Level Security), а также встроенные Auth, Storage и Realtime.
https://tinbase.vercel.app/
👉 @BackendPortal
Запомни: Монолит ≠ Модульный монолит ≠ Микросервисы
Многие команды думают, что путь выглядит так:
Монолит → Микросервисы
Но между ними есть важный этап, который многие пропускают... Модульный монолит.
Вот самый простой способ запомнить разницу:
Монолит ➜ одна кодовая база, одно развёртывание, компоненты тесно связаны между собой.
Модульный монолит ➜ одно развёртывание, но кодовая база разделена на хорошо определённые модули с чёткими границами.
Микросервисы ➜ множество независимых сервисов, которые можно разрабатывать, развёртывать и масштабировать отдельно друг от друга.
Простая шпаргалка 👇
✅ Монолит = одно приложение
✅ Модульный монолит = одно приложение, много модулей
✅ Микросервисы = множество независимых приложений
Когда использовать каждый подход?
🔹 Монолит
стартапы и MVP;
небольшие команды;
быстрая разработка;
простое развёртывание.
🔹 Модульный монолит
растущие приложения;
команды, которым нужна чистая архитектура без сложности распределённых систем;
проще тестировать, сопровождать и развивать.
🔹 Микросервисы
большие инженерные команды;
независимое развёртывание сервисов;
разные требования к масштабированию отдельных доменов;
высокая доступность и масштабируемость организации.
Самое распространённое заблуждение. Микросервисы не становятся автоматически лучшим выбором.
Они привносят распределённые транзакции, сетевые задержки, обнаружение сервисов (service discovery), наблюдаемость (observability), версионирование, пайплайны развёртывания и дополнительные операционные издержки.
Во многих случаях грамотно спроектированный модульный монолит оказывается лучшим долгосрочным решением — до тех пор, пока бизнесу действительно не понадобятся распределённые сервисы.
Фраза, которую стоит запомнить
Монолит = простота
Модульный монолит = организованность
Микросервисы = независимость
Лучшая архитектура — не самая сложная, а та, которая решает сегодняшние задачи, не создавая завтрашних проблем.
Ищешь работу? Пусть отклики шлёт ИИ, а не ты.
Пока ты занят делами, агент откликается на hh.ru: до 200 вакансий в день с сопроводительными письмами — персональные, под твою вакансию и под требования работодателя.
Настроил, запустил один раз и забыл. 6000 откликов в месяц сделает за вас
Первые 2 часа — бесплатно.
Оцени результат сразу. Попробовать можно тут
Зачем нужен обратный прокси (Reverse Proxy)?
У вас есть API на Node.js.
Поначалу пользователи отправляют запросы напрямую в приложение, и всё работает отлично.
Но по мере роста проекта появляются новые задачи:
- использовать HTTPS;
- раздавать статические файлы;
- применять ограничение частоты запросов (Rate Limiting);
- масштабировать приложение.
Часть этих задач можно решить прямо в API. Но проблема в том, что тогда ему приходится выполнять две разные роли:
реализовывать бизнес-логику (пользователи, платежи, заказы и т. д.);
решать инфраструктурные задачи (HTTPS, раздача статики, Rate Limiting и т. д.).
По мере появления новых инфраструктурных задач становится логично отделить их от бизнес-логики.
Для этого между интернетом и вашим API добавляют дополнительный слой.
Этот слой называется обратным прокси (Reverse Proxy).
Он принимает входящие запросы и решает, что с ними делать: обработать их самостоятельно или перенаправить в API.
Интернет → Reverse Proxy → Ваш API
Одним из самых популярных решений для реализации обратного прокси является NGINX.
Главное преимущество такого подхода в том, что API может полностью сосредоточиться на бизнес-логике, а обратный прокси берёт на себя управление входящим трафиком до того, как он попадёт в приложение.
Недостаток заключается в том, что в архитектуре появляется ещё один компонент, который необходимо настраивать и поддерживать.
Однако по мере роста приложения такое разделение ответственности обычно значительно упрощает масштабирование и сопровождение системы.
👉 @BackendPortal