15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Пакетная vs Поточная обработка данных — в чём разница?
Пакетная обработка
- Обрабатывает данные крупными блоками (пакетами) по расписанию
- Подходит для обработки исторических данных, хранилищ и аналитики
- Примеры: расчёт зарплат, периодическая отчётность, ETL-задачи
Плюсы:
- Эффективна при больших объёмах
- Дешевле в эксплуатации
- Высокая пропускная способность
Минусы:
- Высокая задержка
- Не подходит для задач в реальном времени
Инструменты:
Apache Hadoop, Apache Spark, AWS Glue
Поточная обработка (Stream Processing)
- Обрабатывает данные непрерывно по мере поступления
- Используется для real-time аналитики, выявления мошенничества, мониторинга в реальном времени
- Примеры: фондовый рынок, рекомендации в реальном времени, IoT
Плюсы:
- Минимальная задержка
- Мгновенная аналитика
- Подходит для реактивных систем
Минусы:
- Выше техническая сложность
- Требует высокой отказоустойчивости и масштабируемости
Инструменты:
Apache Kafka, Apache Flink, Apache Storm, Spark Streaming
Гибридный подход
Многие современные системы совмещают оба подхода:
- Batch — для хранения и глубокой аналитики
- Stream — для мгновенных реакций и online-обработки
👉 @BackendPortal
Лучшее наглядное руководство по пониманию JOIN в SQL
👉 @BackendPortal
Будущее наступило: россиянин расплачивается криптовалютой в продуктовом магазине. Трамп вкладывает туда миллиарды. В России вот-вот появится цифровой рубль. А простые студенты делают пару средних зарплат за несколько кликов.
При этом, по статистике, у 80% россиян даже нет криптокошелька. Не говоря о том, чтобы зарабатывать там хотя бы 200к. Чтобы, наконец, это исправить — читайте канал Евгения Голицына.
Автор сам прошел путь от новичка до ТОП-1 трейдера СНГ. В канале он простым языком объясняет, откуда в крипте деньги, какими способами войти без вложений и как даже новичку добиться стабильных 40% в месяц.
Подписывайтесь, в канале есть пошаговый план для старта и список монет, которые скоро кратно вырастут: /channel/+jjdmMPvdsvYzZGQy
Load Balancing основа для построения отказоустойчивых систем
Разберёмся за 5 минут.
1. Что такое Load Balancing?
Load balancing это практика распределения вычислительных задач между двумя и более машинами.
Цель - повысить устойчивость, обеспечить доступность приложения и распределить нагрузку по нескольким инстансам.
Load balancing может осуществляться на 4-м или 7-м уровне модели OSI — в зависимости от архитектуры приложения.
На 4 уровне (L4) балансировщики принимают решения на основе IP-адресов и портов.
На 7 уровне (L7) — учитываются протоколы, URL, заголовки и другие параметры, давая больше гибкости в маршрутизации.
2. Статический vs Динамический Load Balancing
Статический балансинг работает по заранее заданным правилам и подходит для ситуаций с предсказуемым трафиком.
Популярные алгоритмы: round robin, weighted round robin, IP Hash.
Динамический балансинг учитывает текущее состояние серверов: нагрузку, доступность, результаты health check’ов.
Он умеет перенаправлять трафик с перегруженных или нестабильных инстансов на менее загруженные.
Популярные алгоритмы: least connections, weighted least connections, weighted response time, resource-based.
3. Балансировка на 4 уровне
Балансировщик создаётся с привязкой к IP/DNS и порту. Он направляет трафик на пул backend-машин, запущенных на конкретном порту.
Основная задача: принимать запросы на указанный порт и переадресовывать их на один из доступных backend-инстансов.
Балансировщик может быть настроен на периодические health checks, чтобы убедиться, что backend-инстансы работают корректно и приложение остаётся доступным.
4. Балансировка на 7 уровне
Пользователь делает запрос по определённому URL.
Балансировщик расшифровывает запрос (если SSL), анализирует его и перенаправляет на соответствующий backend-сервис.
Дополнительные плюсы Layer 7:
- SSL-терминация
- кэширование
- предварительная обработка запросов и др.
👉 @BackendPortal
Что такое Event Sourcing
Event Sourcing — это архитектурный паттерн, при котором каждое изменение состояния приложения фиксируется и сохраняется в виде события.
Вместо прямого обновления записей приложение добавляет неизменяемые события, формируя надёжную и прозрачную историю того, как было достигнуто текущее состояние.
На практике это означает переход от "хранения состояния" к "фиксации изменений".
Как работает Event Sourcing
Когда пользователь взаимодействует с приложением или запускается системный процесс, каждое изменение состояния записывается как отдельное событие. Эти события:
- Неизменяемые : после записи не редактируются и не удаляются.
- Хронологические: сохраняются строго в порядке возникновения, что облегчает анализ истории.
Текущее состояние приложения восстанавливается путём последовательного воспроизведения событий. Это делает систему более прозрачной и надёжной.
Зачем нужен Event Sourcing
Ключевое преимущество — отслеживаемость. При отладке или аудитах можно точно понять, какие действия привели к текущему состоянию, что существенно упрощает диагностику.
Event Sourcing также даёт гибкость. События можно переигрывать:
- для восстановления багов путём точного воспроизведения сценариев
- для тестирования и проверки новых фич
- для анализа поведения пользователей и производительности системы
Кроме того, благодаря возможности асинхронной обработки событий, Event Sourcing способствует масштабируемости системы.
Какие сложности у Event Sourcing
Event Sourcing добавляет сложность, особенно при восстановлении состояния, что может повлиять на производительность при неправильной реализации.
Хранилище событий требует продуманного подхода: лог событий постоянно растёт и нуждается в управлении и оптимизации.
Где Event Sourcing особенно уместен
Паттерн хорошо подходит для доменов, где важна история изменений и строгий аудит:
- Финансовые сервисы: соответствие требованиям и аудит транзакций
- Логистические и медицинские системы: значимость каждой операции
- Любые системы, где важен исторический анализ или сложная отладка
Event Sourcing повышает прозрачность, сопровождаемость и масштабируемость приложения. Но его внедрение требует внимательной и ответственной реализации.
👉 @BackendPortal
Ваша база данных не доверяет серверу. Именно поэтому она пишет всё дважды.
Write-Ahead Log (WAL) — причина, по которой:
- данные не теряются при сбоях,
- реплики остаются консистентными,
- транзакции — надёжными.
В своей новой статье Raul объясняет, как PostgreSQL использует WAL для гарантии отказоустойчивости:
• Как WAL предотвращает потерю данных
• Что именно записывается и в какой момент
• Почему репликация и восстановление полностью на нём завязаны
• Какие компромиссы и сценарии сбоев нужно учитывать
• Диаграммы и примеры — чтобы всё стало наглядно
Если вы бэкенд-инженер и вам важна корректность работы системы — вам нужно это понять.
📖 Полный разбор → ссылка
"WAL — это не просто механизм восстановления. Это принцип проектирования."
Как работают сессии и куки вместе
1. Пользователь заходит на сайт и логинится.
Он отправляет POST-запрос с логином и паролем.
2. Сервер проверяет учётные данные и создаёт сессию.
- Сессия — это запись на сервере (обычно в памяти, Redis или базе данных).
- Она хранит, например: { user_id: 123, isLoggedIn: true }
3. Сервер отправляет в ответ браузеру ID сессии.
- Это случайный уникальный токен, например: abc123xyz
- Он сохраняется в куке:
Set-Cookie: session_id=abc123xyz; HttpOnly
4. Браузер автоматически сохраняет куку.
Теперь при каждом запросе (например, при переходах по сайту) она отправляется вместе с ним:
Cookie: session_id=abc123xyz
5. Сервер получает session ID и находит связанную сессию.
- Он находит данные по этому ID и понимает, кто перед ним.
- Так пользователь остаётся авторизованным без повторного ввода пароля.
Как это всё защищено:
- HttpOnly → JavaScript не может прочитать куку (защита от XSS).
- Secure → кука передаётся только по HTTPS.
- Данные сессии хранятся на сервере → безопаснее, чем класть всё в куки.
👉 @BackendPortal
Разные способы сериализации данных
🔸JSON
Текстовый, человекочитаемый формат
👍 Поддерживается повсеместно, удобно отлаживать
👎 Многословен, медленный при парсинге в больших объёмах
🔸XML
Иерархичный, поддерживает схемы
👍 Подходит для энтерпрайза и формальных контрактов данных
👎 Тяжеловесный, шумный синтаксис
🔸Protocol Buffers (Protobuf)
Компактный бинарный формат, основанный на схемах
👍 Быстрый и эффективный при передаче по сети
👎 Нечитаемый человеком, требует компиляции схем
🔸Avro
Хранит схему и данные вместе
👍 Отличен для Big Data (например, Kafka)
👎 Эволюция схем может быть непростой
🔸MessagePack
Бинарная альтернатива JSON
👍 Меньше и быстрее, чем JSON
👎 Меньше инструментов по сравнению с JSON
🔸YAML
Отступы, читаемый как конфиг
👍 Удобен для разработчиков в конфигурационных файлах
👎 Чувствителен к пробелам, медленный для машинной обработки
👉 @BackendPortal
Чтобы строить надёжные масштабируемые системы, нужны таймауты.
Они предотвращают захват ресурсов на неопределённое время и делают приложения гораздо устойчивее к сбоям, дедлокам и проблемам с производительностью.
Но корректная реализация таймаутов — нетривиальная задача. Чтобы система была действительно надёжной, таймауты должны обладать рядом свойств, которые не всегда очевидны:
—> Таймауты должны быть сквозными (end-to-end)
Если запрос обрабатывается в несколько этапов, нужен таймаут не только на каждый этап, но и на всю цепочку целиком. Иначе остаются «слепые зоны», в которых операция может зависнуть навсегда.
—> Таймауты должны распространяться (propagate)
Если основной запрос завершился по таймауту, все вложенные подзадачи тоже должны быть отменены. В противном случае остаются «осиротевшие» процессы, которые нужно вручную зачищать.
—> Таймауты должны быть устойчивыми (durable)
Для долгих операций (часов или дней) дедлайны должны надёжно сохраняться в хранилище. Иначе при сбое или рестарте таймаут может быть утерян или сброшен.
Именно поэтому устойчивые таймауты в workflow-системах настолько полезны.
Например, в DBOS — когда workflow запускается с таймаутом, система автоматически вычисляет дедлайн, сохраняет его в БД и передаёт всем вложенным workflow. Если дедлайн нарушен — DBOS гарантированно отменяет весь процесс и все дочерние задачи, даже если они выполняются на других серверах или были прерваны и перезапущены.
Так гарантируется, что в любом случае workflow завершится по таймауту и освободит ресурсы, а не будет висеть вечно.
👉 @BackendPortal
Как выглядят будни разработчиков управляемых БД, S3 и CDN в стартапе внутри big tech?
Слушайте в подкасте «Расскажите про MWS». В новом выпуске мы беседуем с Дмитрием Черёмухиным, руководителем направления Data Platform в MWS.
Обсудим, без каких сервисов не может существовать ни одно современное облако, какие команды их разрабатывают и с какими сложностями они сталкиваются. И самое важное, то, о чём все мечтают, — прекрасный green field, в котором все так хотели поработать.
Смотрите и слушайте на всех популярных площадках:
🎬 YouTube
🎬 VK Видео
🎧 Яндекс Музыка
🎧 Apple Podcasts
🎧 Mave Digital
Как работает HTTPS — пошагово, без воды
1. TCP Handshake
Устанавливается соединение (TCP SYN → SYN+ACK → ACK)
2. Проверка сертификата
🔸Клиент отправляет Client Hello (список поддерживаемых шифров)
🔸Сервер отвечает Server Hello + свой сертификат (с публичным ключом)
🔸Клиент проверяет валидность сертификата
3. Обмен ключами
🔸Клиент генерирует session key
🔸Шифрует его публичным ключом сервера и отправляет (asymmetric encryption)
🔸Оба теперь знают session key
4. Передача данных
🔸Используется симметричное шифрование (быстро и безопасно)
🔸Все данные теперь передаются зашифрованными
👉 @BackendPortal
Стили архитектуры ПО
📌 CQRS Architecture
Разделяет операции чтения и записи для хранилища данных.
Позволяет независимо масштабировать чтение и запись, а также оптимизировать их по отдельности.
📌 Layered (n-tier) Architecture
Разделяет программное обеспечение на логические уровни:
> Presentation Layer (Представление)
> Business Layer (Бизнес-логика)
> Persistence Layer (Хранилище)
> Database Layer (База данных)
📌 Microkernel Architecture
Выделяет минимальное функциональное ядро, а специфичные функции реализуются в виде расширений и плагинов.
📌 Microservice Architecture
Архитектура, в которой приложение состоит из набора небольших, независимо разворачиваемых сервисов.
📌 Space-Based Architecture
Решает задачи согласованности данных, надёжности и масштабируемости в распределённых системах за счёт распределённых вычислительных узлов и виртуализированной инфраструктуры (data grid, messaging grid и т.д.).
📌 Event-Driven Architecture
Продвигает подход, основанный на событиях: генерация, обнаружение, потребление и реакция на события.
📌 DDD Architecture (Domain-Driven Design)
Сосредотачивается на бизнес-логике и сложности предметной области, а не на технологиях.
📌 Orchestration Architecture
Централизованный координатор (оркестратор) управляет взаимодействием между сервисами, контролируя потоки данных и управления.
📌 MVP Architecture (Model-View-Presenter)
Производная от MVC, направлена на разделение управления данными, интерфейсом и логикой отображения.
👉 @BackendPortal
CAP-теорема простыми словами:
В распределённой системе нельзя получить всё сразу — всегда приходится чем-то жертвовать.
CAP-теорема утверждает, что любая распределённая система может одновременно гарантировать только два из трёх свойств:
1. C — Consistency (Согласованность)
Каждое чтение возвращает либо актуальные данные, либо ошибку — никакого устаревшего состояния.
🔸Большинство SQL-БД (PostgreSQL, MySQL) заточены под строгую согласованность.
2. A — Availability (Доступность)
Каждый запрос получает ответ, даже если данные могут быть неактуальными.
🔸Многие NoSQL-БД (например, DynamoDB, Cassandra) чаще всего отдают приоритет доступности, жертвуя согласованностью.
3. P — Partition Tolerance (Устойчивость к сетевым разделениям)
Система продолжает работать, даже если между узлами возникает разрыв связи (network partition).
🔸Все реальные распределённые системы обязаны быть устойчивыми к разделениям.
Компромисс: выбирай любые два
> CP (Согласованность + Устойчивость к разделениям)
Приоритет — точность данных. Система может отвергать запросы при сетевых проблемах, чтобы сохранить согласованность.
> AP (Доступность + Устойчивость к разделениям)
Приоритет — доступность. Система продолжает отвечать, даже если данные временно не синхронизированы.
> CA (Согласованность + Доступность)
Выглядит красиво на бумаге, но недостижимо на практике, т.к. сетевые разделения в распределённых системах — это реальность.
Что дальше за CAP? Теорема PACELC
CAP описывает поведение во время сбоев, но не говорит ничего про работу в нормальных условиях.
Здесь вступает PACELC:
— Если происходит Partition (P) → приходится выбирать между Availability (A) и Consistency (C)
— Иначе (Else, E) → выбираешь между Latency (L) и Consistency (C)
Вывод: даже когда система работает стабильно, приходится балансировать между задержками и согласованностью.
👉 @BackendPortal
Карта ключевых команд Kubernetes
Охватывает следующие аспекты:
● Управление Pod-ами
● Управление кластером
● Управление сервисами
● Мониторинг ресурсов
● Управление пространствами имён (namespaces)
● Управление деплойментами
● Работа с конфигурациями и секретами
Примечание: Это не полный список, а только основные команды.
👉 @BackendPortal
Почему Google рекомендует модульные монолиты вместо микросервисов?
За последнее десятилетие индустрия массово ушла в сторону микросервисов. Мы строили системы на сотни или тысячи пользователей — и пытались масштабировать их до миллионов. Это привело к переусложнению и было ошибкой.
В чём ошибка?
Разработка стала долгой и сложной, системы — запутанными и трудными в поддержке. Особенно это критично для стартапов, которым важно двигаться быстро и держать всё просто.
Согласно недавнему исследованию Google, разработчики чаще всего разделяли бинарники по трём причинам:
✓ ради производительности,
✓ ради отказоустойчивости,
✓ ради выделения чётких границ абстракций и возможности гибкого диплоя.
Но разбиение приложений на микросервисы вносит ряд проблем:
● Снижается производительность
Сериализация и сетевые вызовы становятся серьёзным узким местом.
● Сложно гарантировать корректность
Понимать взаимодействие между всеми версиями микросервисов — крайне нетривиально.
● Усложняется управление
Вместо одного бинарника для сборки, тестирования и диплоя, нужно поддерживать десятки — каждый со своим циклом релизов.
● API становятся «замороженными»
Как только микросервис публикует API, его становится сложно менять без поломки клиентов.
Google предлагает альтернативу — модульные монолиты:
1. Пишите монолитные приложения, разбивая их на логически изолированные компоненты. Каждый компонент — это долгоживущий агент, похожий на актор.
2. Используйте рантайм, который сам решает, какие компоненты должны работать в одном процессе, а какие — через сеть (RPC).
Если два компонента находятся в одном процессе — это обычный вызов метода. Если распределены — используется удалённый вызов (RPC). Рантайм сам решает, где и как исполнять каждый компонент, в том числе масштабируя его.
3. Деплой должен быть атомарным, чтобы исключить взаимодействие разных версий одного и того же приложения.
Эта модель состоит из:
● программной модели с чёткой абстракцией для модульной разработки;
● рантайма, который умеет собирать, разворачивать и оптимизировать такие приложения.
Результат по данным Google:
> задержки уменьшаются до 15 раз
> стоимость инфраструктуры — до в 9 раз (за счёт упрощения управления и деплоя)
👉 Ознакомиться с фреймворком, реализующим этот подход: https://serviceweaver.dev/
Как тебе такой подход? Похоже на EJB или CORBA?
👉 @BackendPortal
🔴 Что делать, если сервис остатков не отвечает, а пользователь хочет заказать товар? Заблокировать UI? Показать ошибку?
В Яндекс Маркете в этой ситуации позволяют оформить заказ, а с проблемой разбираются асинхронно. Это один из примеров «изящной деградации», о которой они подробно рассказали в новой статье про инженерию надёжности.
Внутри много интересного:
— Почему Idempotency — это не роскошь, а необходимость при проектировании.
— Как работает RPS limiter — жёсткий механизм защиты от лавинообразной нагрузки.
— Зачем в war room нужны две раздельные роли: координатора и менеджера.
Отличный материал, чтобы сверить свои подходы с практиками большого e-commerce.
Реклама. Рекламодатель ООО «Яндекс.Такси». ИНН 7704340310
Что такое микросервисная архитектура
Микросервисная архитектура это подход, при котором приложение разбивается на набор небольших, изолированных сервисов.
Каждый сервис:
• реализует отдельную бизнес-функцию
• имеет чётко определённый API
• разрабатывается и масштабируется независимо
Типовая структура микросервисной архитектуры:
🔸CDN
Сеть геораспределённых серверов, которые отдают статический контент пользователям с ближайшего узла.
🔸Reverse Proxy
Прокси-сервер, стоящий перед backend-сервисами и скрывающий их от внешнего мира.
🔸Load Balancer
Компонент, распределяющий входящие запросы между несколькими инстансами сервисов для повышения отказоустойчивости и масштабируемости.
🔸API Gateway
Единая точка входа для всех внешних запросов. Проксирует запросы к нужным backend-сервисам.
🔸Service Discovery и Service Registry
Система для регистрации и поиска доступных сервисов. API Gateway обращается к ней, чтобы узнать, где запущен нужный сервис.
🔸Провайдер аутентификации
Компонент, отвечающий за проверку подлинности пользователей и контроль доступа к backend-сервисам.
🔸Микросервисы
Независимые модули, реализующие конкретные функции. У каждого свой собственный БД-инстанс — это обеспечивает изоляцию данных.
Взаимодействуют через RPC и могут развёртываться, масштабироваться и обновляться независимо друг от друга.
Преимущества микросервисов:
• Масштабирование отдельных компонентов под конкретную нагрузку
• Локализация отказов — отказ одного сервиса не роняет всю систему
• Возможность использовать разные технологии под разные задачи
• Независимый деплой — можно выкатывать фичи быстрее
Недостатки микросервисов:
• Сложность координации большого количества сервисов
• Задержки из-за сетевого взаимодействия между сервисами
• Требуются продвинутые практики CI/CD, логирования и мониторинга
• Сложно обеспечивать согласованность данных между сервисами
👉 @BackendPortal
Твои схемы данных либо оптимизированы под запись, либо под чтение. Никогда не под оба варианта одновременно.
Невозможно запускать аналитику на таблице, в которую заливается 5000 вставок в секунду.
Вот как это делают опытные разработчики:
1. Используют append-only таблицу с партиционированием для записи сырых данных.
2. Отказываются от внешних ключей — приоритет в скорости, а не в ссылочной целостности.
3. Создают материализованные представления (materialized views) для типовых запросов — например, средние значения по дням или почасовые тренды.
4. Разносят сырые и производные данные в отдельные таблицы. Разные структуры — разные задачи.
Спроси себя: ты проектируешь под массовую запись или под аналитику?
Потому что попытка совместить оба сценария в одной таблице — прямой путь к убийству производительности.
Таблицы с высокой нагрузкой на запись не подходят для отчётности.
А ты как решаешь конфликт между паттернами записи и чтения? 🥰
👉 @BackendPortal
Жара в IT! Теперь популярные языки программирования можно легко выучить по гайдам в картинках
Бесплатные инструменты, полезные ресурсы, а также советы и задачки. Выбирай нужное направление и учись не напрягаясь:
👩💻 Linux Ninja
🖥 CodHub | Курсы IT
📱 Python | Программирование
😷 Hacking | Кибербезопасность
⚙️ Webdev | Backend & Frontend
🖥 Программирование по мемам
Если вы инженер-программист и хотите лучше разбираться в алгоритмах и проектировании систем, прочитайте эти 12 статей: ↓
1. Что должен знать каждый инженер при работе с распределёнными системами. — > ссылка
2. Лучшие практики управления изменениями в API без потери доверия пользователей. — > ссылка
3. Как быстро считать диапазонные запросы по массивам с помощью префиксных сумм и разрежённых таблиц (sparse tables). — > ссылка
4. Как овладеть алгоритмами с возвратом (backtracking): пошаговое руководство для решения любой задачи. — > ссылка
5. Всё, что нужно знать, чтобы сделать базу данных масштабируемой, быстрой и доступной — с помощью шардинга. — > ссылка
6. Разница между задержкой (latency) и пропускной способностью (throughput). И как их оптимизировать при проектировании систем. — > ссылка
7. Как эффективно применять метод двух указателей (two-pointer) для задач с массивами и строками (с шаблонами кода). — > ссылка
8. Всё, что разработчику нужно знать о том, как работает система доменных имён (DNS). — > ссылка
9. Как эффективно использовать множества (sets) и хеш-таблицы для решения задач на собеседованиях. — > ссылка
10. Углублённый разбор Redis: архитектура, типы данных и операции, модель персистентности, кейсы использования и многое другое. — > ссылка
11. Как проектировать отказоустойчивые (highly available) системы и измерять доступность (availability) системы. — > ссылка
👉 @BackendPortal
Ускоряй SQL-запросы:
✓ Используй индексы на часто фильтруемых колонках
✓ Избегай LIKE '%что-то' — индекс не сработает
✓ Не делай ORDER BY по большим таблицам без LIMIT
✓ Группируй INSERT-ы в батчи
✓ Анализируй план запроса с помощью EXPLAIN
Бэкенд тормозит? Сначала проверь базу.
👉 @BackendPortal
Термины, которые действительно должен знать каждый разработчик
• Иммутабельность. Данные, которые нельзя изменить после создания — вместо этого при обновлении создаются новые копии.
• Чистые функции. Функции, которые при одинаковом входе всегда возвращают одинаковый результат и не имеют побочных эффектов.
• Побочные эффекты. Любое внешнее воздействие вне функции (например, логгирование, вызов API, изменение внешнего состояния).
• Референциальная прозрачность. Выражение можно заменить его значением без изменения поведения программы.
• Мутация состояния. Изменение значения переменной или объекта со временем — часто не приветствуется в функциональном программировании.
• Идемпотентность . Операция, которую можно выполнять многократно без изменения результата после первого применения.
• Декларативное программирование. Описание того, что нужно сделать, а не как это сделать (например, SQL, React, HTML).
• Императивное программирование. Пошаговые инструкции для выполнения задачи (например, циклы, условные операторы).
• Мемоизация. Кеширование результата функции, чтобы при повторных вызовах с теми же аргументами результат возвращался мгновенно.
• Когезия. Насколько чётко и логично связаны обязанности класса — высокая когезия = лучше дизайн.
• Тесная связанность. Классы чрезмерно зависят от внутренней реализации друг друга — изменения становятся рискованными.
• Утиная типизация. «Если выглядит как утка и крякает как утка — значит, это утка» — тип проверяется по поведению, а не по наследованию.
• Срезка объекта. При присваивании объекта производного класса объекту базового типа теряются дополнительные поля/методы — типичная ловушка в C++.
👉 @BackendPortal
Любая распределённая сага как минимум удваивает объём работы.
Ты пишешь не только основную бизнес-логику — тебе нужно реализовать компенсации для каждой операции.
Возьмём типовой e-commerce-флоу:
🔸Создать заказ
🔸Списать оплату
🔸Запустить доставку
Выглядит просто — пока всё не начнёт падать.
Что если служба доставки легла, но платёж уже прошёл?
Теперь нужно откатить всё:
- Вернуть деньги
- Отменить заказ
- Залогировать сбой и уведомить поддержку
Итого: 6 шагов — половина на успех, половина на восстановление.
Если у тебя n распределённых операций — проектируй сразу на 2n:n прямых шагов и n компенсаций.
Не потому что хочется, а потому что сбой делает это обязательным. 🧠
Успех — это только половина уравнения.
Нет отката = Нет надёжности.
Согласен?
👉 @BackendPortal
Как работает Docker?
🔹Docker Client — ты пишешь команды
🔹Docker Daemon (Darmon) — оркеструет всё внутри
🔹Docker Host — управляет образами и контейнерами
🔹Docker Registry — удалённое хранилище образов (Docker Hub, GitHub Container Registry и т.д.)
Потоки взаимодействия:
> docker build — создаёт образ → сохраняет его локально
> docker pull — тянет образ из registry
> docker run — запускает контейнер из образа
Всё работает по модели: клиент → демон → хост → registry
👉 @BackendPortal
GitHub-репозитория для подготовки к разным типам собеседований на Software Engineer:
1️⃣System Design
> https://github.com/ashishps1/awesome-system-design-resources
Ресурсы по масштабируемой архитектуре, CAP-теореме, базам данных и прочему.
2️⃣Low-Level Design
> https://github.com/ashishps1/awesome-low-level-design
Шаблоны проектирования, объектно-ориентированный подход, SOLID, GRASP.
3️⃣Coding Interviews
> https://github.com/ashishps1/awesome-leetcode-resources
Подборка задач LeetCode, алгоритмы, структуры данных.
4️⃣Behavioral Interviews
> https://github.com/ashishps1/awesome-behavioral-interviews
Типовые вопросы про мотивацию, командную работу, фейлы и успехи.
👉 @BackendPortal
Проектирование Backend-системы. Система уведомлений
Цель —> Разработать систему для доставки уведомлений пользователям через:
➣ Встроенные уведомления
➣ Push-уведомления (мобильные/веб)
➣ Email
С поддержкой:
✓Масштабируемости (миллионы пользователей)
✓Настраиваемых пользовательских предпочтений
✓Надежности, повторных попыток и дедупликации
✓Реального времени и пакетных оповещений
Пошаговый сквозной процесс
Шаг 1: Срабатывание события
✓ Приложение инициирует событие:
➣ Например, пользователь A лайкнул ваш пост
➣ Отправляется запрос POST на API /notify:
{
"event_type": "like",
"actor": "UserA",
"receiver": "UserB",
"object": "Post123"
}"UserA лайкнул ваш пост 'How to scale systems'"[
{ "text": "UserA лайкнул ваш пост", "read": false, ... }
]
Временная и пространственная сложность популярных алгоритмов сортировки:
1. Selection Sort (сортировка выбором)
> Время:
Лучший случай — Ω(n²)
Средний — Θ(n²)
Худший — O(n²)
> Память: O(1)
2. Insertion Sort (сортировка вставками)
> Время:
Лучший случай — Ω(n)
Средний — Θ(n²)
Худший — O(n²)
> Память: O(1)
3. Bubble Sort (пузырьковая сортировка)
> Время:
Лучший случай — Ω(n)
Средний — Θ(n²)
Худший — O(n²)
> Память: O(1)
4. Shell Sort (сортировка Шелла)
> Время:
Лучший случай — Ω(n log n)
Средний — Θ(n log² n)
Худший — O(n²)
> Память: O(1)
5. Merge Sort (сортировка слиянием)
> Время:
Лучший случай — Ω(n log n)
Средний — Θ(n log n)
Худший — O(n log n)
> Память: O(n)
6. Quick Sort (быстрая сортировка)
> Время:
Лучший случай — Ω(n log n)
Средний — Θ(n log n)
Худший — O(n²)
> Память: O(log n)
7. Heap Sort (пирамидальная сортировка)
> Время:
Лучший случай — Ω(n log n)
Средний — Θ(n log n)
Худший — O(n log n)
> Память: O(1)
8. Counting Sort (сортировка подсчётом)
> Время:
Лучший случай — Ω(n + k)
Средний — Θ(n + k)
Худший — O(n + k)
> Память: O(k)
9. Bucket Sort (сортировка по корзинам)
> Время:
Лучший случай — Ω(n + k)
Средний — Θ(n + k)
Худший — O(n²)
> Память: O(n)
10. Radix Sort (поразрядная сортировка)
> Время:
Лучший случай — Ω(nk)
Средний — Θ(nk)
Худший — O(nk)
> Память: O(n + k)
Примечание:
n — количество элементов,
k — диапазон возможных значений элементов.
👉 @BackendPortal
Архитектура PostgreSQL изнутри:
🔸Процессно-ориентированная архитектура
— PostgreSQL использует модель один процесс на соединение — каждое подключение клиента обрабатывается отдельным процессом ОС.
🔸Журнал предварительной записи (WAL — Write Ahead Logging)
— WAL обеспечивает надёжность данных, согласованность, восстановление после сбоев и репликацию.
🔸Многоверсионное управление параллелизмом (MVCC — Multi-Version Concurrency Control)
— PostgreSQL применяет MVCC для обработки параллельных транзакций без жёсткой блокировки.
🔸Конвейер выполнения запроса
— Запросы проходят по чётко определённому пайплайну: разбор → планирование → исполнение → выдача результата.
🔸Система индексации
— PostgreSQL поддерживает разные типы индексов под разные задачи: B-Tree, GIN, GiST, BRIN и др. — для ускорения выборок и оптимизации производительности.
🔸Партиционирование таблиц
— PostgreSQL поддерживает разбиение больших таблиц на более мелкие части (партиции) по диапазону, списку значений или хешу.
🔸Логическая декодировка
— Позволяет транслировать изменения из WAL в логическом формате — удобно для репликации и систем Change Data Capture (CDC).
🔸Расширения
— PostgreSQL спроектирован модульно и поддерживает плагины. Через расширения можно добавлять кастомные функции и возможности.
🔸Сбор статистики
— Встроенный модуль собирает статистику по активности БД в реальном времени, что помогает отслеживать состояние системы и проводить оптимизацию.
👉 @BackendPortal
💲Каналы с Junior IT вакансиями и стажировками
Подписывайся и забирай свой оффер⚡
1. IT вакансии по СНГ
2. IT стажировки по СНГ
3. IT стажировки в топовых компаниях мира
4. Удалённые IT вакансии и стажировки
5. Python вакансии и стажировки
6. БИГТЕХ вакансии и стажировки
7. Design вакансии и стажировки
8. QA вакансии и стажировки
9. Junior вакансии и стажировки
10. Frontend вакансии и вопросы собесов
11. Вакансии и стажировки для аналитиков
12. Вакансии в русских стартапах за границей
13. Вакансии и стажировки для DevOps
14. Вакансии, которых нет на ХХ.РУ
Ошибки безопасности, которые встречаются даже в зрелых кодовых базах:
🔸Хранение секретов в коде или .env-файлах
→ API-ключи и пароли от БД попадают в Git или в логи.
🔸Упор на скрытность вместо аутентификации
→ «Этот эндпоинт скрыт» — это не стратегия безопасности.
🔸Небезопасные значения по умолчанию
→ Дебаг-эндпоинты, открытые порты или слабые правила паролей остаются активны в проде.
🔸Просроченные зависимости с известными уязвимостями (CVE)
→ Библиотеку никто не обновляет, потому что «всё работает».
🔸Отсутствие rate limiting на чувствительных API
→ Эндпоинты входа, OTP и сброса пароля становятся мишенью для перебора.
🔸Неправильная валидация или экранирование ввода
→ Уязвимости типа XSS, SQL-инъекций и командных инъекций легко пролезают при работе с динамическими данными.
🔸Сервисные аккаунты с избыточными правами
→ Сервисы работают от имени «admin» и имеют доступ к тому, к чему не должны.
🔸Публичный доступ к внутренним API или админке
→ Ошибки в настройках firewall или API gateway открывают лазейку для атакующих.
🔸Отсутствие аудита для чувствительных операций
→ Нельзя задетектить злоупотребление — логи не ведутся.
🔸Зашитые в коде JWT-секреты или ключи подписи
→ После утечки их сложно ротировать, и это компрометирует все сессии.
🔸Нет защиты от CSRF на веб-формах
→ Атакующий может заставить пользователя выполнить нежелательное действие в рамках активной сессии.
🔸Некорректный выход из системы или отзыв токенов
→ Пользователь думает, что вышел — но токен всё ещё активен.
🔸Нет алертов на подозрительную активность
→ Даже при аномалиях никто не реагирует — нет уведомления, нет ответа.
🔸Предположение «внутреннее = безопасное»
→ Внутренние API часто без авторизации и логирования — «всё равно никто извне не достучится».
🔸Некачественная или самописная криптография
→ Команды пишут свой шифр вместо использования проверенных и прошедших аудит библиотек.
👉 @BackendPortal