15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Топ-10 техник оптимизации SQL-запросов для повышения производительности
Любая база данных позволяет извлекать данные с помощью SQL. И если ты когда-либо работал с запросами, то наверняка сталкивался с их медленной работой.
Иногда дело в нагрузке на систему, но куда чаще причина — неэффективно написанный SQL-запрос.
Чтобы добиться оптимальной производительности, нужно использовать максимально эффективные и быстрые конструкции.
Вот список SQL-оптимизаций, которые помогут ускорить выполнение запросов:
1. Используй имена колонок вместо * в SELECT
Извлекай только нужные поля, это уменьшает объём передаваемых данных и ускоряет обработку.
2. Избегай HAVING без крайней необходимости
Для фильтрации строк используй WHERE, а не HAVING, если нет агрегации.
3. Убирай лишние DISTINCT
Не применяй DISTINCT, если можно обойтись без него — он добавляет накладные расходы.
4. Избавляйся от ненужных вложенных подзапросов (unnest)
Часто такие конструкции можно переписать через JOIN или CTE (WITH).
5. Используй IN`по индексируемым колонкам
Если колонка индексирована, IN (...) работает быстрее, чем кажется.
6. Используй EXISTS вместо DISTINCT при JOIN-ах с отношением один-ко-многим EXISTS эффективнее, особенно при проверке наличия связанных записей.
7. Заменяй UNION на UNION ALL, если дубликаты не важны UNION удаляет дубликаты, что требует дополнительных ресурсов.
8. Избегай OR в условиях соединения (JOIN)
Разбивай на UNION ALL или переписывай логику — OR может мешать использованию индексов.
9. Не применяй функции к правой части в условиях (WHERE col = FUNCTION(...))
Это мешает оптимизатору использовать индекс — сначала вычисли значение отдельно.
10. Убирай избыточные математические операции
Не нагружай запрос лишними расчётами — это замедляет выполнение.
Есть что добавить?
🔸Полный текст: https://andrewrgoss.com/pdf/sql_query_optimization_techniques.pdf
👉 @BackendPortal
ХОСТИНГИ ДЛЯ БАЗ ДАННЫХ — БЕСПЛАТНО
Актуальные варианты на сегодня ↓
🔸NEON TECH
PostgreSQL, 500 МБ, 190 часов вычислений
→ neon.tech
🔸MONGODB ATLAS
MongoDB, 512 МБ, автоматические бэкапы
→ mongodb.com
🔸TURSO
SQLite, 5 ГБ, 1 миллиард чтений
→ turso.com
🔸XATA
PostgreSQL, 15 ГБ, неограниченный трафик
→ lite.xata.io
🔸SUPABASE
PostgreSQL, 500 МБ, 5 ГБ трафика
→ supabase.com
🔸COCKROACHDB
10 ГБ хранилища, 50 млн запросов
→ cockroachlabs.com
🔸KOYEB
PostgreSQL, 1 ГБ, 5 часов вычислений
→ koyeb.com
🔸FREEDB TECH
MySQL, 25 МБ, максимум 200 подключений
→ freedb.tech
Если знаешь ещё варианты — делись
👉 @BackendPortal
Как грамотно выстроить работу с Kubernetes
Правильная настройка приложений в k8s — критически важна для стабильной работы. О том, на что особенно стоит обратить внимание при настройке приложения в k8s расскажет Константин Никитин, руководитель направления Т-Банка. 30 августа он вместе с другими спикерами выступит на конференции JVM Day.
В программе также:
🔸Оптимизация производительности
Александр Ланцов поделится опытом ускорения клиринговой системы платежей "Мир" и расскажет о нетривиальных приемах, которые ему в этом помогли.
🔸Разбор протоколов gRPC и RESTful
Алексей Романов проведёт детальное сравнение API-протоколов по ключевым параметрам: от применимости в разных сценариях до удобства разработки и безопасности.
🔸Афтепати и нетворкинг
После деловой программы гости смогут пообщаться друг с другом в неформальной обстановке, сыграть в настолки и лото. Также будет работать фреш-бар.
Половину собранных средств Т-Банк перечислит региональным техническим вузам. На сайте были указаны: КФУ (ИТИС) в Казани, УрФУ в Екатеринбурге и факультет вычислительной техники РГРТУ в Рязани. Такие меры поддержки могут помочь регионам с подготовкой будущих ИТ-специалистов и развитием ИТ-отрасли. Для прохода на JVM Day необходимо пройти предварительную регистрацию.
👉 @BackendPortal
Таблица обязательных задач по алгоритмам и структурам данных для собеседований
👉 @BackendPortal
Системный дизайн. Система бронирования отелей
Цель
- Искать отели с фильтрами (локация, цена, рейтинг, доступность)
- Просматривать детали (номера, удобства, отзывы)
- Бронировать номер, получать подтверждение
- Обрабатывать отмены, возвраты, оплаты и прочее
Шаг 1: Пользователь ищет отель
Фронтенд: GET /search?city=London&checkin=Jul20&checkout=Jul22
Бэкенд:
- Выполняет поиск через ElasticSearch (по гео и фильтрам)
- Получает метаданные отелей из предзаполненного кеша
- Параллельно запрашивает доступность номеров из Redis по топ-отелям
Шаг 2: Выбор номера и блокировка
При выборе номера:
- Включается слой блокировки номера:
SET room:R123_2025-07-20 locked NX EX 120
_(Блокировка на 2 минуты — чтобы дать пользователю время на завершение оплаты)_
- Если номер уже заблокирован — показываем ошибку
Шаг 3: Инициация бронирования
Клиент отправляет POST-запрос:
http
POST /book
{
user_id, hotel_id, room_id,
checkin, checkout, amount,
payment_token, idempotency_key
}
hotel_id, name, geo_hash, city, starsroom_id, hotel_id, room_type, base_price, max_guestsroom_id, date, available_count booking_id, user_id, room_id, checkin, checkout, status, price
🔴 Что делать, если сервис остатков не отвечает, а пользователь хочет заказать товар? Заблокировать 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 разработчиков, удалёнка, платим много!
Специально для Вас, собираем лучшие вакансии. Только вакансии с прямыми контактами в Telegram!
👩💻 Java 👣 GoLang
👩💻 Python 🖼️ PHP
👩💻 Node.js 🤖 ML & Data Science
Подпишись чтобы не упустить свой шанс получить лучший оффер!
Список БЕСПЛАТНЫХ облачных сервисов для разработчиков.
Хостинг, SaaS, PaaS, IaaS и сотни инструментов с фритиром — всё собрано в одном месте.
https://free-for.dev
👉 @BackendPortal
По мере того как ИИ пишет всё больше кода, системный дизайн становится всё важнее.
101 короткий приём по системному дизайну
🔸Данные и хранилища
- Нужно искать текст по большим данным? → Inverted Index
- Нужна строгая согласованность (ACID)? → RDBMS
- Гибкая/хаотичная схема? → NoSQL
- Храним видео, изображения, большие файлы? → Object Storage (S3, GCS)
- Доступ по всему миру? → CDN
🔸Производительность и масштабирование
- Основная нагрузка — чтение? → Read-through Cache (Redis)
- Основная нагрузка — запись? → Асинхронные очереди (Kafka, RabbitMQ)
- Масштабирование БД:
> NoSQL → горизонтальное
> RDBMS → вертикальное или шардинг
- Низкая задержка? → CDN + Load Balancer + Cache
- Медленные запросы? → Индексы (по одному/нескольким столбцам, покрывающие)
🔸Управление нагрузкой и масштаб
- Слишком много трафика на один сервис? → Rate Limiting
- Умная маршрутизация между серверами? → Consistent Hashing
- Готов пожертвовать консистентностью ради аптайма? → Eventual Consistency
- Кэш забивается? → LRU (по умолчанию) или кастомная эвакуация
🔸Надёжность и отказоустойчивость
- Высокая доступность? → Load Balancer + Репликация
- Хотим защитить записи? → Write-through Cache + Реплика
- Синхронизация между системами? → Checksums / Hashing
🔸Реалтайм-связь
- Онлайн-обновления (чаты, уведомления)? → WebSockets
- Видео/аудио-связь? → WebRTC
🔸Наблюдаемость
- Отладка и мониторинг? → Централизованные логи и метрики (ELK, Grafana)
- Трассировка межсервисных задержек? → Distributed Tracing (OpenTelemetry, Jaeger)
🔸Продвинутые паттерны
- Circuit Breaker → изоляция сбойных компонентов
- Bulkhead → изоляция ресурсов между модулями
- Throttling → ограничение нагрузки на нижележащие системы
🔸Что важно помнить
- Начни с типа задачи: чтение, запись, низкая задержка, реалтайм
- Выбирай правильные примитивы: очередь, кэш, балансировщик, трассировка
- Всегда учитывай компромиссы: задержка, консистентность, доступность, надёжность, стоимость
👉 @BackendPortal
Поздравляем, вы на 1 шаг ближе к работе мечты 🥳
Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉
Avito Career — место, где Авито делится актуальными вакансиями для разных грейдов и направлений.
Вакансии, которые недавно выходили в канале:
— Бэкенд-разработчик
— Бэкенд-разработчик в команду инструментов надёжности
— Go-разработчик
Подписывайтесь, чтобы не потерять полезный ресурс!
Пакетная 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