Foreign keys и constraints. Многие путают эти понятия.

Foreign key: столбец, который устанавливает связь между двумя таблицами. Обычно это столбец в одной таблице, который хранит значения первичного ключа из другой таблицы , чтобы можно было соединить их в запросе.

Foreign key constraint: механизм, который заставляет СУБД контролировать целостность внешних ключей. Он гарантирует, что значения во внешнем ключе (post -> user_id) ссылаются на реальную запись в другой таблице (user -> id).

Constraints это полезная фича (помогает с той самой буквой C в ACID), но за удобство приходится платить. Вставки, обновления и удаления на таблицах с constraints требуют дополнительных вычислений и IO для проверки.

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

Базы данных, как мир бесконечных компромиссов. 🚬

👉 @BackendPortal

API ускорили, трафик похудел

В продакшн завезли gzip-сжатие. Размер ответов упал примерно на 85%, а задержка почти на 60%.

До:

Средний ответ 240 KB
Передача ~400 мс

Трафик обходился в ~220 $ в месяц

После:

Средний ответ 36 KB
Передача ~48 мс
Трафик снизился до ~70 $ в месяц

Добавили compression middleware и сразу получили:

Загрузка быстрее на 88%
Минус 68% по расходам на пропускную способность

Маленькое изменение. Большая разница.

👉 @BackendPortal

Наш основной файл состояния Terraform весил 15 МБ. В нём была описана вся наша AWS-организация.

terraform plan занимал 20 минут и часто падал по таймауту.

Никто не хотел к нему прикасаться. Это был наш самый большой технический долг.

Рефакторинг занял 3 месяца:
- Инфраструктуру не меняли.
- Через terraform state mv переносили ресурсы из огромного state-файла в более мелкие логические (например, networking.tfstate, security.tfstate, app-foo.tfstate).
- Terragrunt использовали для оркестрации зависимостей между новыми маленькими state-ами.

Теперь план для одного приложения занимает 30 секунд. Наконец-то можно безопасно вносить изменения.

👉 @BackendPortal

Пентестер получил root-доступ к нашему Kubernetes-кластера за 15 минут. Вот что он эксплуатировал.

Цепочка атаки:

- Нашёл открытый Kubernetes Dashboard (это наш косяк)
- На Dashboard был service account только с view-доступом (мы считали это безопасным)
- Service account мог читать Secrets во всех namespaces
- В одном из Secrets были AWS-креды
- С этими кредами получил доступ к EC2 instance profile
- Instance profile имел полный Kubernetes admin через IAM
- Через kubectl поднял привилегированный pod
- Сделал escape на node
- Root-доступ ко всему кластеру

Что мы думали сделали правильно:

- Dashboard был read-only
- Secrets были зашифрованы at rest
- NetworkPolicy настроены
- Регулярные безопасности обновления

Что мы упустили:

- Dashboard вообще не должен быть доступен снаружи
- Service accounts должны работать по принципу наименьших привилегий
- Secrets не должны хранить AWS-креды (нужен IRSA)
- Pod Security Policies не были включены
- Узлы не были достаточно защищены

Исправление заняло 2 недели:

- Полностью убрали Kubernetes Dashboard
- Внедрили IRSA для всех pod'ов, которым нужен доступ к AWS
- Включили строгие PSP / Pod Security Standards
- Провели аудит всех RBAC-разрешений
- Регулярные пентесты

Стоимость: 24K $ за пентест
Ценность: предотвратили потенциально катастрофический взлом

👉 @BackendPortal

Нужен был API-gateway для нашего кластера Kubernetes.

Вариант 1: AWS API Gateway + ALB Ingress
Плюсы: полностью управляется AWS, масштабируется как угодно, есть авторизация и прочие нужные штуки
Минусы: дорого. Плюс это два хопа (API-GW -> ALB -> Pod)

Вариант 2: просто использовать AWS ALB Ingress Controller
Плюсы: проще, дешевле, трафик сразу в под
Минусы: нет авторизации, нет rate limiting, никаких фич уровня gateway

В итоге выбрали вариант 1. Авторизация, WAF и rate limiting для нас обязательны, и лучше заплатить AWS за готовое решение, чем лепить своё. По сути мы платим за возможности gateway, а не за ingress.

👉 @BackendPortal

Если можно, делай работу на записи.

Низкая задержка любит предвычисление.

Ситуация у Майи:

В таблице профилей были опциональные поля: display_name, timezone и bio.
Половина строк с NULL.
Чтения должны укладываться в 20 мс при 10k QPS.

Нужно было гарантировать, что все сервисы видят согласованные эффективные значения. Никаких NULL ни при каких обстоятельствах.

Варианты:

A → COALESCE на чтении

Оставить колонки nullable.
В каждом запросе писать COALESCE(column, default).
Просто, пока не понимаешь, что каждое чтение теперь считает на горячем пути.
Разный хардкод логики по сервисам.
Не индексируется. Медленно.

B → Материализовать effective_ колонки на записи*

Считать один раз при записи или через CDC.
Хранить effective_display_name, effective_timezone и т. п.
Чтения быстрые. Дефолты единые.
Чуть больше работы на запись, зато предсказуемо, кэшируемо, наблюдаемо.

C → DB defaults + миграция на NOT NULL

Выглядит чисто и декларативно.
Но менять живую таблицу на миллионах строк — минное поле.
Дефолты фиксят только новые строки, не легаси.
Сложные правила дефолтов не место тащить в SQL.

D → Пускай каждый потребитель сам подставляет дефолты

Схему трогать не надо.
Но каждый сервис заново изобретает, что такое default.
Через месяц получаешь пять версий правды, ни одна не совпадает.

Майя выбрала B.

Потому что на масштабе чтения доминируют записи.
Каждая миллисекунда, снятая с запроса, накапливается.
Посчитать один раз на записи лучше, чем пересчитывать 10 000 раз в секунду.

Компромиссы, на которые она пошла:

Чуть выше латентность записи.
Нужна идемпотентность и контроль конкуренции.
Лаг CDC, если апдейты асинхронные.
Бэкфилл, чтобы поправить существующие данные.

Гоняться за перфом умеют многие.
Сделать это надежным — единицы.

Помни: латентность любит предвычисление.

Пара вариантов E, которые можно рассмотреть:

E1 → Сгенерированные колонки в БД (persisted/generated)

Если база поддерживает stored/generated columns, вынеси вычисление эффективных значений в схему.
Плюсы: считает на записи, индексируется, одна точка истины, одинаково для всех клиентов. Можно поставить NOT NULL и уникальные индексы на effective_* поля.
Минусы: логика дефолтов уезжает в DDL, сложнее версионировать и тестировать, зависит от конкретного движка.

E2 → Write-through кэш эффективного профиля

При записи формируешь компактный документ с effective_* и кладешь в быструю KV-базу или Redis. Чтения идут в кэш, БД остается источником истины и синхронизируется через outbox/CDC.
Плюсы: легко удержать <20 мс при 10k QPS, дешево масштабируется, можно добавить TTL и метрики попаданий.
Минусы: инвалидация и согласованность, прогрев кэша, нужно строго держать идемпотентность и порядок событий.

Небольшая ремарка к варианту A: если все же тянуть COALESCE на чтении, можно частично смягчить минусы выражениями-индексами и оберткой-VIEW/DB-функцией, чтобы стандартизировать логику. Это не отменяет вычислений на горячем пути, но делает их индексируемыми и едиными. Однако при 10k QPS B/E1/E2 обычно выигрывают.

👉 @BackendPortal

Пул соединений помогает выдерживать большое количество запросов. Но стоит учитывать, что дефолтные настройки могут быть неудачными.

Когда фронтенд подключается к реверс-прокси (load balancer, API-gateway, CDN и т.д.) и отправляет запрос, прокси устанавливает соединение с исходным бэкендом и пробрасывает запрос по этому соединению.

Проблема в том, как обрабатывать большой поток запросов со всех фронтендов. Это легко может перегрузить бэкенд или привести к ошибкам connection reset, если очередь accept у бэкенда забивается.

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

Но даже с пулом, если дефолтные лимиты слишком большие, проблемы могут возникать незаметно. Правильные параметры — это баланс, который зависит от нагрузки и используемых протоколов.

👉 @BackendPortal

Мы прогнали проверку безопасности. У 90% наших K8s pod'ов оказался примонтирован Service Account token в /var/run/secrets/...

Мы спросили у разработчиков: вы вообще используете это для обращения к K8s API?

Ответ: нет.

Проблема в том, что automountServiceAccountToken по умолчанию true. Токен получает каждый pod, даже если он ему вообще не нужен.

Риск огромный. Если pod взломали (например, через SSRF), атакер сразу получает токен для запросов к API.

Фикс: теперь по умолчанию ставим automountServiceAccountToken: false на всех Deployment'ах

👉 @BackendPortal

Хочешь быструю базу? Выбирай диск с головой.

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

Самые частые варианты EBS: gp3 и io2. Оба — сетевые SSD, но по скорости заметно отличаются.

gp3 дешевле, но сильно ограничен по IOPS (максимум 16k) и по скорости ощущается слабее, чем io2.

io2 может выдавать до 64k IOPS (256k c Block Express) и обычно работает очень бодро. Но стоит БОЛЬШИХ денег. Переход с gp3 на io2 легко умножает стоимость хранилища раза в пять.

Лучший вариант? Локальные NVMe диски. Они самые быстрые и часто самые выгодные по деньгам. Если позаботиться о репликации и безопасности данных, это просто победа для производительности базы.

👉 @BackendPortal

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

Consistent hashing делает упор на скорость поиска и масштабируемость.

Rendezvous hashing ставит на первое место равномерное распределение нагрузки.

Суть простая:

• для каждого ключа считаем рейтинг всех серверов
• ключ уходит на сервер с максимальным рейтингом
• при добавлении или удалении серверов нужно сохранить эту схему

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

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

Обычный rendezvous hashing — O(N) по времени на расчет хешей для каждого ключа. Есть вариант (skeleton-based), который сокращает это до O(log N). Дополнительная память не нужна, потому что рейтинг для ключа считается динамически.

👉 @BackendPortal

Большинство инженеров действительно начинают не с той стороны.

Сначала накидывают Kubernetes, Terraform, сервис-меш, мониторинг, а потом удивляются, почему всё тормозит и разваливается под нагрузкой.

Хороший порядок обучения выглядит примерно так:

- Сети

Разобраться что такое TCP, что внутри HTTP, зачем нужен DNS, как работает routing и чем задержка отличается от пропускной способности.
Без этого все последующие знания, как дом на песке.

- Базы данных

Индексирование, транзакции, репликация, шардинг.
Если не понимаешь как хранить и доставать данные = не понимаешь как масштабировать систему.

- Кэширование

Redis, мемкеш, CDN.
Правильно закэшировал = снял 70 процентов нагрузки.

- Очереди и стримы

Kafka, RabbitMQ и прочие.
Это подушка безопасности, когда трафик внезапно летит очень сильно

- Балансировка нагрузки

Разные стратегии, sticky-сессии, health-checks.
Если не умеешь равномерно раскладывать запросы, то горизонтальное масштабирование превращается в клоунаду 🤡

- Практика на классических задачах

Сократи ссылки.
Ограничь скорость.
Сделай чат, ленту новостей, уведомления.
Боевое обучение без огромных рисков.

- Пост-мортемы

Лучший учитель — чужой факап.
Читаешь разбор инцидентов и видишь закономерности.

В итоге ты начинаешь думать не о «микросервисной архитектуре ради микросервисов», а о базовых законах:
задержка, надежность, пропускная способность, доступность, деньги.

Вот когда у тебя это в голове, то любые диаграммы становятся просто формой записи мыслей, а не магией бога-DevOps.

👉 @BackendPortal

Учебник по Java от Андрея Иванцова теперь доступен онлайн на GitBook. В нём собрано всё, что нужно новичку: от простых типов данных и строк до исключений и коллекций. Материал подан по делу, с примерами кода и понятными объяснениями.

Ссылка для тех, кто хочет прокачаться: andrey-ivantsov.gitbook.io/java

👉 @BackendPortal

Знал, что у Git есть свой собственный сетевой протокол?

Он не использует HTTP, а гоняет бинарный протокол поверх сырого TCP, построенный на формате передачи pkt-line.

Можно глянуть, как это работает, если выставить переменную окружения GIT_TRACE_PACKET=1. Тогда видно, как Git в реальном времени общается с удалённым репозиторием.

Pkt-line это бинарная строка переменной длины. Первые четыре байта содержат длину всей строки в шестнадцатеричном виде. Это значение включает и сами эти четыре байта.

Git отправляет пачку строк want и have, чтобы показать, какие объекты ему нужны. Сервер отвечает сжатыми pack-файлами только с недостающими данными. В итоге получается минимальный и очень компактный бинарный поток с низкими задержками, который отлично масштабируется на огромных репах.

По сравнению с HTTPS этот родной протокол быстрее, потому что ему не мешают HTTP-заголовки, TLS-рукопожатия и статлесс-циклы запросов. Это постоянный двунаправленный канал, заточенный под Git’овскую модель данных.

И да: свой протокол у Git появился потому, что иногда нужен транспорт, спроектированный под твою граф-структуру объектов.

👉 @BackendPortal

У SQL есть решение почти под любую задачу с данными. Освой его по-серьёзке и жизнь станет проще.

Вот самый простой способ вывести отчёт по продажам.

Если делаешь отчёты, одних итогов мало.

Нужны подытоги.

И вот тут все обычно косячат. Пишут GROUP BY… и забывают про WITH ROLLUP.

Пример.

Есть таблица Sales с такими полями:

product — название товара
region — регион продаж
sales_amount — сумма продаж

И тебе нужно получить отчёт: подытоги по каждому товару и один общий итог по всем.

Один GROUP BY этого не сделает.
WITH ROLLUP — сделает.

WITH ROLLUP используется вместе с GROUP BY, чтобы добавить строки с суммами: подытоги и общий итог.

Что фактически делает WITH ROLLUP:

Обычные строки: каждая комбинация product + region и её сумма продаж.

Подытоги: там, где region = NULL, показывается сумма по товару.

Общий итог: product = NULL и region = NULL — сумма всех продаж.

Вот разница между «уметь писать SQL» и «знать SQL».

👉 @BackendPortal

Хочешь лучше разобраться в B-деревьях?

Попробуй http://btree.app Это отдельные песочницы с визуализациями, которые сделаны для статьи про B-деревья и индексы в базах данных. Полезно, чтобы понять вставку, поиск и расщепление узлов в B-деревьях.

Если вы не видели статью, которая сопровождает это: вот

👉 @BackendPortal

Cloudflare поделилась цифрами про интернет-трафик в больших масштабах, и там много любопытного.

Половина всех TCP-соединений укладывается всего в 12 пакетов или меньше. Средний ответ от серверов Cloudflare — примерно 4,8 КБ для HTTP/1.X и около 6 КБ для HTTP/2. Большинство веб-запросов мизерные.

А вот что интересно дальше. Хотя средняя длительность соединения всего 4,7 секунды, некоторые живут сутками. При этом среднее соединение отправляет в 3,78 раза больше данных, чем получает. Веб сильно завязан на загрузку контента.

Распределение классическое — «слоны и мыши». Маленькая доля соединений гоняет миллионы пакетов (стриминг, большие загрузки), тогда как огромная часть — крошечные (API, мелкие ресурсы веб-страниц).

В большинстве соединений проходит всего один HTTP-запрос, даже несмотря на мультиплексирование в HTTP/2. Это касается как пользовательского трафика, так и автоматических запросов из дата-центров.

Интернет гораздо более всплесковый и мимолётный, чем может казаться.

Надеюсь, тебе тоже показалось это занятным.

👉 @BackendPortal

В ноябре 1991 года Тим Бернерс-Ли создал первый вариант протокола, позже получивший название HTTP v0.9, как часть спецификации сервиса WWW

👉 @BackendPortal

Подключение backend API на фронтенде: продвинутый способ

→ Используй TanStack Query для кэширования и фонового refetch.
→ Внедри AbortController для отмены запросов при смене маршрута.
→ Добавь интерсепторы Axios для обновления токена и retry-логики.
→ Держи типизированный слой API для чистых контрактов между FE и BE.
→ Применяй WebSocket для реального времени вместо polling.

Умелая обработка и оркестрация API важны.

👉 @BackendPortal

Когда-нибудь задумывался, как эти капчи с «выбери все светофоры» вообще понимают, что ты всё сделал правильно?
Рассказываю.

Там нет никакой магии. Всё сводится к токену и проверке хеша.
Когда страница загружается, бэкенд генерирует challenge id, сохраняет правильный хеш и отдает браузеру подписанный токен, в котором указано «это челлендж X».
Когда ты кликаешь по квадратикам, твой выбор хешируется, и браузер отправляет на сервер хеш ответа + тот самый токен.
Сервер просто проверяет: совпадает ли хеш с эталоном и не истек ли токен (и не подделан ли он).

Если всё ок — ты человек.
Если нет — добро пожаловать на очередной раунд «найди все эти чёртовы светофоры».
На демо маленький пример на Rust, который показывает ту же логику:

👉 @BackendPortal