15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Короткая заметка про k8s:
Оказалось, что можно настраивать лимиты пропускной способности для пода или деплоймента. По умолчанию эта фича отключена. Но входящий и исходящий трафик можно контролировать через аннотации на поде, примерно так 😃
Кстати: M это Mbps, G это Gbps.
👉 @BackendPortal
Одна простая привычка, которая сильно упрощает поддержку Dockerfile, это сортировка многострочных списков пакетов по алфавиту.
На первый взгляд мелочь, но влияние на читаемость и будущую поддержку заметное.
Когда ставишь пакеты в многострочном apt-get install или apk add блоке, легко случайно добавить дубликат или пропустить что-то, что затерялось в середине списка.
Алфавитная сортировка полностью снимает этот вопрос. Список можно быстро просканировать, сразу увидеть дубли и держать всё в едином стиле на разных окружениях.
Плюс уменьшаются шумные диффы в код-ревью.
Когда пакеты отсортированы, добавление или удаление одного пункта выглядит как аккуратное и предсказуемое изменение.
Без сортировки маленькое обновление часто превращается в огромный diff, и ревью становится сложнее, чем должно быть.
Этот подход особенно полезен, когда команда растёт.
Несколько человек, трогающих один Dockerfile, не начинают перетасовывать строки под свой вкус или форматировать по-разному.
Структура остаётся стабильной, и поддержка со временем становится проще.
Небольшое улучшение, но на сотнях билдов оно экономит заметно нервов и времени.
👉 @BackendPortal
💧 А вы заметили, насколько сейчас сложнее устроиться на работу?
Да даже получать приглашение на техническое собеседование.
К примеру, на хх.ру при нормальном резюме после 100 откликов — ты должен получить минимум 4 приглашения от эйчар.
Если у вас меньше, то тут что-то не чисто.
И это я говорю, если мы будем откликаться на позицию мидл и сеньор, т.к. на джунов вакансий кратно меньше.
Один мой знакомый недавно проводил эксперимент на эту тему:
Он выложил вакансии на 3 разные позиции и посмотрел на всё это дело глазами HR, разобрал резюме кандидатов, а затем выложил ролик на свой ют канал.
Его зовут Вадим Новоселов - один из немногих, кто показывает рынок трудоустройства в IT изнутри.
В тг канале много авторского контента:
(тут) можно оставить своё резюме для прожарки на предстоящем стриме
(тут) гайд по трудоустройству за 3-4 месяца
(тут) подкаст о том, что будет с рынком айти в рф
Этот человек вкладывает душу в свой контент и проекты, советую подписаться и черпать для себя полезные фишки: @gernar288
Совет: всегда добавляй workflow_dispatch в триггеры workflow.
Так у тебя появится кнопка в UI GitHub, чтобы вручную запускать новые прогонки (когда CI, как обычно, развалится).
👉 @BackendPortal
Сообщество разработчиков объявило о выходе экспериментального CRDT-расширения для Postgres. Проект открыт и доступен для изучения и использования.
CRDT это тип данных, который применяется в приложениях с одновременным редактированием. Простой пример — Google Docs, где несколько пользователей могут печатать одновременно, а изменения автоматически объединяются без конфликтов.
Обычно такие структуры сериализуются на стороне сервера и только потом сохраняются в базу. Новое расширение меняет подход: теперь Postgres может работать с CRDT нативно — хранить, индексировать, искать и автоматически объединять изменения прямо в базе данных.
Авторы проекта показывают, как это может выглядеть в будущем:
create table blog_posts (
id uuid primary key,
title text,
body crdt default '{}'
);
Небольшая новость для тех, кто работает с PostgreSQL.
У Postgres есть официальное расширение для VS Code. Можно работать с базой прямо в редакторе без лишних тулз и переключений.
Что внутри:
- Визуализация схемы
- Поддержка агентов для взаимодействия с базой
- Метрики, аналитика и мониторинг
- Быстрый запуск PostgreSQL в Docker, если нужно локальное окружение
- Умный IntelliSense с учётом контекста базы: автодополнение, форматирование, подсветка синтаксиса
И это только основные фишки.
Кому интересно, вот расширение: тык
👉 @BackendPortal
Диграмма микросервисной архитектуры и связанных с ней паттернов
👉 @BackendPortal
В новой статье на Хабре Алексей Кременьков, бэкенд-разработчик в Яндекс 360, рассказывает о создании и эволюции сервиса динамического шардирования Sharpei для масштабирования PostgreSQL под нагрузкой в 300К+ RPS.
Пошагово разберём, как:
• Создали собственный инструмент для управления 700+ шардами PostgreSQL
• Справились с пиковыми нагрузками при миграциях
• Автоматизировали перенос пользователей между шардами и переехали в облако без даунтайма
Сервис Sharpei позволил Яндекс Почте перейти к гибкому горизонтальному масштабированию, полностью автоматизировать управление шардами и добиться четырёх девяток отказоустойчивости.
↘️ Подробнее читайте на Хабре
12 рекомендаций по дизайну API для бэкенд-разработчиков
(Их часто спрашивают на собеседованиях)
1. Понятные имена ресурсов
❌`GET /get-all-orders`
✅`GET /orders`
POST /users — создать пользователя GET /users/123 — получить пользователя PUT /users/123 — заменить полностью DELETE /users/123 — удалить POST /payments
Idempotency-Key: abc-123
GET /v1/products/42
GET /v2/products/42
❌ `200 OK { "error": "user not found" }`
✅ `404 Not Found`GET /articles?page=2&limit=50
GET /orders?status=shipped&sort=-created_at
Authorization: Bearer <token>
429 Too Many Requests
GET /blog/posts/123
ETag: "abc"
If-None-Match: "abc"
POST /auth/login
POST /sessions
Если честно, я всё чаще замечаю, что бэкенд-сообщество – невероятно разное. Здесь есть и те, кто только начинает разбираться в сервисах и базах, и те, кто уже пишет такие системы, которые держат на себе половину интернета. Но есть одна общая черта: хороших бэкендеров формирует не только практика, но и среда, в которой они находятся.
Мы растём быстрее, когда видим, как мыслят другие разработчики: какие решения принимают, какие компромиссы выбирают, как подходят к сложным задачам. И иногда одна чужая история или разбор может дать гораздо больше, чем длинные учебники или курсы.
Поэтому хочу поделиться небольшой папкой каналов, где собраны разработчики, которые по-разному мыслят, по-разному пишут и по-разному растут. Среди них есть те, кто ежедневно ковыряет продакшен, те, кто давно ушёл в архитектуру, и те, кто пробует силы в смежных направлениях.
Если вы работаете с бэкендом, то скорее всего, найдёте там что-то ценное для себя: идеи, подходы, вдохновение или даже ответы на вопросы, которые давно крутились в голове.
Хорошая среда делает нас сильнее 😎
SQL + SELECT = выбор данных
SQL + JOIN = объединение данных
SQL + WHERE = фильтрация
SQL + GROUP BY = агрегация
SQL + ORDER BY = сортировка
SQL + UNION = объединение запросов
SQL + INSERT = добавление записей
SQL + UPDATE = изменение данных
SQL + DELETE = удаление записей
SQL + CREATE TABLE = проектирование структуры
SQL + ALTER TABLE = изменение схемы
SQL + DROP TABLE = удаление таблицы
SQL + INDEX = ускорение запросов
SQL + VIEW = виртуальные таблицы
SQL + подзапросы = вложенные запросы
SQL + хранимые процедуры = автоматизация задач
SQL + триггеры = автоматические реакции на события
SQL + CTE = рекурсивные запросы
SQL + оконные функции = продвинутая аналитика
SQL + транзакции = целостность данных
SQL + ACID = надежные операции
SQL + хранилища данных = работа с большими объёмами
SQL + ETL = преобразование данных
SQL + партиционирование = работа с большими таблицами
SQL + репликация = высокая доступность
SQL + шардинг = масштабирование базы
SQL + JSON = полуструктурированные данные
SQL + XML = структурированные данные
SQL + безопасность данных = защита информации
SQL + оптимизация запросов = повышение производительности
SQL + управление данными = контроль качества данных
Вопрос:
try {
call_order_service();
call_inventory_service(); // уменьшаем остатки
} catch (Exception e) {
// лол, и что теперь? Заказ уже создан.
}
Разработчик ускорил загрузку сайта при работе в браузере ladybird почти в три раза. Время рендера сократилось примерно с одной секунды до четырёхсот миллисекунд.
Оптимизация получилась за счёт двух изменений:
- в HTTP-кеш добавили поддержку heuristic freshness lifetime в соответствии с RFC 9110 и 9111
- рендер теперь стартует только после получения всех CSS-импортов, так что эффект FOUC больше не появляется
👉 @BackendPortal
Заголовки безопасности сломали мобильное приложение
Никто не протестировал мобилку — и вот что получилось.
Что изменили
- Добавили security headers в API:
- Content-Security-Policy
- X-Frame-Options
- X-Content-Type-Options
- Strict-Transport-Security
- Почувствовали себя уверенно насчет безопасности
Что пошло не так
- Деплой в пятницу вечером
- Веб-приложение работало нормально
- Мобильное приложение полностью упало
- Данные не грузились
- Итог: инцидент на выходных
Расследование
- API показывал успешные запросы
- Логи мобильного клиента показывали ошибки
- Ответы: 200 OK
- Но мобильное приложение получало пустые данные
- Сетевой слой просто отбрасывал ответы
Виновник
- Content-Security-Policy
- Приложение использовало встроенный WebView
- CSP блокировал WebView при обработке ответов
- Браузерные правила безопасности применялись в мобильном контексте
- Хедер предназначен для браузеров, а не для API
Почему это пропустили
- Тестировали только веб
- Мобильная команда не была подключена к изменению
- Не было mobile testing в staging
- Предположили, что заголовки безопасны "по умолчанию"
- Не было feature-флагов для отката
Экстренный фикс
- Временно удалили CSP
- Горячий фикс в production
- Мобилка снова заработала
- Итого: 8 часов даунтайма
Правильное решение
- Разные заголовки для API и веба
- Логика на основе User-Agent
- Отдельная CSP-политика для мобильных клиентов
- Полное кроссплатформенное тестирование
- Feature-флаги для security-изменений
Урон
- Даунтайм: 2 часа
- Затронутых пользователей: 125 000
- Рейтинг в сторе: 4.7
Security headers не универсальны.
Тестируйте на всех платформах.
Web security и API security — разные вещи.
👉 @BackendPortal
⚡️ На Stepik вышел курс по Linux
Ребята сделали крутейший курс по Linux, где понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами обучают работе с этой ОС
Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой).
После прохождения вы получите сертификат, который можно добавить в резюме.
Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «LINUXTG25»: открыть курс на Stepik
AWS открыл бесплатный доступ к SimuLearn до 6 января!
✓ Реальные симуляции, чтобы прокачать навыки по облакам
✓ Без кредитки и без риска внезапных списаний
✓ EC2, NoSQL, архитектура, траффик под нагрузкой и другое
Один из топовых ресурсов:
→ ссылка
👉 @BackendPortal
Пиковый опыт разработки на TypeScript в бэкенде.
Определяешь маршрут, возвращаешь данные, всё полностью типобезопасно.
Типобезопасность тянется до фронтенда через RPC-подобный коннектор.
Документация по API генерируется для всех ответов.
OpenTelemetry заводится меньше чем за 10 строк.
Живём в интересное время.
Код тоже очень хороший, чувак написал его примерно за час.
https://github.com/SaltyAom/elysia-prisma-better-auth-example
👉 @BackendPortal
Еще одна книжка на полку. Пятое издание. Подборка статей, собранных Стоунбрейкером, Питером Бейлисом и Джозефом Хеллерстейном. PDF доступен бесплатно.
redbook.io/pdf/redbook-5th-edition.pdf
👉 @BackendPortal
Удаляйте ChatGPT. Вы не умеете им пользоваться.
Большинство пользователей спамит в ИИ всякую чушь — просят рассказать анекдот, изливают душу и используют как Гугл.
Российский тимлид OpenAI Вадим Петрич рассказывает в «Доктор GPT» как извлекать из нейронок максимум пользы. Это очень интересно:
• ТОП №1 нейросеть, генерирующая видео без цензуры вообще
• Готовые промты на все случаи жизни
• Инсайды и разработки от китов индустрии
Подпишитесь, с Доктором GPT нейронки станут инструментом роста, а не безделушкой:
/channel/+K65EHRh_x_c2OTli
Почему JSON жрет твой CPU
Твой API тупит. Ты думаешь что база медленная, сеть лагает. Но реальная пробка может быть в том формате, на котором всё общается.
JSON это не формат данных. Это текст.
Каждый раз, когда ты отправляешь {"id": 12345}, сервер платит скрытый "налог на парсинг". Даже самые быстрые парсеры вроде simdjson упираются в аппаратные ограничения, которых у бинарных форматов просто нет.
Разложим по технике.
1. Цена на CPU (state-machine против арифметики)
JSON (текст):
Чтобы прочитать число 12345, CPU получает сырые байты. Даже оптимизированный парсер должен пройти через state machine:
- искать структурные символы (: , { }).
- проверять escape-последовательности.
- а потом конвертировать строку в число:
цикл: взять char, вычесть '0', умножить накопленное на 10, прибавить.
Это прыжки в ветках, пропуски кеша, ситуации, где CPU просто ждет.
Protobuf (бинарный):
Отправляет Varint (для маленьких чисел) или фиксированный формат.
fixed32 => просто memcpy. Никакого парсинга.
Varint => читаешь байт, смотришь флаг в старшем бите (MSB), решаешь, идет ли число дальше.
Результат: несколько битовых операций. На нагрузках с большим количеством чисел бинарный формат фундаментально быстрее.
2. Стоимость по сети (энтропия против повторов)
JSON:
[
{"status": "active"},
{"status": "active"}
]
gzip всё решит!
gzip решает сеть, но ест CPU.
Ты правильно используешь Docker.?
Вот две вещи, которые СКОРЕЕ ВСЕГО ты упускаешь:
• У тебя Dockerfile в один stage. Это медленно.
• Ты почти не используешь кэширование слоев. Это тоже медленно.
Уже несколько лет Docker по умолчанию использует BuildKit как основной движок, и он поддерживает multi-stage Dockerfile.
Суть такая:
Обычный single-stage Dockerfile (скорее всего, у тебя как раз такой) заставляет каждый шаг зависеть от предыдущего.
Это значит:
• Все шаги выполняются строго последовательно
• Итоговый образ раздувается
• Любое изменение ломает кэш следующих слоев
• Нет шансов что-то реально распараллелить
Меняешь одну строку в начале Dockerfile = все слои после нее идут мимо кэша.
Есть вариант получше:
Начни использовать multi-stage сборки.
Парень записал видео, где сравниваю медленную single-stage сборку и быструю multi-stage.
Что нужно сделать:
Разбей Dockerfile на независимые стадии с помощью нескольких FROM. BuildKit построит граф зависимостей и будет гонять независимые стадии параллельно.
Плюсы тут такие:
Сборка станет намного быстрее. Параллельные стадии реально экономят кучу времени.
Кэширование будет намного эффективнее. У каждого stage свой набор слоев. Если что-то изменилось в build-стейдже, финальный stage не инвалидируется.
Итоговый образ будет чистым. Тебе не нужно тянуть туда тулчейн, компиляторы и временные файлы. В финальный образ копируется только то, что реально нужно.
Для меня это стало огромным апгрейдом того, как я пишу Dockerfile.
👉 @BackendPortal
Proxmox 9.1 теперь нативно поддерживает OCI-образы (Docker)
Proxmox VE 9.1 теперь поддерживает OCI-контейнеры на базе LXC, использует ядро Linux 6.17 и содержит улучшения в области виртуализации, безопасности и сетевых функций
Подробнее здесь
👉 @BackendPortal
С UUIDv7 в PostgreSQL 18 сортировка через ORDER BY теперь реально выдаёт записи в порядке их создания.
👉 @BackendPortal
Хочешь избежать проблем, когда Cloudflare падает?
Или когда La Liga блокирует твои страницы?
Разработчик сделал open-source CLI, чтобы можно было легко отключать этот сервис в проектах за пару секунд.
$ npx disable-cloudflare@latest
25 золотых правил системного дизайна
1. Система с упором на чтение
> Используй кэш (Redis/Memcached) для частых запросов вроде профилей пользователей
2. Низкая задержка
> Используй кэш и CDN (Cloudflare), чтобы раздавать статику ближе к пользователю
3. Система с упором на запись
> Используй Message Queue (Kafka) для буферизации большого объема записей (логи, аналитика)
4. ACID-требования
> Используй SQL (PostgreSQL) для строгих транзакций вроде банковских операций
5. Неструктурированные данные
> Используй NoSQL (MongoDB) для гибких схем, например каталогов товаров
6. Сложные медиа-ресурсы
> Используй Blob Storage (AWS S3) для видео, изображений и больших файлов
7. Сложные предварительные расчёты
> Используй Message Queue + Cache для асинхронной генерации контента (например ленты новостей)
8. Поиск при больших объемах данных
> Используй Elasticsearch для полнотекстового поиска и автокомплита
9. Масштабирование SQL
> Используй шардирование, чтобы разделить большие таблицы на несколько инстансов
10. Высокая доступность
> Используй Load Balancer (NGINX) чтобы распределять трафик и избегать перегрузки
11. Глобальная доставка данных
> Используй CDN для стабильного стриминга и раздачи контента по всему миру
12. Графовые данные
> Используй Graph DB (Neo4j) для соцсетей, рекомендаций и связей между сущностями
13. Масштабирование компонентов
> Используй горизонтальное масштабирование, а не просто апгрейд железа
14. Быстрые запросы к базе
> Используй индексы на ключевых колонках вроде email или user_id
15. Пакетные задачи
> Используй Batch Processing для отчётов, расчётов или периодических задач
16. Защита от злоупотреблений
> Используй Rate Limiter, чтобы предотвращать DDoS и спам запросов к API
17. Доступ к микросервисам
> Используй API Gateway для авторизации, маршрутизации и SSL-терминации
18. Единая точка отказа
> Добавляй Redundancy (Active-Passive), чтобы сервис продолжал работать при сбоях
19. Отказоустойчивость данных
> Используй репликацию (Master-Slave), чтобы данные не терялись при падении узлов
20. Реальное время
> Используй WebSockets для чатов, лайв-обновлений, лайв-результатов
21. Обнаружение сбоев
> Используй Heartbeat-пинг, чтобы проверять статус сервисов каждые несколько секунд
22. Целостность данных
> Используй Checksums (MD5/SHA) чтобы проверить, что загруженные файлы не повреждены
23. Децентрализованное состояние
> Используй Gossip Protocol, чтобы ноды обменивались статусами без центрального сервера
24. Эффективное кеширование
> Используй Consistent Hashing, чтобы добавлять или убирать кэш-ноды без полного пересчёта ключей
25. Работа с геоданными
> Используй Quadtree или Geohash для быстрых запросов вроде поиска ближайших водителей
Случайные UUID заметно просаживают производительность базы
Ты перешел с integer ID (1, 2, 3…) на UUID (a1b2-3c4d-…) ради безопасности или распределенной генерации.
И вдруг вставки стали медленнее. Иногда намного.
Причина простая - фрагментация индекса.
Большинство индексов в базах данных это B-деревья (сбалансированные сортированные структуры). Физическое расположение данных в индексе реально важно.
Последовательные ID
Когда ты вставляешь последовательные целые числа (1, 2, 3), новые записи всегда попадают в правую страницу листа индекса.
Все максимально предсказуемо:
- записи идут последовательно
- кэш работает эффективно
- страницы заполняются полностью
Это почти максимальная скорость, на которую способна твоя база.
Случайные UUIDv4
UUIDv4 генерируются равномерно случайно. Вставка может попасть в любое место структуры B-дерева.
Из-за хаотичного распределения:
База должна постоянно подгружать случайные страницы с диска в память. Это random I/O.
Page splitting: когда страница заполнена, ее приходится делить на две, оставляя обе наполовину пустыми.
Эффект "швейцарского сыра": индекс раздувается, полон дыр и плохо использует RAM и место на диске.
Когда размер индекса превышает доступную оперативку, пропускная способность записи может просесть на 20–90%.
UUIDv7
Хватит использовать UUIDv4 в качестве primary key. Переходи на UUIDv7 (стандарт RFC 9562).
UUIDv7 содержит timestamp в начале, так что значения становятся сортируемыми.
Что это дает:
Генерация без центрального счетчика
Вставки идут монотонно, почти как обычные последовательные числа
Фрагментация индекса исчезает
Защита от угадывания ID (хотя по ID можно понять время вставки)
Получается удобство UUID, но без потерь по производительности.
Короче, UUIDv7 норм. UUIDv4 не особо, если используешь как primary key.
👉 @BackendPortal
Большинство споров про Docker рано или поздно приходят к одному вопросу: slim или alpine, какой базовый образ выбрать?
Alpine очень маленький, выглядит привлекательно, если хочется сильно урезать размер образа. Но он использует musl вместо glibc, поэтому некоторые приложения ведут себя иначе, часть библиотек работает криво, а отладка может превратиться
Хороший вариант, если у тебя простое приложение или статический бинарник без кучи зависимостей на уровне ОС.
Slim-образы, вроде debian:slim или node:22-slim, больше Alpine, но всё ещё намного легче полноценных системных образов.
Они используют glibc, так что большинство тулов и библиотек работает нормально.
Обычно это означает меньше сюрпризов в проде, проще дебаг и лучше совместимость с документацией и примерами в сети.
Для большинства веб-приложений, API и инструментов slim = более безопасный выбор по умолчанию. Размер образа всё ещё небольшой, скачивается быстро, безопасность ок, и при этом не приходится ловить странные баги, связанные с musl.
Alpine имеет смысл, если ты:
поставляешь один статический бинарник
хорошо понимаешь свои зависимости
готов разруливать совместимость, если что-то поедет боком
🚀 Сначала запусти, а потом улучшай
Эту мантру знает каждый успешный фаундер. Главный риск в IT — застрять в перфекционизме и так и не выйти на рынок. Ценится скорость!
Яркий пример — челлендж «12 запусков за 12 месяцев» в комьюнити «Короче, Капитан». Вот как это работает у них:
⚡️Фокус. Берёте одну проблему с проверенным спросом. Никаких догадок.
⚡️Скорость и бюджет. Ровно месяц на разработку и запуск в США/ЕС. Средний бюджет на продвижение — всего $150.
⚡️Анализ. В конце месяца — честный разбор: что сработало, а что нет.
Вы в реальном времени видите запуск, продвижение и доход по каждому проекту. Идеальный способ прокачать насмотренность и перенять работающие подходы — даже если вы инженер, а не фаундер.
В будущем гарантированно набьете меньше шишек 💡
👉 Подписаться: @its_capitan
Когда нужно работать с данными в реальном времени, обычный HTTP не лучший вариант.
В HTTP клиент отправляет запрос, сервер отвечает и соединение закрывается. И важный момент: коммуникацию всегда инициирует клиент.
Для статей или обычных страниц это норм. Но если ты пишешь чат, такой подход развалится.
Придётся каждые пару секунд спрашивать сервер: "Есть новые сообщения?" Это грузит CPU, создаёт кучу лишних запросов и добавляет задержку. Такой подход называется polling.
Чтобы это решить, появился WebSocket.
Главная идея:
"Соединение остаётся открытым, и обе стороны могут общаться когда захотят."
Уменьшил размер Docker-образа с 2.1GB до 180MB. Деплой стал в 8 раз быстрее.
Как выглядел исходный Dockerfile:
Брался ubuntu:latest
Все ставилось через apt
В образ попадали дев зависимости
Копировалась вся директория проекта
Остались билд-артефакты
Не было оптимизации слоев
Pull занимал 6–8 минут
Хранилище в registry стоило дорого
Деплой тянулся слишком долго
Скан безопасности показал 47 уязвимостей
Большинство — из ненужных пакетов
Убрали дев зависимости
Использовали multi-stage build
В прод версию попали только нужные пакеты
Сначала копировали requirements
Устанавливали зависимости
Потом копировали исходники
Использовали кэш слоев Docker