14390
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Как грамотно структурировать Kubernetes-проект?
Если у тебя куча .yaml файлов валяется в одной папке — не беда. Но пора наводить порядок. Вот как делаем правильно:
1. Вынеси общие манифесты (deployment, service, ingress и т.д.) в папку base/
2. Для каждого окружения (dev, staging, prod) создай папку с переопределениями (overlays/dev, overlays/prod и т.д.)
3. Используй Kustomize, чтобы не копипастить .yaml, а нормально патчить нужные поля
4. Подключай Helm — шаблонизация, переменные и всё, что нужно для удобного управления
👉 @BackendPortal
Объясняем разницу
👉 @BackendPortal
12 алгоритмов для собеседований по проектированию систем
1. Bloom Filter
Снижает издержки на поиск
2. Geohash
Сервисы, основанные на геолокации
3. HyperLogLog
Оценка количества уникальных элементов
4. Консистентное хеширование
Распределение объектов данных в кластере
5. Дерево Меркла
Выявление несоответствий между узлами
6. Raft Algorithm
Алгоритм консенсуса в базах данных
7. Lossy Count
Эффективный подсчёт частоты элементов
8. Квадродерево
Сервис на основе геолокации
9. Оперативная трансформация
Используется для совместного редактирования
10. Протекающее ведро
Используется для ограничения скорости в API
11. Rsync
Синхронизация файлов и каталогов между устройствами
12. Ray Casting
Обнаружение столкновений, рендеринг компьютерной графики
👉 @BackendPortal
Запоминаем HTTP-коды по котикам
http.cat — это галерея HTTP-статусов в виде котиков. Да-да, код ответа от сервера + соответствующий котик — и вуаля, скучная разработка превращается в мемчик.
Есть ещё httpstatusdogs.com — та же идея, но вместо котов — собаки 🐶
Но ты сам понимаешь... интернет больше котиков любит 🥰
👉 @BackendPortal
𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆 №𝟭 для улучшения производительности вашего приложения
Это — кэшировать (почти) всё! Кэширование сохраняет копии часто запрашиваемых данных в легко доступном месте, сокращая время доступа и снижая нагрузку на основные источники данных.
Преимущества кэширования — более быстрое получение данных, меньшая нагрузка на основные хранилища и улучшение пользовательского опыта.
Не ограничивайтесь кэшированием только запросов к базе данных, так как чтение из кэша значительно быстрее, чем вызов API.
Как решить, стоит ли что-то кэшировать? Лучше спросить себя: а почему это НЕ стоит кэшировать? 🤔
Использование кэша несёт затраты, поэтому для каждого кандидата нужно оценить следующее:
⏩Быстрее ли будет получить данные из кэша?
⏩Стоит ли хранить эти данные?
⏩Как часто нужно обновлять данные?
⏩Сколько обращений будет к одной записи в кэше?
⏩Кэш будет локальным или общим?
Однако данные в кэше могут устаревать, поэтому бывают ситуации, когда их использование неуместно.
Чтобы понять, насколько успешен ваш кэш, следите за такими метриками, как количество промахов (cache misses).
Вот несколько стратегий кэширования:
𝟭. 𝗖𝗮𝗰𝗵𝗲-𝗔𝘀𝗶𝗱𝗲:
Приложение вручную управляет хранением и получением данных из кэша. При промахе данные загружаются из основного источника и затем помещаются в кэш.
𝟮. 𝗥𝗲𝗮𝗱-𝗧𝗵𝗿𝗼𝘂𝗴𝗵:
При промахе кэш автоматически загружает данные из основного источника. Эта стратегия упрощает работу с данными, самостоятельно обрабатывая промахи кэша.
𝟯. 𝗪𝗿𝗶𝘁𝗲-𝗔𝗿𝗼𝘂𝗻𝗱:
Данные записываются напрямую в основное хранилище, минуя кэш. Подходит, когда записи происходят часто, а чтения — редко.
𝟰. 𝗪𝗿𝗶𝘁𝗲-𝗕𝗮𝗰𝗸:
Данные сначала записываются в кэш, а затем синхронизируются с основным хранилищем. Это уменьшает число операций записи, но есть риск потерять данные, если система выйдет из строя до синхронизации.
𝟱. 𝗪𝗿𝗶𝘁𝗲-𝗧𝗵𝗿𝗼𝘂𝗴𝗵:
Данные одновременно записываются и в кэш, и в основное хранилище, что обеспечивает согласованность, но может увеличить задержку при записи. Идеально подходит для сценариев, где целостность данных критически важна.
𝗖𝗹𝗼𝘂𝗱 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀
Эти принципы помогают создавать надежные, масштабируемые и безопасные облачные системы.
𝟭. 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗼𝗳 𝗗𝗮𝘁𝗮 – управление данными, включая синхронизацию для обеспечения их согласованности и производительности. Примеры: CQRS, Sharding.
𝟮. 𝗗𝗲𝘀𝗶𝗴𝗻 𝗮𝗻𝗱 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 – хороший дизайн для удобства обслуживания, повторного использования и согласованности. Примеры: Sidecar, Strangler fig.
𝟯. 𝗠𝗲𝘀𝘀𝗮𝗴𝗶𝗻𝗴 – инфраструктура обмена сообщениями для связи компонентов и сервисов. Примеры: Priority Queue, Pub/Sub.
𝟰. 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆 – защита данных для обеспечения конфиденциальности, целостности и доступности. Примеры: Федеративная идентичность, Gatekeeper.
𝟱. 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆 – обеспечение доступности и устойчивости системы.
👉 @BackendPortal
🇷🇺«Сталинские Соколы» объявляют первый крупнейший в России турнир «Drone-Con»
Одна из номинаций - Настройка WiFi🎤
🕙Когда? 11-13 апреля 2025 года
Заезд участников с 10.04.2025
Приз за выход в 1/8 финала – 300 000 рублей
За победу в номинации:
🥇I место – 3 000 000 рублей
🥈II место – 2 000 000 рублей
🥉III место – 1 000 000 рублей
Пройди заочный онлайн этап до 8 апреля, и получи возможность попасть на очный этап «Drone-Con»!
Подать заявку и узнать подробности – @dronecon
Если тебя спросят, в чем разница, вот самый простой ответ:
Разбиение (Partitioning) — для управляемости, шардинг (Sharding) — для масштабируемости.
Если ты хочешь стать настоящим мастером backend-разработки, тогда добавляй в избранное — Mastering Backend
Здесь есть всё: серверное программирование, проектирование API, базы данных, микросервисы, безопасность и др. ✍️
👉 @BackendPortal
Асинхронные системы улучшают масштабируемость, но вводят риски.
Группировка — один из самых простых способов решить некоторые из этих проблем.
Асинхронная обработка позволяет задачам выполняться независимо, сокращает время простоя и повышает использование ресурсов.
Она помогает сервисам развязываться, масштабироваться горизонтально и выдерживать нагрузки.
Но асинхронность — это не бесплатно. Она несёт скрытые риски:
❌Сообщения могут приходить не по порядку
❌Операции могут конфликтовать из-за конкурентного выполнения
Это не крайние случаи, а фундаментальные компромиссы, требующие явного проектирования.
Что может пойти не так?
— Банк обрабатывает снятие средств раньше, чем поступает депозит. Транзакция отклоняется, хотя деньги отправлены.
— IoT-система получает команды «открыть дверь» и «запереть дверь» одновременно. Что делать?
Группировка гарантирует, что связанные операции выполняются последовательно, сохраняя строгий порядок. При этом несвязанные группы могут обрабатываться параллельно.
Этот паттерн уже встроен в ключевые системы:
⏩SQS FIFO использует messageGroupId для упорядоченной доставки
⏩Azure Service Bus применяет сессии для последовательной обработки
⏩Kafka использует ключи разделов (partition key), обеспечивая порядок для конкретной сущности
Баланс между порядком и масштабируемостью
Если группировка реализована правильно, она поддерживает баланс между корректностью и параллельной обработкой. Но строгий порядок может ограничить пропускную способность.
А если ошибиться — появляются горячие партиции, узкие места и проблемы с ребалансировкой.
Пример: Горячие партиции возникают, когда одна группа (например, суперпользователь) генерирует основной трафик, перегружая один раздел.
Большинство команд учатся на ошибках — после сбоев системы.
Какой у вас подход к группировке? И как вы решаете её компромиссы, например, горячие партиции? 🤔
👉 @BackendPortal
💡 Совет: Chrome DevTools может переопределять содержимое запросов Fetch/XHR! Полезно для имитации API без ожидания изменений на сервере.
👉 @BackendPortal
HTTP Статусы
🟡1xx Информационные
— 100 Continue – Сервер получил заголовки, ожидает тело.
— 101 Switching Protocols – Сервер меняет протокол по запросу.
🟡2xx Успех
— 200 OK – Запрос выполнен успешно.
— 201 Created – Создан новый ресурс.
— 202 Accepted – Принято, но не обработано.
— 204 No Content – Успешно, но без контента.
— 3xx Перенаправление
— 301 Moved Permanently – Ресурс перемещен навсегда.
— 302 Found – Временный новый адрес.
— 304 Not Modified – Данные не изменились, нет необходимости пересылать.
— 307 Temporary Redirect – Временное перенаправление.
🟡4xx Ошибки клиента
— 400 Bad Request – Ошибка в запросе.
— 401 Unauthorized – Требуется авторизация.
— 403 Forbidden – Доступ запрещен.
— 404 Not Found – Ресурс не найден.
— 429 Too Many Requests – Слишком много запросов (лимит).
🟡5xx Ошибки сервера
— 500 Internal Server Error – Внутренняя ошибка сервера.
— 502 Bad Gateway – Сервер получил неверный ответ.
— 503 Service Unavailable – Сервер перегружен или на обслуживании.
— 504 Gateway Timeout – Сервер не получил ответ вовремя.
👉 @BackendPortal
IT_ONE Cup. ML Challenge от IT_ONE и Sk FinTech Hub — создай AI-ассистента, который будет помогать в работе дизайнерам, системным и бизнес-аналитикам. Участвуй онлайн с 12 по 29 апреля и поборись за 1 500 000 рублей.
Регистрация открыта до 11 апреля
Твоя формула победы:
✅ Разбираешься в машинном обучении.
✅ На ты с NLP и LLM.
✅ Концептуально понимаешь принципы работы веб-приложений.
Также приглашаем Backend и Frontend-разработчиков, системных и бизнес-аналитиков, UI/UX-дизайнеров. Участвуй онлайн соло или командой до 5 человек.
Задачи IT_ONE Cup. ML Challenge:
🔤 Динамические контекстные подсказки для системного аналитика.
🔤 AI-генератор дизайн-макетов по описанию требований.
🔤 Система визуализации BPMN-диаграмм.
4 апреля приходи на митап с экспертами соревнования — задай вопросы и узнай больше о задачах.
Создай AI-ассистента, который облегчит выполнение рабочих задач — регистрируйся на IT_ONE Cup. ML Challenge
❤️ Backend Talks от Яндекс 360
17 апреля, Москва, 19:00
Поговорим про три основы, без которых невозможно создавать высоконагруженные сервисы для миллионной аудитории: инфраструктура, архитектура и команда.
В программе:
📌На пути к 9999: принципы и практики построения высоконагруженных сервисов — Игорь Обручев, руководитель группы SRE
📌Эволюция проектирования общих решений в Яндекс 360 — Евгений Ширанков, руководитель команды платформенных сервисов
📌Ценности и культура команды. Почему они важны и как их сохранить в период роста — Роман Акинфеев, руководитель бэкенд-разработки Яндекс 360
Команда Яндекс 360 работает с нагрузками >1 000 000+ RPS и создает продукты которыми пользуются 95+ млн человек каждый месяц — Диск, Почта, Телемост, Мессенджер и другие.
🍻Приходите на митап обсуждать инженерные практики, качественно нетворкаться с разработчиками и классно провести время!
Регистрируйтесь
Крутейшая онлайн-платформа для практики программирования, которая предлагает более 7000 упражнений на 75 различных ЯП
Каждый язык представлен целой дорожкой с задачами, которые помогут разобраться во всех тонкостях шаг за шагом.
А если застрял, можно получить обратную связь от опытных менторов — не всегда сразу, но всегда по делу ✌️
👉 @BackendPortal
Недавно опубликовывал дорожную карту по бэкенд. а теперь держите по микросервисам! 😁
👉 @BackendPortal
5 лучших бесплатных курсов по Kubernetes
1. K8 для начинающих - https://bit.ly/3cnHzUE
2. Учимся развертыванию Kubernetes в DevOps - https://bit.ly/3PgZk6X
3. Введение в Kubernetes - https://bit.ly/3O8ds0Z
4. Контейнеры 101 - https://bit.ly/3PDEJcR
5. больше - https://bit.ly/3RCXH4V
👉 @BackendPortal
Контроллер раннеров GitHub Actions (ARC) — это Kubernetes-контроллер для управления self-hosted раннерами GitHub Actions.
С ARC можно:
⏩Разворачивать self-hosted раннеры в Kubernetes-кластере через несколько простых команд
⏩Автоматически масштабировать раннеры в зависимости от количества входящих задач (job'ов)
👉 @BackendPortal
❓ Python-разработчики, уже пробовали создавать REST API с помощью Django REST Framework?
⏰ 17 апреля в 20:00 на открытом вебинаре Сурен Хоренян покажет, как быстро стартовать с Django REST Framework, почему это лучший инструмент для построения API на Django и как использовать его в своих проектах.
Сурен — бэкенд-разработчик в ВК Рекламе, руководитель команды и open-source контрибьютор. Отвечает за реализацию бизнес-фич и современные backend-практики. Опыт от стартапов до крупных компаний, ментор курсов по Python и Django.
Если вы разрабатываете на Python (Django, Flask, FastAPI) или только начинаете осваивать веб-разработку — приходите. После вебинара вы сможете самостоятельно создавать REST API на Django и ускорите разработку.
🎁 Все участники смогут задать вопросы эксперту и получат скидку на полный курс по Django-разработке.
👉 Регистрируйтесь и прокачивайте свои навыки веб-разработки
https://otus.pw/ggHP/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Для тех кому нужна дорожная карта по бэкенд 👆
Эта будет более актуальней
👉 @BackendPortal
Шпаргалка по алгоритмам и структурам данных!
Временная сложность, пространственная сложность и многое другое
👉 @BackendPortal
Теорема CAP часто неправильно понимается
Она не утверждает, что система не может проявлять все три свойства (консистентность, доступность, толерантность к разделению сети) в той или иной степени.
Наоборот, она утверждает, что в случае сетевого разделения (P) системе нужно выбирать между консистентностью (C) и доступностью (A).
Это означает, что если данные не могут быть синхронизированы между всеми узлами из-за проблемы в сети, система либо гарантирует, что все данные будут согласованными, но может не ответить на запросы, либо обеспечит доступность запросов, но данные могут быть неконсистентными. ✍️
Теорема CAP помогает разработчикам понять, какие компромиссы им нужно будет делать при проектировании распределённых систем.
👉 @BackendPortal
🗞 EasyOffer 2.0 собрал более 1 млн рублей за первые сутки краудфандинга
Платформа EasyOffer, предназначенная для подготовки к IT-собеседованиям, объявила о разработке новой версии сервиса. За первые 24 часа краудфандинга проекту удалось привлечь более 1 000 000 рублей.
В релизе EasyOffer 2.0 планируется:
— крупнейшая база реальных вопросов и задач с технических интервью
— тренажёры по интервальным повторениям и симуляторы собеседований
— аналитика по компаниям, грейдам, популярности и сложности вопросов
— тестовые задания и требования из вакансий
📆 Релиз запланирован на конец мая.
Сейчас в рамках сбора средств можно оформить годовой PRO-доступ за 3 200 ₽. После запуска такая сумма будет соответствовать цене месячной подписки.
Являются ли микросервисы решением, или монолит тоже справится?
Давайте сравним оба подхода:
Плюсы монолита:
☑ Единая кодовая база и база данных
☑ Проще развертывание
☑ Вызовы внутри процесса, меньше сложных компонентов
Плюсы микросервисов:
☑ Независимые развертывания и масштабирование
☑ Чёткое разделение ответственности
☑ Маленькие, сфокусированные команды
Но микросервисы также добавляют:
1. Сложность распределённых систем (сетевые вызовы, согласованность данных)
2. Дополнительные операционные расходы (мониторинг, оркестрация)
3. Риск изоляции команд, если нет слаженности
❔ Задайте себе вопросы:
- Нужно ли мне масштабировать части системы независимо?
- Готова ли моя команда работать с несколькими сервисами?
- Справлюсь ли я с отказоустойчивостью и версионированием?
Хороший монолит — отличный выбор, если не требуется отдельное масштабирование или доменная область не слишком велика.
Микросервисы полезны при чётких границах, независимых релизах и команде, готовой к распределённым системам.
⚠️ Не выбирайте микросервисы по умолчанию.
Выбирайте подход, который лучше всего подходит вашему домену и команде.
Делайте выбор с умом.
👉 @BackendPortal
В чем разница между балансировщиками нагрузки, обратными прокси и API-шлюзами?
🍩Балансировщик нагрузки распределяет клиентские запросы между серверами, выбирая их по алгоритму, чтобы равномерно распределять нагрузку, избегать перегрузок и обеспечивать стабильную работу системы.
Он получает запрос, перенаправляет его на сервер, принимает ответ и отправляет его обратно клиенту.
Это увеличивает пропускную способность, снижает задержки и оптимизирует использование ресурсов.
🍩Обратные прокси работают как посредники между клиентами и серверами, обрабатывая запросы и передавая данные, скрывая серверы и повышая их безопасность.
Они обеспечивают контроль за сетевым трафиком, снижая риски атак и угроз.
Дополнительно, они могут кэшировать контент для уменьшения нагрузки на сервер, сжимать данные для ускорения передачи и управлять SSL/TLS-шифрованием, разгружая веб-серверы.
🍩API-шлюзы работают как единая точка входа для всех API-запросов, направляя их к нужным микросервисам и собирая результаты.
Они упрощают взаимодействие клиентов с разными сервисами, добавляют защиту, применяют правила, переводят между веб-протоколами и агрегируют данные.
Идеально подходят для работы с микросервисной архитектурой.
👉 @BackendPortal
Различия между HTTP/1, HTTP/2 и HTTP/3
HTTP является основой веб-коммуникации с 1989 года, но за это время он значительно эволюционировал. Вот разбор того, как каждая версия развивалась, чтобы удовлетворять растущие потребности:
1. HTTP/1.1 (1997)
Оригинальный протокол, определивший взаимодействие в вебе, использует простые методы, такие как GET и POST. Однако с развитием веба, появлением сложных приложений, потокового HD-видео и других нагрузок HTTP/1.1 столкнулся с рядом ограничений:
⏩Проблема head-of-line (HOL) blocking, замедляющая загрузку ресурсов.
⏩Избыточные HTTP-заголовки.
⏩Необходимость устанавливать несколько TCP-соединений для параллельной загрузки ресурсов.
2. HTTP/2 (2015)
Значительный шаг вперед, включающий:
⏩Сжатие заголовков для экономии трафика.
⏩Мультиплексирование – возможность одновременной передачи нескольких запросов в одном TCP-соединении.
⏩Приоритезация запросов для ускоренной загрузки важных элементов.
⏩Бинарное кодирование вместо текстового, что ускоряет обработку.
HTTP/2 позволил сократить число TCP-соединений, ускоряя загрузку страниц и оптимизируя использование ресурсов сети. Однако он все еще страдал от TCP head-of-line blocking и проблем безопасности, таких как Stream Reuse Attack.
3. HTTP/3 (2020)
Основан на протоколе QUIC и использует UDP вместо TCP, что дает:
⏩Полное устранение head-of-line blocking TCP.
⏩Улучшенную миграцию соединений (например, при смене Wi-Fi на мобильную сеть).
⏩Встроенное шифрование (TLS 1.3 по умолчанию).
⏩Быстрое установление соединений за счет отказа от трехэтапного рукопожатия TCP.
HTTP/3 не полностью заменяет HTTP/2 – он предназначен для определенных сценариев, где его преимущества наиболее заметны, тогда как HTTP/2 остается надежным вариантом.
👉 @BackendPortal
Git Merge vs Rebase
Одна из самых важных функций Git — это ветвление. Однако при работе с ветками необходимо объединять изменения из одной ветки в другую, и сделать это можно разными способами.
У нас есть два варианта: 👇
1. Merge
Когда ты выполняешь слияние ветки A в ветку B (с помощью git merge), Git создаёт новый коммит слияния. Этот коммит имеет двух родителей — один из каждой ветки, символизируя объединение их истории. Это неразрушающая операция, которая сохраняет всю историю проекта в первозданном виде.
Когда использовать?
☑ Полезно в совместной работе, где важно сохранять целостность и хронологию изменений.
❌ Однако merge-коммиты могут засорять историю, усложняя её понимание.
2. Rebase
Когда ты перебазируешь ветку A на ветку B (git rebase), это означает: "Давайте представим, что изменения из ветки A были сделаны поверх последних изменений в ветке B."
При этом Git перезаписывает историю, создавая новые коммиты для каждого коммита из исходной ветки. В результате получается более чистая и линейная история.
Когда использовать?
☑ Отлично подходит для личных веток, когда тебе нужно сделать историю более аккуратной и понятной.
❌ Но опасно использовать при совместной работе — перебазирование изменяет историю, что может вызвать конфликты, если другие разработчики уже подтянули или запушили исходную ветку.
👉 @BackendPortal
Анализ логов в Linux – полезные команды
⏩Найти все строки с "ERROR" в логах
grep "ERROR" /var/log/syslog
grep -i "failed" /var/log/auth.log
awk '{print $1}' /var/log/access.log | sort | uniqgrep -c "timeout" /var/log/nginx/error.log
awk '{print $1, $2, $3}' /var/log/syslogsed 's/ERROR/ALERT/g' /var/log/syslog
grep "disk full" /var/log/messages | tail -n 10
grep ' 500 ' /var/log/nginx/access.log
grep -v "DEBUG" /var/log/app.log
awk '$3 == "username"' /var/log/app.log
sed -E 's/([0-9]{4})-([0-9]{2})-([0-9]{2})/\2\/\3\/\1/' /var/log/app.logtail -f /var/log/syslog | grep "ERROR"
📕 Открытый урок по разработке веб-приложений на Scala
На открытом уроке 1 апреля в 20:00 мск мы погрузимся в мир бэкенд-разработки на Scala.
📗 В результате вы:
— Узнаете ключевые аспекты создания современных веб-приложений на Scala;
— Познакомитесь с популярными фреймворками и инструментами для работы с базами данных;
— На практике создадите простое CRUD-приложение для закрепления навыков.
Спикер: Алексей Воронец — руководитель разработки департамента проектных решений и поисковых систем в компании Naumen, эксперт с 14-летним опытом, специализирующийся на Scala и функциональном программировании.
👉 Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие
https://otus.pw/3X5o/
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576