15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Айтишники не рассказывают где учатся бесплатно и эффективно
Никому не говори об этом канале!!! В сфере онлайн образования появился новый гигант «TERMINAL» — который разрушит индустрию платных IT-курсов
Бесплатный доступ:
🔄Практические курсы и задания
🔄Книги и статьи от профи
🔄Полезные инструменты и ресурсы
🔄IT-новости и инсайды
Наш основной файл состояния Terraform весил 15 МБ. В нём была описана вся наша AWS-организация.
terraform plan занимал 20 минут и часто падал по таймауту.
Никто не хотел к нему прикасаться. Это был наш самый большой технический долг.
Рефакторинг занял 3 месяца:
- Инфраструктуру не меняли.
- Через terraform state mv переносили ресурсы из огромного state-файла в более мелкие логические (например, networking.tfstate, security.tfstate, app-foo.tfstate).
- Terragrunt использовали для оркестрации зависимостей между новыми маленькими state-ами.
Теперь план для одного приложения занимает 30 секунд. Наконец-то можно безопасно вносить изменения.
👉 @BackendPortal
API ускорили, трафик похудел
В продакшн завезли gzip-сжатие. Размер ответов упал примерно на 85%, а задержка почти на 60%.
До:
Средний ответ 240 KB
Передача ~400 мс
Трафик обходился в ~220 $ в месяц
После:
Средний ответ 36 KB
Передача ~48 мс
Трафик снизился до ~70 $ в месяц
Добавили compression middleware и сразу получили:
Загрузка быстрее на 88%
Минус 68% по расходам на пропускную способность
Маленькое изменение. Большая разница.
👉 @BackendPortal
Интенсив по очередям: Kafka & NATS
Асинхронное взаимодействие и очереди — невероятно широкая тема, и абсолютно обязательная к изучению всем, кто интересуется архитектурой. Разработчику важно понимать архитектурные особенности, сильные и слабые стороны компонент, на базе которых строится архитектура.
🌐 В программе курса:
▪️Асинхронное взаимодействие с помощью очередей: подходы, свойства, гарантии
▪️Какие бывают очереди, основные системы очередей, на какие свойства и требования смотреть при выборе
▪️Как конфигурировать и управлять системами очередей
▪️Архитектура Apache Kafka, streams, topics, конфигурации от минимального single instance до production grade кластера с отказоустойчивостью
▪️Архитектуры NATS, pub/sub, req/res, streaming, кластер, суперкластер, федерация, edge.
Всё в формате «живых» онлайн-сессий (лекции, брейнштормы, демо).
🥸 Кто мы: R&D-центр Devhands.io, наш канал. Автор курса — Владимир Перепелица, эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.
🗓 Старт курса 3 июля. Изучить программу и записаться можно здесь.
Ждём вас!
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqucQ8Rd
Реализовали ограничение API по IP. 1000 запросов в час на один IP. Идеальная защита от злоупотреблений.
Неделя спустя: легитимный клиент уперся в лимит. Пожаловался, что у них сервис сломался.
Они сидели за корпоративным NAT. 500 сотрудников делили один IP. Лимит кончился за 20 минут.
Переключили ограничение на API-ключ. Проблема решена.
Еще через неделю: бот-атака. 50 000 запросов в час. Разные API-ключи. Абьюз бесплатного тарифа.
Сделали ограничение и по IP, и по API-ключу. Проблема решена.
Еще через неделю: DDoS. 10 000 разных IP и 10 000 разных бесплатных API-ключей.
Rate limiting оказался бесполезен против распределенной атаки.
Настоящее решение:
Ограничение по IP для неавторизованных эндпоинтов
Ограничение по API-ключу для авторизованных эндпоинтов
Анализ поведения для поиска подозрительных паттернов
CAPTCHA для подозрительного трафика
CloudFlare спереди для защиты от DDoS
Лимиты по стоимости на бесплатный тариф
Нет одной универсальной стратегии rate limiting. Нужны слои. IP, пользователь, аккаунт, поведение и внешняя DDoS-защита.
👉 @BackendPortal
Это моя любимая статья про внутренности B-деревьев.
Джереми Коул работал с MySQL в Twitter, Google и Shopify. Один из самых прошаренных MySQL-инженеров в мире, а его блог просто кладезь полезной инфы.
👉 @BackendPortal
Векторные базы данных простыми словами
Представь, у тебя есть 10 000 описаний товаров. Пользователь ищет "удобная уличная мебель".
Обычная база данных:
Ищет точные совпадения слов
Находит товары с "удобная" ИЛИ "уличная" ИЛИ "мебель"
Пропускает "уютные кресла для террасы", хотя это то же самое
Ключевые слова — тупой способ поиска
Векторная база данных:
Превращает запрос в набор чисел, отражающих смысл: [0.2, 0.8, 0.1, 0.9, ...]
Каждое описание товара тоже превращается в такие числа
Сравнивает эти "векторы" и ищет похожие по смыслу
Находит "уютные кресла для террасы", потому что векторы похожи
Смысловой поиск — умный поиск
Как это работает
Шаг 1. Превращаем текст в векторы (массивы чисел)
"comfortable chair" → [0.2, 0.7, 0.1, 0.4, ...]
"cozy seat" → [0.3, 0.8, 0.2, 0.5, ...]
Похожие фразы → похожие числа
Это делает AI-модель, например OpenAI embeddings
Шаг 2. Храним векторы
В обычной БД хранят текст
В векторной — массив чисел для каждого объекта
Индексируют их, чтобы быстро искать по схожести
Оптимизировано под "найди похожие", а не "найди точное"
Шаг 3. Ищем по схожести
Запрос: "outdoor furniture"
Превращается в [0.3, 0.6, 0.2, 0.8, ...]
Система ищет ближайшие векторы (через cosine similarity)
Результаты сортируются по степени похожести
Где это используется:
- Поиск товаров, который понимает смысл, а не только слова
- Поиск по документации, который находит релевантные ответы
- Рекомендательные системы
- Чатботы, ищущие похожие вопросы
- Обнаружение аномалий
Популярные векторные базы
Pinecone = управляемая, простая, но дорогая
Weaviate = опенсорс, с кучей функций
Milvus = быстрая и масштабируемая, но сложная
pgvector = расширение для Postgres, простое и удобное
Qdrant = быстрая, написана на Rust
Спорная, но практичная мысль
В большинстве проектов тебе не нужна отдельная векторная база.
Начни с Postgres + pgvector = этого хватает, пока у тебя меньше 1 миллиона векторов.
Когда масштаб вырастет, тогда уже смотри в сторону специализированных решений.
👉 @BackendPortal
👩💻 В сеть вывалилась гигантская куча курсов и книг
Держи сотни гигабайт свежих уроков, и каждую неделю мы подкидываем ещё!
• 1612 ГБ — DevOps
• 1402 ГБ — Python
• 1300 ГБ — C, C++
• 1815 ГБ — Frontend
• 1515 ГБ — Backend
• 898 ГБ — ИБ, Хакинг
• 996 ГБ — Kotlin, Swift
• 212 ГБ — JavaScript
• 315 ГБ — Flutter
• 820 ГБ — Go, PHP
• 419 ГБ — Java, Rust
• 648 ГБ — GameDev
• 517 ГБ — Windows, Linux
• 998 ГБ — Дизайн (UX/UI)
• 617 ГБ — Нейросети (ML/RL)
• 546 ГБ — БД (SQL & NoSQL)
• 687 ГБ — Аналитика данных
• 115 ГБ — QA-тестирование
Подписывайся и не плати за то, что можно получить бесплатно
Программисты, откопал вам годноту для прокачки алгоритмов: визуальный тренажёр с пошаговым выполнением кода
70+ алгоритмов на JavaScript, Java и C++, всё интерактивно и с наглядной визуализацией
Забираем здесь 🍯
@linuxos_tg
У тебя микросервисная архитектура. OrderService должен дать сигнал EmailService, чтобы тот отправил письмо. Ты поднимаешь простую очередь - Redis или RabbitMQ. OrderService пушит задачу, EmailService её читает. Всё вроде бы работает.
Потом появляется AnalyticsService, которому тоже нужно знать об этом заказе. Но уже поздно, ведь EmailService прочитал и удалил сообщение. Тогда ты добавляешь костыль: OrderService пишет сразу в две очереди. Потом приходит FraudService и теперь уже три. В итоге OrderService превращается в хрупкий, связанный узел, от которого всё зависит.
Ты слышал про Kafka и думаешь: «Да это просто очередь, только сложнее». Но нет. Kafka это не очередь, а лог. И вот это всё меняет.
В обычной очереди, как в RabbitMQ, сообщение живёт как таска в туду-листе. Консьюмер его забирает, и оно исчезает. Если сервис упал то сообщение потеряно, если не строить сложный retry. И только одна группа консьюмеров может получить сообщение.
В Kafka всё иначе. Сообщения это события, которые не удаляются после чтения. Они публикуются в топик, например all-orders, и записываются в файл, как в git-лог, в порядке поступления. Эти данные устойчивы и защищены от сбоев по умолчанию.
Самое интересное начинается, когда понимаешь, что консьюмеры ничего не "вытаскивают". Они просто читают лог, начиная с определённого offset. EmailService читает лог, AnalyticsService читает тот же лог, только в своём темпе, FraudService тоже. Каждый в своей consumer group, и Kafka это не волнует. OrderService просто один раз "кричит в пустоту" и не заботится, кто услышит. Всё максимально развязано.
А теперь представь, что EmailService упал. Всё равно не страшно, ведь сообщение осталось в логе. После перезапуска он продолжит читать с того места, где остановился. Потерь нет. Потом ты выкатываешь новый RecommendationService с ИИ и говоришь ему: «Начни с начала топика all-orders, прочитай последние полгода истории и построй модель». Он спокойно переигрывает прошлое. С очередью так сделать нельзя.
Kafka это не message bus. Это распределённый, отказоустойчивый и постоянный источник истины для всей компании. По сути, центральная нервная система современного бизнеса, который живёт на данных.
👉 @BackendPortal
Производство упало. Health-чеки балансировщика валятся. Все инстансы помечены как unhealthy.
Зашёл по SSH на инстанс:
Приложение: запущено
CPU: 5%
Память: 40%
Диск: 15%
Сеть: ок
Ручной запрос к health-эндпоинту:
curl localhost/health
{"status": "ok"}
Health-check URL: /health
timeout
⚡️ На Stepik вышел курс по Linux
Ребята сделали крутейший курс по Linux, где понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами обучают работе с этой ОС
Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой).
После прохождения вы получите сертификат, который можно добавить в резюме.
Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «25LINUX»: открыть курс на Stepik
Вчера пробовал cloudflared от Cloudflare, чтобы пробросить локально запущенное API для теста интеграции с GitHub — честно, 10/10.
Даже аккаунт Cloudflare не нужен.
Установил пакет и запустил:
cloudflared tunnel --url http://localhost:8000
Когда backend dev сделал frontend
- он отзывчивый из коробки
- загружается за 0,00004 секунды
👉 @BackendPortal
Оптимизировали Docker-образ: минус 540 МБ!
Ужали размер образа с 588 МБ до 47.7 МБ — почти в 12 раз меньше.
Что сделали:
- Перешли на Python 3.9-alpine — лёгкий и быстрый базовый образ.
- Объединили RUN-инструкции, чтобы не плодить лишние слои.
- Добавили .dockerignore, чтобы не тянуть в сборку кеши и временные файлы.
- Перешли на multi-stage build: на выходе только то, что реально нужно в проде.
Результат:
Образ стал на 91.89% меньше
Контейнеры стартуют быстрее
Деплой стал легче, а сборка — быстрее
Каждый мегабайт экономии ускоряет процесс. Мелочи, но складываются в ощутимую разницу.
👉 @BackendPortal
Пентестер получил root-доступ к нашему Kubernetes-кластера за 15 минут. Вот что он эксплуатировал.
Цепочка атаки:
- Нашёл открытый Kubernetes Dashboard (это наш косяк)
- На Dashboard был service account только с view-доступом (мы считали это безопасным)
- Service account мог читать Secrets во всех namespaces
- В одном из Secrets были AWS-креды
- С этими кредами получил доступ к EC2 instance profile
- Instance profile имел полный Kubernetes admin через IAM
- Через kubectl поднял привилегированный pod
- Сделал escape на node
- Root-доступ ко всему кластеру
Что мы думали сделали правильно:
- Dashboard был read-only
- Secrets были зашифрованы at rest
- NetworkPolicy настроены
- Регулярные безопасности обновления
Что мы упустили:
- Dashboard вообще не должен быть доступен снаружи
- Service accounts должны работать по принципу наименьших привилегий
- Secrets не должны хранить AWS-креды (нужен IRSA)
- Pod Security Policies не были включены
- Узлы не были достаточно защищены
Исправление заняло 2 недели:
- Полностью убрали Kubernetes Dashboard
- Внедрили IRSA для всех pod'ов, которым нужен доступ к AWS
- Включили строгие PSP / Pod Security Standards
- Провели аудит всех RBAC-разрешений
- Регулярные пентесты
Стоимость: 24K $ за пентест
Ценность: предотвратили потенциально катастрофический взлом
👉 @BackendPortal
⚡️ Запускаем крупный розыгрыш призов, где можно выиграть iPhone 17, игровые наушники, клавиатуру и мышь!
Без лишних слов, условия:
1. Подписка на:
— бизнестрендс
— Технотренды
— Блумберг
2. Нажать кнопку «Участвовать» снизу
Итоги будут опубликованы 15 ноября в 18:00 на наших каналах, желаем удачи!
Foreign keys и constraints. Многие путают эти понятия.
Foreign key: столбец, который устанавливает связь между двумя таблицами. Обычно это столбец в одной таблице, который хранит значения первичного ключа из другой таблицы , чтобы можно было соединить их в запросе.
Foreign key constraint: механизм, который заставляет СУБД контролировать целостность внешних ключей. Он гарантирует, что значения во внешнем ключе (post -> user_id) ссылаются на реальную запись в другой таблице (user -> id).
Constraints это полезная фича (помогает с той самой буквой C в ACID), но за удобство приходится платить. Вставки, обновления и удаления на таблицах с constraints требуют дополнительных вычислений и IO для проверки.
Если их убрать, можно ускорить систему, но тогда ответственность за поддержание связей перекладывается на сторону приложения. Приложение должно гарантировать, что после транзакций отношения между данными остаются валидными.
Базы данных, как мир бесконечных компромиссов. 🚬
👉 @BackendPortal
Большинство проблем с производительностью возникают не из-за плохих запросов.
А из-за кривых таблиц.
Каждый CREATE TABLE это решение, которое потом аукнется:
• типы данных
• индексы
• ограничения
• партиционирование
Мой друг Рауль, собрал то, чему его научили годы проектирования и перепроектирования баз.
Почему реальная производительность начинается именно со схемы.
Читать тут → ссылка
👉 @BackendPortal
Last Call: не пропусти Wink AI Challenge — первый в России ИИ-хакатон в киноиндустрии. Создай своё решение, которое ускорит производство фильмов и сериалов. Призовой фонд — 1 125 000 рублей.
Регистрация открыта до 4 ноября: https://cnrlink.com/winkaichallengebackport
Приглашаем ML-инженеров, backend- и frontend-разработчиков, DevOps, MLOps и мультимедиа-инженеров.
Главные причины присоединиться:
🔸 Работа с настоящими сценариями и материалами, анализ текстов, извлечение сущностей, генерация структуры съёмок.
🔸 Практика применения NLP, NER и мультимодальных данных в задачах кинопроизводства.
🔸 Разработка ИИ-сервиса, который оценят и будут использовать продюсеры популярных российских фильмов и сериалов.
🔸 Реальный кейс в портфолио, созданный специально для крупнейшего онлайн-кинотеатра.
🔸Финалисты отправятся в Москву — Wink оплатит билеты и проживание.
Успей зарегистрироваться на первый в России хакатон по применению ИИ в кинопроизводстве: https://cnrlink.com/winkaichallengebackport
Совет по Docker
Как понять, что раздувает образ
Любой Docker-образ состоит из слоев.
Каждая строка в Dockerfile добавляет новый слой.
По этим слоям можно понять, почему образ получается большим, долго собирается или плохо кешируется.
Вот как посмотреть слои и узнать, что именно менялось в каждом из них.
Используй утилиту dive.
Она показывает наглядно:
- какие слои созданы
- какие файлы добавлены или изменены
- сколько места занимает каждый слой
Когда начинаешь изучать слои образа, можно быстро выяснить:
• какая команда в Dockerfile добавляет лишний вес
• как оптимизировать сборку, чтобы образ был меньше и собирался быстрее
Dive также дает оценку «эффективности» образа. Она показывает, насколько много данных дублируется или просто впустую занимает место в слоях.
👉 @BackendPortal
Платежи не дают второго шанса.
Вот решение, которое стояло перед Марко
Большинство инженеров в первую очередь выбирают скорость.
А потом месяцами пилят возвраты, джобы для сверки и устраняют последствия.
Но платежам плевать на «низкую задержку».
Им важно одно и это не списывать деньги дважды.
Перед ним были такие варианты:
A → Строгая консистентность
Хранить сгенерированный клиентом idempotency key и финальный ответ в надежной БД.
Уникальное ограничение отсекает дубликаты.
Аудируемо. Правильно. Чуть медленнее.
B → Хак с Redis и TTL
SETNX-лок → обработка → кеширование результата.
Очень быстро… пока Redis не перезапустится, TTL не сгорит раньше времени или не случится разделение сети.
И вот ты уже списал деньги дважды и несколько дней «разбираешься».
C → Вера в магию Kafka
Публикуешь событие и надеешься на “exactly-once” в стриме.
Но в платежах корректность нужна до того, как ты возвращаешь успех.
Это решает масштаб, но не ответственность.
D → Починим потом
Позволяешь двойным списаниям происходить.
Потом проводишь аудит, делаешь возвраты, извиняешься и тд
Дешево в реализации. Дорого в доверии.
Марко выбрал A.
Потому что «быстрые» варианты становятся самыми дорогими, когда в игру вступают реальные деньги.
В финтехе побеждает корректность. Всегда.
Задержка раздражает, но двойное списание уничтожает доверие.
👉 @BackendPortal
Структура данных B-Tree реально крутая штука. Базы данных используют B-деревья для хранения данных на диске, разбивая всё на страницы , обычно по 4–8 КБ. Все операции ввода-вывода происходят именно с этими страницами как единицами.
Как устроена страница
Один из популярных способов организовать данные внутри страницы, называется slotted page structure.
Она начинается с заголовка, за ним идут указатели на ячейки, которые ссылаются на ячейки данных в конце страницы.
Пока ты добавляешь данные:
указатели растут слева направо,
а сами ячейки растут справа налево,
встречаясь где-то посередине.
Эта середина — формально "свободное место", но прикол в том, что оно может содержать что угодно. Страница и всё дерево вообще не заботятся, что там лежит.
Если на эти байты нет указателей, они просто не существуют для дерева. Там может быть мусор из прошлых операций, но он не читается и не используется.
Буферный пул и «грязные» страницы
Базы данных ещё поддерживают buffer pool, это кэш страниц, загруженных с диска. Эти страницы часто переиспользуются.
И вот тут появляется интересная оптимизация:
вызов memset (который обнуляет память) занимает время, поэтому базы часто вообще не затирают старые данные.
Удаление записи это просто удаление указателя, но данные на диске остаются.
В итоге, старый мусор из памяти может снова попасть на диск, хотя уже не используется. Ни одна другая структура данных, кажется, так не делает.
Зарезервированное место в конце страницы
Помнишь, я говорил, что ячейки растут справа налево?
Если ты специально оставишь немного свободного места в конце страницы до начала области ячеек, B-дерево продолжит работать как ни в чём не бывало.
Эта область не используется самим деревом, и в неё можно записывать что угодно.
SQLite использует этот трюк для фичи reserved space.
Расширения могут сохранять свои данные прямо в каждой странице, не ломая работу дерева.
Например, туда пишут метаданные для шифрования или контрольных сумм.
Кстати, у SQLite есть настройка PRAGMA secure_delete, которая при удалении затирает содержимое нулями, чтобы мусор не утёк никуда , это уже для безопасности.
Если коротко: B-Tree не просто эффективная структура, она ещё и невероятно продумана для работы с реальным диском, где каждая операция чтения и записи стоит дорого.
👉 @BackendPortal
Через 2 дня заканчивается регистрация на Yandex Cup 2025 — 8-й международный чемпионат по программированию с призовым фондом в 12 млн рублей.
В этом году участники смогут попробовать силы в шести направлениях: аналитика, фронтенд, бэкенд, мобильная разработка, а также в двух международных треках — «Алгоритм» и машинное обучение, которые будут доступны на русском и английском языках. Присоединиться могут как юниоры 14-18 лет из России, так и взрослые программисты со всего мира.
Регистрация и пробный тур открыты до 29 октября, квалификация пройдет 2 ноября. Отборочный тур по ML продлится до 5 ноября.
Финал состоится 5-7 декабря в Стамбуле. Он будет посвящен искусству древних мастеров. Разработчикам предстоит продолжить философию крафта в коде.
Подать заявку можно на сайте чемпионата до 29 октября
👩💻 IT теперь в Telegram!
Программисты и TechLead'ы из FAANG создали этот канал для обучения их стажёров и джунов, чтобы подготовить их к работе в топовых компаниях.
Курсы, новости, гайды, советы, мемы, книги — всё, что входит в дневной рацион разработчика.
Забирай доступ: @it_matrix
Kite — это современная лёгкая панель управления для Kubernetes, которая предоставляет метрики в реальном времени, поддерживает работу с несколькими кластерами, редактирование YAML и управление ресурсами через удобный интерфейс.
➜ https://ku.bz/95jvldnx_
👉 @BackendPortal
Пользователь сообщил: "Поиск работает медленно." Результаты вернулись за 8 секунд.
Кластер Elasticsearch был в порядке. Запрос оптимизирован. Индексы — здоровые.
Я проследил весь запрос от начала до конца:
Frontend → API: 45 мс
API → Elasticsearch: 180 мс
Запрос в Elasticsearch: 220 мс
API → Frontend: 7 480 мс
API сериализовал 50 000 результатов в JSON до пагинации.
Забирал все результаты
Конвертировал в JSON
Отправлял всё на фронт
Фронт показывал 10 элементов
Фикс: делать пагинацию на уровне Elasticsearch, а не в API.
Новый отклик: 312 мс.
База данных не была медленной. Разработчик просто неправильно понял, где нужно делать фильтрацию.
👉 @BackendPortal
#вакансия #удаленка #fulltime #backend
Backend Engineer (Nodejs + Python) — сначала быстро, потом
Мы делаем продукт для BTC-майнинга. Пишем веб-бэкенды на Node.js + Python, гоняем клиентский трафик и телеметрию, храним метрики в Clickhouse, биллинг в Postgres. Нам нужен человек, который быстро доставляет ценность, не боится грязных MVP и умеет превращать их в чистые, наблюдаемые сервисы.
Формат:
- Full-time, remote-friendly (UTC±2 ок).
- Язык: RU на уровне команды.
- Техническая команда: веб-фулстэк, Rust-бэкенд, CTO.
- Решения принимаем быстро, мерджим часто, катим сразу, рефакторим планово.
- Вилка: $3000-$6000
Чем заниматься:
- Проектировать и делать веб-API (REST/WebSocket) для кабинета и админки: биллинг, выплаты, нотификации, вспомогательные сервисы.
- Интеграции: Clerk (auth, impersonation), Postgres (RLS, миграции), ClickHouse (агрегаты статистики), Redis (кэш/lock), R2/S3 (CDN).
- Наблюдаемость: метрики/логи/трейсинг, дашборды и алерты (Prometheus/Grafana/Loki).
- Производительность: индексы, EXPLAIN, профилирование, backpressure.
Технологии (основное):
- Node.js (TypeScript, Express/Nest/Fastify), Python (FastAPI/aiohttp), async I/O.
- Postgres (SQL, триггеры и хранимки, индексы, планировщик), ClickHouse, Redis
- Docker, GitHub Actions.
- Линтеры/тайпчекеры: ESLint/Prettier, ruff/black/mypy, pyright.
Как мы работаем («быстро на костылях → потом нормально»):
- Спринт 1–3 дня: узкий MVP, минимум слоёв, прямые SQL/SDK, фича-флаг, happy-path e2e.
- Дожим после релиза: типизация, валидация (Pydantic/Zod), идемпотентность, ретраи с backoff, метрики, алерты, интеграционные тесты, миграции и docs (короткие ADR).
- В PR ждём: чёткие таймауты, поведение при ошибках, метрики и лог-ключи для дебага.
Требования (must-have):
- 4+ лет в бэкенде, реально продуктивен в Node.js и/или Python, готов работать в обоих.
- Сильный SQL/Postgres: индексы, EXPLAIN, блокировки, миграции; понимаешь, где узкие места.
- Асинхронщина, очереди, кэш, идемпотентные API, ретраи/таймауты/backoff, at-least-once/дедуп.
- Наблюдаемость как привычка: метрики до кода, лог-корреляция, дешёвые SLO.
- Умение быстро «прибить костыль» и потом довести до прод-качества.
Будет плюсом:
- ClickHouse, высоконагруженная телеметрия.
- Понимание домена: финтех, крипто.
- Pulumi, Prometheus/Grafana/Loki.
- Supabase (RLS), Clerk, R2/S3.
Что считаем успехом (30/60/90):
- 30 дней: 3–4 фичи в проде, метрики/алерты на свои сервисы, первое снятие узкого места (индекс/кэш).
- 60 дней: закрыт e2e «регистрация → начисления → баланс», выплаты в sandbox, стабилизирован оффлайн-детект.
- 90 дней: берёшь end-to-end зону (Billing или Notifications), выжигаешь технический долг v0, покрытие интеграционными тестами ≥60% на своём коде, минус 3 главных перф-бутылочных горлышка.
Кому точно к намЖ
- Ты делаешь PR в тот же день, не ждёшь идеального ТЗ.
- Тебя не пугает переписывать свой код через неделю, если так быстрее для бизнеса.
- Любишь цифры: latency, error-rate, p95, RPS — не «где-то там», а в твоём дашборде.
Кому лучше не к нам:
- Нужен «архсовет на 6 встреч» перед Hello World.
- Болит от временных решений и фича-флагов.
- Не готов брать на себя поддержку того, что выкатил.
Процесс найма:
- Выполнение тестового задания.
-60 мин созвон: разбираем тестовое задание, короткий deep-dive по одному твоему проекту (где ты сначала сделал «как попало», а потом правильно).
Финальное собеседование с CEO.
-Как откликнуться: пришлите 1–2 ссылки на репо/PR + 3–5 предложений про ваш «костыль → нормальное решение» (какие компромиссы, какие метрики улучшили).
— Готовы «возить углём» и шипить быстро? Поговорим.
Telegram: @dishsh
Docker это не мини-виртуальные машины
Многие пользуются Docker каждый день, но не особо понимают, что происходит под капотом. Это становится очевидно, когда начинаются проблемы с производительностью, правами доступа или сетью.
1. Docker — это не виртуалка
Когда ты запускаешь docker run ubuntu, ты не создаешь «мини-компьютер».
Никакого нового ядра нет.
Контейнер использует то же ядро, что и хост — просто в изоляции.
Поэтому он стартует за миллисекунды и ест меньше оперативки, чем виртуальная машина.
2. Изоляция достигается через namespaces
Namespace говорит системе:
«Этот процесс видит только вот этот кусочек мира».
Примеры:
PID namespace — контейнер думает, что его процесс 1 — единственный.
NET namespace — у контейнера своя сеть и интерфейсы.
MNT namespace — своя файловая система с примонтированными ресурсами.
Так несколько контейнеров могут спокойно жить рядом, не мешая друг другу.
3. Cgroups ограничивают ресурсы
Контейнер может считать, что владеет всей машиной…
но control groups (cgroups) ставят реальные лимиты:
- максимум CPU (--cpus=2)
- максимум памяти (--memory=1g)
- лимиты на I/O или количество процессов
Если контейнер пытается выйти за рамки, ядро его просто отрубает 😅
4. Файловая система и слои (UnionFS)
Образ это не один файл, а набор слоев.
Каждая инструкция RUN, COPY или ADD в Dockerfile создает новый слой.
Когда контейнер запускается, поверх монтируется временный слой для записи.
Вот почему все изменения исчезают после удаления контейнера —
временный слой просто выкидывается.
5. Как контейнеры общаются между собой
Docker создает виртуальные сети внутри хоста.
Каждый контейнер получает свой внутренний IP.
Когда ты используешь --link или docker-compose,
ты просто задаешь внутренние DNS-имена.
Во внешний мир трафик не выходит,
пока ты сам не пробросишь порт через -p 8080:80.
6. Безопасность -изоляция не идеальна
Поскольку ядро общее, защита не такая жесткая, как у виртуалки.
Для этого и придуманы штуки вроде:
gVisor — песочница для системных вызовов
SELinux или AppArmor
rootless Docker
Если запускаешь сторонние контейнеры — лучше использовать их.
Так что же такое Docker на самом деле?
Это оркестратор изоляции:
- прячет ресурсы через namespaces
- ограничивает их через cgroups
- управляет файловой системой через UnionFS
- эмулирует сеть через network namespaces
Он ничего не эмулирует по-настоящему,
он просто создает очень правдоподобную иллюзию 👏
Понимание этого полностью меняет подход к дебагу и оптимизации.
Контейнер жрет всю оперативку? → смотри cgroups.
Не может подключиться к сети? → проверь network namespace.
Билды весят по 5 ГБ? → разбери слои образа.
👉 @BackendPortal
Паттерны микросервисов для Backend-разработчиков
Для backend-разработчика знание паттернов микросервисов — это базовый навык.
Он делает тебя сильнее как инженера и помогает уверенно проходить собеседования.
Сохрани, выучи и применяй, и ты будешь на шаг впереди остальных.
🔸Application Architecture Patterns
Высокоуровневые схемы структуры систем:
- Monolithic architecture
- Microservice architecture
🔸 External API Patterns
Подходы к проектированию API для сторонних разработчиков:
- API Gateway
- Backends for Frontend (BFF)
🔸Decomposition Patterns
Как разделить большую систему на независимые сервисы:
- Decompose by business capability
- Decompose by subdomain
🔸Testing Patterns
Подходы к проверке корректности микросервисов:
- Consumer-driven contract test
- Consumer-side contract test
- Service component test
🔸Messaging Style Patterns
Схемы асинхронного взаимодействия сервисов:
- Messaging
- Remote Procedure Invocation (RPI)
🔸Security Patterns
Решения для аутентификации и авторизации:
- Access Token
🔸Reliable Communication Patterns
Техники обработки сбоев при взаимодействии сервисов:
- Circuit Breaker
🔸Cross-cutting Concerns Patterns
Обработка общих функций вроде логирования и метрик:
- Externalized Configuration
- Microservice Chassis
🔸 Service Discovery Patterns
Как сервисы находят друг друга в сети:
- 3rd Party Registration
- Client-side Discovery
- Self-registration
- Server-side Discovery
🔸Observability Patterns
Как понять, что происходит внутри системы:
- Application Metrics
- Audit Logging
- Distributed Tracing
- Exception Tracking
- Health Check API
- Log Aggregation
🔸Transactional Messaging Patterns
Обеспечение согласованности данных между сервисами:
- Polling Publisher
- Transaction Log Tailing
- Transactional Outbox
🔸Deployment Patterns
Подходы к безопасному релизу новых версий сервисов:
- Deploy as Container
- Deploy as VM
- Language-specific Packaging
- Service Mesh
- Serverless Deployment
- Sidecar
🔸Data Consistency Patterns
Как управлять целостностью данных в распределённых БД:
- Saga
🔸Business Logic Design Patterns
Как организовать доменную модель и бизнес-логику:
- Aggregate
- Domain Event
- Domain Model
- Event Sourcing
- Transaction Script
🔸Refactoring to Microservices Patterns
Как поэтапно мигрировать монолит в микросервисы:
- Transaction Script
- Strangler Application
🔸Querying Patterns
Как извлекать данные из нескольких сервисов:
- API Composition
- CQRS (Command Query Responsibility Segregation)