9 лучших практик работы с Docker

1. Используй официальные образы

   FROM node:14-alpine

Гарантия безопасности, стабильности и регулярных обновлений.

2. Фиксируй конкретную версию

   FROM node:14.17.0-alpine3.13

Тег latest непредсказуем, лучше указывать точную версию.

3. Многоэтапные сборки (multi-stage builds)

   FROM build-image AS build
   # шаги сборки
   FROM production-image
   COPY --from=build /app /app

Снижает размер финального образа, исключая инструменты сборки и зависимости.

4. Используй .dockerignore

   node_modules
   npm-debug.log

Исключает лишние файлы из образа.

5. Запускай под наименьшими привилегиями

   RUN useradd -m myuser
   USER myuser
   CMD node index.js

Улучшает безопасность, ограничивая права внутри контейнера.

6. Применяй переменные окружения

   ENV APP_HOME /app
   WORKDIR $APP_HOME

Повышает портируемость между разными окружениями.

7. Правильный порядок инструкций для кэша

   FROM debian
   RUN apt-get update
   RUN apt-get -y install openjdk ssh vim
   COPY . /app
   CMD ["java", "-jar", "/app/target/app.jar"]

Упорядочивай шаги от самых редких изменений к самым частым, чтобы оптимизировать кэширование.

8. Добавляй метаданные к образам

   LABEL maintainer="name@example.com"
   LABEL version="1.0"

Упрощает организацию и управление образами.

9. Сканируй образы

   docker scan

Находит уязвимости в безопасности.

👉 @BackendPortal

99% "медленных API" работают медленно из-за таких причин:

- N+1 запросы
- нет индексов
- чрезмерно многословные эндпоинты (слишком много мелких запросов туда-сюда)
- возвращают больше данных, чем нужно
- криво настроено кэширование

👉 @BackendPortal

Каждому бэкенд-разработчику стоит хотя бы раз написать свой HTTP-сервер.

Поверь, это куда веселее, чем звучит.

Ты разберёшься в сетях с нуля и поймёшь, как работают TCP-сокеты, что реально происходит в запросе и ответе HTTP, и зачем нужны заголовки и статус-коды

👉 @BackendPortal

Почему Twelve-Factor App важен

Он описывает проверенные временем архитектурные паттерны и практики, которые можно применять к SaaS-приложениям. Эти подходы помогают создавать софт, который будет устойчивым и легко переносимым при деплое в онлайн-среду.

Двенадцать факторов:

I. Codebase
Одна кодовая база под управлением системы контроля версий, много окружений для деплоя

II. Dependencies
Явное объявление и изоляция зависимостей

III. Config
Хранение конфигурации в окружении

IV. Backing services
Внешние сервисы воспринимаются как подключаемые ресурсы

V. Build, release, run
Жёсткое разделение стадий сборки, релиза и запуска

VI. Processes
Приложение запускается как один или несколько Stateless-процессов

VII. Port binding
Экспорт сервисов через привязку к порту

VIII. Concurrency
Масштабирование через модель процессов

IX. Disposability
Максимальная надёжность за счёт быстрого старта и корректного завершения

X. Dev/prod parity
Минимизировать различия между dev, staging и production

XI. Logs
Логи рассматриваются как поток событий

XII. Admin processes
Админские задачи выполняются как одноразовые процессы

В книге Beyond the 12 Factor App Кевин Хоффман дополняет эти принципы новыми пунктами, включая телеметрию и безопасность:

- Один код, одно приложение
- API first
- Управление зависимостями
- Design, build, release, run
- Конфигурация, креды и код
- Логи
- Disposability
- Внешние сервисы
- Эквивалентность окружений
- Административные процессы
- Port binding
- Stateless-процессы
- Конкурентность
- Телеметрия
- Аутентификация и авторизация

👉 @BackendPortal

Базовые компоненты современного backend-системы

👉 @BackendPortal

API Rate Limiting и Throttling

Rate limiting — это механизм, который контролирует количество запросов к API за определённый промежуток времени. Он нужен, чтобы защитить систему от перегрузки и злоупотреблений, распределить нагрузку между пользователями и обеспечить стабильную работу сервера.

Например, можно разрешать не более ста запросов в минуту для одного пользователя. Такой подход помогает предотвращать DoS-атаки, сохраняет ресурсы сервера, поддерживает равные условия доступа и повышает стабильность API.

Throttling — это управление потоком запросов, когда после достижения лимита новые запросы не блокируются, а обрабатываются с задержкой или ставятся в очередь.

В отличие от жёсткого ограничения, throttling даёт более мягкое поведение: система не отказывает сразу, а распределяет нагрузку во времени. Это важно для сглаживания резких всплесков трафика, обеспечения стабильной производительности и равномерного распределения нагрузки между серверами.

Разница между rate limiting и throttling заключается в том, что первое полностью отсекает запросы сверх установленного лимита, а второе регулирует скорость обработки и позволяет дополнительным запросам пройти с задержкой.

Для реализации этих механизмов используют разные техники.

→ Token Bucket разрешает запросы, если есть свободные токены, которые постепенно восстанавливаются.
→ Leaky Bucket обрабатывает запросы с фиксированной скоростью, а избыточные либо отбрасываются, либо ставятся в очередь.
→ Fixed Window ограничивает количество запросов в фиксированном временном окне, например в течение одной минуты.
→ Sliding Window работает по схожему принципу, но в скользящем интервале, что обеспечивает более плавный контроль нагрузки.

В реальном мире такие подходы встречаются повсюду. Twitter API ограничивает количество запросов на пользователя каждые пятнадцать минут. GitHub API устанавливает лимиты на количество авторизованных запросов в час. AWS API Gateway сочетает оба механизма и даёт разработчикам гибкие инструменты для управления нагрузкой.

👉 @BackendPortal

Как понять, что твоя стратегия кеширования правильная?

Ключевая метрика — процент запросов, когда данные находятся в кеше.

Это называется коэффициент попаданий в кеш и показывает, как часто ты можешь переиспользовать закешированный объект.

Вот как замаксить этот коэффициент:

I. Размер пространства ключей

Единственный способ найти элемент в кеше — точно совпасть по ключу.
Чем меньше возможных ключей, тем эффективнее кеш.
Всегда думай, как уменьшить количество возможных ключей.

II. Размер кеша и элементов

Сколько объектов ты можешь хранить в кеше, зависит от их среднего размера и размера самого кеша.
Когда кеш заполнен, приходится вытеснять старые элементы перед добавлением новых.
Это снижает коэффициент попаданий, потому что элементы удаляются даже если могли бы удовлетворить будущие запросы.
Значит, чем больше элементов помещается в кеш, тем выше будет коэффициент попаданий.

III. Долговечность

Во многих случаях можно кешировать объекты на предопределённое время, так называемый Time to Live, TTL.
В других случаях ты не можешь рисковать устаревшими данными и должен инвалидировать объекты в кеше.
В общем, чем дольше ты можешь держать элементы в кеше, тем выше шанс их переиспользовать.

Большинство кейсов, хорошо подходящих для кеширования, имеют высокий ratio чтений к записям.
Потому что закешированные элементы можно создать один раз и хранить длительное время, пока они не истекут или не станут невалидными.

С другой стороны, кейсы с частыми изменениями данных могут сделать кеш бесполезным, потому что элементы успевают устареть до следующего использования.

👉 @BackendPortal

Охотьтесь на N+1 и убирайте их

Проблема N+1-запросов опасна и легко может ускользнуть из виду. Сценарий такой. Один запрос получает набор данных. Затем для каждой строки нужен ещё один запрос. Количество запросов при загрузке страницы зависит от размера выборки, и если N большой, производительность падает

Пример на псевдокоде

// один запрос
users = db.query('SELECT * FROM users')

// превращается в N дополнительных
for (const user of users) {
  posts = db.query(`
      SELECT * FROM posts 
      WHERE user_id = user->id`)
  user.posts = posts
}
// только теперь можно вернуть результат

Лучше переписать на один запрос с JOIN, чтобы забрать всё сразу

results = await db.query(
  `SELECT u.*, p.* 
   FROM users u 
   LEFT JOIN posts p 
   ON u.id = p.user_id`)

Интересный момент в том, что иногда N+1 почти не заметен. Если N маленький, база настроена и находится рядом с приложением, всё может работать быстро. Но если N=100, сразу ощущается тормоз и база нагружается лишней работой. Исправив это, вы улучшите UX и снизите нагрузку на сервер БД

Иногда такие запросы пишут руками. Но часто их генерирует ORM незаметно для вас. В любом случае избавляйтесь от них

👉 @BackendPortal

Нашёл классный опенсорс инструмент: ConfMap

Он превращает YAML и JSON-конфиги в интерактивные майнд-мапы. Можно искать ключи и значения, кликать по нодам, сворачивать ветки и быстро разбираться даже в самых запутанных структурах.

Забираем здесь: ConfMap или c GitHub 🤩

👉 @BackendPortal

Тесты это не про баги. Это про скорость.

Позвольте объяснить.

Безошибочный код это вымысел.

Но быстрая и бесстрашная итерация? Это реально. И именно для этого нужны тесты.

Хороший набор тестов делает 3 вещи:

- Ломается, когда вы что-то ломаете.
- Объясняет поведение лучше, чем ваши комментарии.
- Даёт уверенность двигаться быстро.

Если работать с кодом страшно, значит, у вас недостаточно тестов или не те тесты.

Тесты это не лишнее.
Вы не пишете их, чтобы угодить менеджеру.
Вы пишете их, чтобы иметь возможность рефакторить без страха.

Скорость это прибыль. Тесты делают скорость безопасной.

👉 @BackendPortal

Большинство думает, что SQL медленный. Это не так.

Медленные у них запросы. Лови простое введение в функциональные индексы.

Что такое функциональный индекс?

• Обычный индекс говорит: «Я помогу тебе быстрее найти значение в этой колонке».
• Функциональный индекс говорит: «Я помогу тебе быстрее найти результат функции».

Пример:

-- Обычный фильтр (медленно)
WHERE EXTRACT(YEAR FROM order_date) = 2023;

-- С функциональным индексом
CREATE INDEX idx_order_year ON orders ((EXTRACT(YEAR FROM order_date)));

Теперь YEAR() не вычисляется для каждой строки — он просто ищется в индексе, как в словаре.

Зачем тебе это?
Ты постоянно пишешь такие запросы:

• LOWER(email) → поиск без учёта регистра
• SUBSTRING(code, 1, 4) → поиск по части строки
• price * quantity → вычисляемые поля
• EXTRACT(MONTH FROM signup_date) → фильтр по месяцу

И все они будут медленными без функционального индекса.

Когда использовать?

• Когда фильтруешь по вычисляемым значениям
• Когда работаешь с датами, строками или вычислениями в колонках
• Когда у тебя много чтения и мало записи
• Когда нужны ответы быстрее 100 мс

Запомни:

I. Функциональные индексы хранят результат функции.
II. Они избавляют от пересчёта при каждом запросе.
III. Делают тяжёлые фильтры очень быстрыми.
IV. Но жрут место и работают только с детерминированными функциями.

Сохрани это. Внедри. Поделись с тем, кто всё ещё пишет тормозные запросы.

Спокойствие, только SQL 🥺

👉 @BackendPortal

За каждой масштабируемой системой стоит очередь. За каждым падением —> неправильно использованная очередь.

Очереди повсюду - фоновые задачи, потоки событий, брокеры сообщений.

Они основа масштабируемых систем, но также и частая причина сбоев.

Базовые определения

I. Очередь: структура данных или система для хранения задач/сообщений в порядке FIFO (First-In-First-Out).
II. Продюсер: компонент, отправляющий сообщения в очередь.
III. Консьюмер: компонент, читающий и обрабатывающий сообщения из очереди.
IV. Брокер: промежуточное ПО для управления очередями (например, RabbitMQ, Kafka, SQS).
V. Подтверждение: сигнал, что сообщение успешно обработано.
VI. Очередь «мёртвых писем» (DLQ): очередь для сообщений, которые не удалось обработать.
VII. Идемпотентность: гарантия, что повторная обработка сообщения не создаст дублирующих побочных эффектов.
VIII. Visibility Timeout: время, в течение которого сообщение «невидимо» для других, пока оно обрабатывается.

Лучшие практики / Подводные камни

I. Используй идемпотентных консьюмеров → предотвращает двойную обработку.
II. Определяй политики повторных попыток (экспоненциальная задержка, ограничение числа попыток).
III. Мониторь длину очереди и задержку обработки как ключевые метрики здоровья.
IV. Используй очереди «мёртвых писем» для упавших сообщений.
V. Гарантируй порядок сообщений только тогда, когда это критично для бизнеса (порядок повышает стоимость и сложность).
VI. Держи сообщения маленькими и самодостаточными.
VII. Всегда включай correlation ID для трассировки.

Производительность

I. Для пропускной способности → параллельные консьюмеры или партиции.
II. Для надёжности → сохраняй сообщения, если критично (компромисс: скорость).
III. Для масштабируемости → авто-масштабирование консьюмеров.

Паттерны

I. Work Queue → распределение задач между воркерами.
II. Pub/Sub → широковещательная рассылка множеству подписчиков.
III. Delayed Queue → повторная попытка позже или планирование задач.
IV. Priority Queue → приоритетная обработка срочных сообщений.

Очереди развязывают компоненты систем, но они не управляют собой сами.

Используешь неправильно — получаешь сбои. Используешь правильно — получаешь масштабируемость, устойчивость и скорость.

👉 @BackendPortal

Делюсь настоящей сокровищницей по систем-дизайну.

В этом репозитории собрана огромная коллекция материалов о том, как строить масштабируемые, надежные и быстрые системы. Тут есть статьи инженеров из FAANG и других компаний, реальные кейсы с архитектурами, которые выдерживают миллиарды запросов, схемы и принципы работы сервисов, а также разборы фейлов, после которых компании восстанавливали свои системы с нуля.

И бонусом идёт шпаргалка для подготовки к собеседованиям по систем-дизайну. 🎉

👉 @BackendPortal

Что такое обработка данных

Обработка данных это сбор, манипулирование и анализ данных для получения полезной информации или инсайтов.

Суть в том, чтобы превращать сырые данные в осмысленную и применимую информацию с помощью разных инструментов, техник и алгоритмов.

Обработка данных бывает разных типов: пакетная (batch), в реальном времени (real-time) и потоковая (stream processing).

В пакетной обработке большие объёмы данных обрабатываются одновременно, обычно ночью или в периоды низкой нагрузки.

В реальном времени данные обрабатываются сразу по мере поступления.

Основные шаги обработки данных:

I. Сбор данных
Первый шаг — собрать данные. Это можно сделать через опросы, сенсоры, веб-скрейпинг или API.

II. Очистка данных
Сырые данные часто содержат ошибки, дубли и пропуски. Очистка данных это поиск и исправление этих проблем, чтобы данные были точными и согласованными.

III. Преобразование данных
После очистки данные нужно привести в формат, удобный для анализа. Это может включать агрегацию данных, конвертацию типов или нормализацию.

IV. Анализ данных
После преобразования данные анализируются с помощью статистики или машинного обучения, чтобы выявить закономерности и инсайты.

V. Визуализация данных
Визуализация это представление обработанных данных в наглядной форме (графики, диаграммы, карты). Это помогает заинтересованным сторонам легко понимать и интерпретировать результаты.

👉 @BackendPortal

Сегодня отмечается День программиста!

256-й день года выбран не случайно:

Дата праздника объясняется расчетом: 2 (двоичная система исчисления) в степени 8 (количество битов в байте). То есть 2^8= 256. Поэтому в обычный год день программиста 13 сентября, а в високосный — 12 сентября

С праздником, коллеги! ☺️

👉 @BackendPortal

Да, CDN снижает задержки за счёт кэширования контента ближе к пользователям, но есть интересная оптимизация, которую они используют, чтобы ещё сильнее уменьшить latency

TCP страдает от slow start -> когда устанавливается новое TCP-соединение, оно сразу не работает на полной пропускной способности. Вместо этого оно стартует консервативно с небольшого количества сегментов и удваивает их каждый RTT, пока не обнаружит перегрузку.

Этот ramp-up может занимать несколько итераций, прежде чем достигнет оптимальной пропускной способности, что проблематично для latency-sensitive приложений. Это серьёзная проблема для CDN, потому что даже несколько лишних RTT на масштабе большого количества пользователей обходятся дорого.

CDN решают это с помощью persistent connection pools к origin-серверам. Вместо того чтобы создавать новое соединение для каждого запроса пользователя, они поддерживают пул долгоживущих соединений между edge-узлами и origin-серверами.

Интересная часть —> это pre-warming в периоды низкой нагрузки.

CDN периодически отправляют небольшие объёмы данных (например, health check или запросы на валидацию кэша) по этим idle-соединениям. Это поддерживает TCP congestion window на максимуме и предотвращает её уменьшение из-за простоя.

Небольшой расчёт, чтобы показать эффект.

Если поддерживать congestion window разогретой, она работает на 64KB вместо 4KB. Это исключает задержку 3–7 RTT, которая возникла бы в противном случае.

Для соединения с RTT 50 мс это экономит 150–350 мс latency - а это очень значимо на масштабе веба.

Надеюсь, вам было интересно. И, как всегда, копайте глубже. 🪰

👉 @BackendPortal

SQLZap это прям находка

sqlzap.com — это онлайн-платформа для тренировок SQL-запросов в браузере. Что-то вроде интерактивного тренажёра

Идеально чтобы натаскать руку (как Leetcode, только для SQL)

👉 @BackendPortal