14390
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Типы облачных сервисов
Существует три основных типа облачных вычислительных сервисов: инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS)
1. Инфраструктура как услуга (IaaS)
IaaS — это самый базовый уровень облачных сервисов. С помощью IaaS мы можем арендовать инфраструктуру, такую как серверы, виртуальные машины (VM), хранилища данных, сети, операционные системы и другое, у облачного провайдера, оплачивая только то, что используем.
Мы можем быстро запускать ресурсы, масштабировать их вертикально или горизонтально в зависимости от потребностей. Когда ресурсы больше не нужны — просто удаляем их и платим только за фактическое время использования.
2. Платформа как услуга (PaaS)
С помощью PaaS мы получаем доступ к средам и сервисам, необходимым для разработки, тестирования, доставки и управления программными приложениями.
Это упрощает работу разработчиков, позволяя быстро создавать веб-приложения, API, мобильные приложения и т.п., без необходимости заботиться о настройке или управлении серверной инфраструктурой, хранилищами, сетями, базами данных и т.д. Примеры — GitHub, Docker и др.
3. Программное обеспечение как услуга (SaaS)
В модели SaaS, которая чаще всего основана на подписке, мы используем программные приложения через Интернет по мере необходимости. Облачный провайдер управляет всей инфраструктурой, операционной системой, программным обеспечением, а также обновлениями и безопасностью. Мы просто подключаемся к приложению через браузер и начинаем работу.
@BackendPortal
Начните карьеру разработчика в Авито 😎
Стажировка для разработчиков возвращается — Авито открывает набор в направлениях Frontend, Backend и QA.
Здесь вы будете работать с продуктами, которыми пользуются миллионы.
Профессионально развиваться и расти вам помогут:
• наставник — научит, как найти лучшее решение, и поможет разобраться в инструментах и технологиях,
• комьюнити стажёров — поделятся опытом и поддержат,
• доступ к базам знаний, библиотекам и корпоративным курсам — поможет нарастить экспертизу.
Стажировка оплачивается. Доступно три направления, вы можете выбрать два – основное и запасное. Если попасть на первое не удастся, сможете пройти отбор на второе при наличии мест.
Условия:
• длительность программы — 6 месяцев,
• работа от 25 часов в неделю, после завершения стажировки — возможность остаться в компании на полную занятость,
• зарплата и корпоративный ноутбук,
• можно работать из офиса, удалённо или в гибридном формате.
Более 80% стажёров продолжают карьеру в Авито. Присоединяйтесь к команде и растите вместе с нами! Регистрация открыта до 10 апреля.
⚡ Совет на 2025 год — не трать деньги на дорогие IT-курсы!
Обучение стоит дорого, но в Telegram слили топовый контент по программированию: курсы, статьи, видео и гайды — всё бесплатно:
👩💻 JavaScript 👩💻 React
👩💻 Python 👩💻 Docker
👩💻 Java 🖼️ Spring
👩💻 C# 👩💻 Game Dev
👩💻 С/С++ 👩💻 DevOps
👣 GoLang 🖼️ Redis
👩💻 Kotlin 👩💻 Mob Dev
🖼️ PHP 🖥 SQL
🖼️ Swift 👩💻 Kubernetes
Не плати за то, что можно получить бесплатно — подписывайся и учись👆
Мои коллеги из Яндекса создали сильнейшие IT каналы 🔥
Наше кредо — программирование не сложно, просто никто не объяснял нормально.
Недавно опубликовывал дорожную карту по бэкенд. а теперь держите по микросервисам! 😁
👉 @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
Как выбрать тип базы данных?
Сегодня доступны сотни, а то и тысячи баз данных, такие как Oracle, MySQL, MariaDB, SQLite, PostgreSQL, Redis, ClickHouse, MongoDB, S3, Ceph и другие.
🟡Реляционная база данных – практически любую задачу можно решить с ее помощью.
🟡Хранилище в памяти – высокая скорость и ограниченный объем данных делают его идеальным для быстрых операций.
🟡База данных временных рядов – хранит и управляет данными с временными метками.
🟡Графовая база данных – подходит для сложных связей между неструктурированными объектами.
🟡Документное хранилище – хорошо подходит для хранения больших неизменяемых данных.
🟡Хранилище широких столбцов – обычно используется для работы с большими данными, аналитики, отчетности и других задач, требующих денормализованных данных.
Есть ли что-то, что вы часто используете, и почему выбираете именно это? 🤔
👉 @BackendPortal
2 архитектурных подхода — MVC и MVP. Оба используются для разделения ответственности в приложении
MVC (Model - View - Controller)
⏩View
Это шаблон или HTML-страница. Слушает изменения модели (например, через data-binding или рендер шаблона).
⏩Controller — обрабатывает HTTP-запросы. Получает данные от пользователя и решает, что делать. Может напрямую изменить View (например, вернуть другую страницу) или вызвать методы модели.
⏩Model — бизнес-логика и доступ к данным. Работает с базой (например, через ORM). При изменениях может оповестить View (в интерактивных системах)
MVP (Model - View - Presenter)
⏩View — пассивная: не принимает решений, только отображает. Все действия отправляет в Presenter.
⏩Presenter — получает события от View. Работает с Model. Сам обновляет View — View ничего не делает без команды
⏩Model
То же самое — бизнес-логика и данные
👉 @BackendPortal
6 решений в дизайне API, которые я больше никогда не приму
Полезно распечатать и повесить на стену
1. Общие ошибки в ответах
⏩Коды ошибок без контекста бесполезны
⏩"400 Bad Request" не помогает в отладке
⏩Отсутствие структурированных полей ошибок приводит к тратам на поддержку
⏩Каждый ответ об ошибке должен включать: код, сообщение, детали, requestId
2. Мышление только в терминах ресурсов
⏩Не всё укладывается в CRUD
⏩Бизнес-операции часто пересекают границы ресурсов
⏩Глаголы иногда делают лучшие эндпоинты, чем существительные
⏩POST /orders/123/cancel лучше, чем PATCH /orders/123 со статусом в теле
3. Версионирование в пути URL
⏩/v1/users моментально становится техническим долгом
⏩Версионирование через URL делает гипермедиа невозможным
⏩Лучше использовать content negotiation через заголовок Accept
⏩Один стабильный URL для каждого ресурса — правильный подход
4. Пагинация без курсоров
⏩Номера страниц ломаются при параллельной записи
⏩Offset/limit не работает на больших объёмах
⏩Отсутствие ссылок на next/previous усложняет клиент
⏩Пагинация с курсорами — необходима
5. Синхронные операции для всего
⏩Блокировка клиента на долгие операции приводит к таймаутам
⏩Нет механизмов ретрая при сетевых сбоях
⏩Без ключей идемпотентности повторные запросы опасны
⏩Долгие операции требуют асинхронного подхода
6. Игнорирование семантики кэша
⏩Отсутствие ETag и If-None-Match приводит к лишнему трафику
⏩Без cache-control поведение становится непредсказуемым
⏩Кэширование критично для масштабирования
⏩Грамотные HTTP-заголовки кэша снижают нагрузку на 60% и более
👉 @BackendPortal
Топ-10 техник масштабирования баз данных, которые вам стоит знать:
🍩Индексирование: Создавайте индексы на часто запрашиваемых столбцах, чтобы ускорить извлечение данных.
🍩Вертикальное масштабирование: Обновите сервер базы данных, добавив больше процессора, ОЗУ или хранилища для обработки увеличенной нагрузки.
🍩Кэширование: Храните часто запрашиваемые данные в памяти (например, Redis, Memcached), чтобы снизить нагрузку на базу данных и улучшить время отклика.
🍩Шардинг: Распределяйте данные по нескольким серверам, разделив базу данных на более мелкие независимые шардированные части, что позволяет достичь горизонтального масштабирования и улучшенной производительности.
🍩Репликация: Создавайте несколько копий (реплик) базы данных на разных серверах, позволяя распределять запросы на чтение по репликам и улучшая доступность.
🍩Оптимизация запросов: Тщательно настраивайте SQL-запросы, избегайте дорогих операций и эффективно используйте индексы для улучшения скорости выполнения и снижения нагрузки на базу данных.
🍩Пуллинг соединений: Снижайте накладные расходы на открытие/закрытие соединений с базой данных, повторно используя существующие соединения, что улучшает производительность при высоком трафике.
🍩Вертикальное партиционирование: Разделите большие таблицы на более мелкие, более управляемые части (партиции), каждая из которых содержит подмножество столбцов из исходной таблицы.
🍩Денормализация: Храните данные в избыточном, но структурированном формате, чтобы минимизировать сложные объединения и ускорить работу с запросами, ориентированными на чтение.
🍩🍩Материализованные представления: Предварительно вычисляйте и храните результаты сложных запросов как отдельные таблицы, чтобы избежать дорогостоящих перерасчетов, уменьшив нагрузку на базу данных и улучшив время отклика.
Как грамотно структурировать 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