🏅🏅🏅🏅🏅
🎯🎯🎯🎯🎯🎯🎯
Приступаем к розыгрышу онлайн-билета на конференцию HighLoad в Санкт-Петербурге 22-23 июня.

Победителем будет тот, чей комментарий под этим постом с правильными ответами на оба вопроса будет первым.

1. Вы проектируете отказоустойчивый кластер на 5 нод. Принятие решений требует согласия большинства. Как называется это большинство?

2. Какой паттерн помогает обрабатывать всплески нагрузки, временно возвращая ошибку вместо падения сервиса?

Как давать ссылки на файлы
(и чтобы никто не украл)


🗳 Публичные файлы (аватарка, превью новости)
Любой может посмотреть. Просто ссылка:
https://cdn.myapp.com/assets/12345/avatar.jpg


🗳 Приватные файлы (паспорт, налоговая, личный документ)
Только владелец или кто с правом.


💔 Как не надо делать
Запрос к API: GET /api/get-file?id=123, сервер читает файл с диска и отдает байты.

Почему плохо: Сервер тратит CPU и память, передавая гигабайты файлов. При 1000 пользователей сервер ляжет.

💚 Как надо делать
Предподписанные ссылки (Pre-signed URLs) - это ссылка, которая:
🔸Работает ограниченное время (например, 1 час)
🔸Содержит подпись (шифр), что файл можно забрать

Как работает:
1. Фронтенд просит бэкенд: "Дай ссылку на файл 123"
2. Бэкенд проверяет права пользователя
3. Бэкенд генерирует специальную ссылку на S3 вида:
https://s3.amazonaws.com/bucket/123?signature=abc...&expires=3600
4. Бэкенд отдает ссылку фронтенду
5. Фронтенд идет напрямую в S3 по этой ссылке


Итог:
Сервер не передает файл, а только дает одноразовую ссылку.

⚡️⚡️⚡️🔥🔥🔥
Розыгрыш для очных участников конференции HighLoad.

Чтобы получить мерч от ПСБ, нужно правильно ответить первым на 2 вопроса.

Вопрос 1

Какого вида согласованности не существует в классификации PACELC?

A. Strict consistency
B. Eventual consistency
C. Optimistic consistency
D. Strong consistency


Вопрос 2

Как меняется поведение системы при проверке лимитов во время деградации, согласно PACELC-профилю операции из доклада?

A. Система перестаёт проверять лимиты вообще
B. Система переключается на строгую согласованность
C. Система перестаёт доверять «быстрым» данным из кеша и возвращается к «медленным, но точным»
D. Система начинает проверять лимиты асинхронно после списания денег


Победителя буду ждать у входа в "Башню" после доклада до 13.15

Давно не виделись!
Думали, я забросила? Нет, конечно!

Завершен мой сезон конференций "весна-лето 2026" (да-да, как у коллекций дизайнеров).
В этом сезоне у меня был фокус и на других задачах, поэтому в арсенале всего 2 конференции, зато какие.

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

Могу сказать, что уровень был очень достойный и в части сильной программы, и в части создания атмосферы, что я особенно ценю.
А еще мне нравится, что эта конференция не относится к тем, где можно смело пропускать половину секций. На Аналисте многие доклады действительно заслуживали внимания. Много практики, живое общение, нетворкинг — все это было в полном объеме.

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

Мой доклад был про CAP-теорему и PACELC в контексте согласованности данных — достаточно техническая тема. И знаете, я была очень рада, что аудитория с таким живым интересом слушала про технические детали, задавала много конкретных вопросов и хотела докопаться до сути. Это здорово, что сообщество не ограничивается философскими рассуждениями о бизнесе и ценностях, а искренне хочет разбираться в железобетонных вещах, на которых всё держится. Вопросы после моего выступления подтвердили: технический фундамент аналитикам нужен и важен.

Главный итог: Analyst Days 2026 оставил приятное впечатление. Организаторам — респект, а аналитическому сообществу — пожелание не бояться сложных тем и задавать неудобные вопросы. Именно так мы и растем профессионально.

А вы были на этой конференции? Что запомнилось больше всего? Делитесь в комментариях 👇

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

Что я вынесла из кулуаров?
Превалирование докладов в ИИ-тематику понравился не всем. Люди по-прежнему ждут инженерных решений, но не в формате «как проектировать ракетные двигатели» (из которого в свой проект ничего не утащишь), а чего-то более универсального и прикладного.
Впрочем, звучало и встречное мнение: перекос кажется нам перекосом только потому, что мы пока не доросли до истинной трансформации сознания для качественного использования ИИ. И с этим мне тоже трудно не согласиться. Время покажет.

Что я вынесла из официальной программы?
Очень зашел формат круглых столов и живых рассуждений о процессах. Говорили о процессах на уровне принятия решений руководства, о том, где экономия бюджета стала реальностью, а где её не случилось. Делились опытом внедрения ИИ в разных бигтехах и всей правдой о том, что ожидания часто не оправдались. Было честно, местами больно, но очень полезно.

Что я вынесла из нетворкинга и общения с аудиторией?
Как я и ожидала, аудитория здесь сильно отличается от моих профильных конференций. Мой доклад слушали с хирургической точностью — люди разобрали его буквально по косточкам. И я увидела, что попала в самое сердечко большинства. Не на всё смогла ответить (некоторые вопросы просто не в моем профиле), но это лишь подстегнуло меня залезать еще глубже в смежные области. Ведь именно благодаря этому неуемному интересу к разным техническим деталям я когда-то и зашла на территорию спикерской деятельности. И это ощущение, когда к тебе приходят с конкретными, сложными вопросами — бесценно.

Главный итог: HighLoad++ 2026 — это конференция-маркер. Она показывает, что мы находимся в точке бифуркации. Все понимают: по-старому работать больше не получится. Но как именно будет выглядеть "новое нормальное" — никто не знает. И это тот самый момент, когда аналитики, инженеры и лидеры должны не просто слушать тренды, а сами формировать будущее.

Точка входа.
Почему сессия это сложно, и при чем тут токены

Привет, коллеги. Сегодня вкатываемся в, пожалуй, самую базовую, но от этого не менее холиварную тему -- аутентификацию. Точнее, в то, что происходит после того, как пользователь ввел логин и пароль. Как система вообще понимает, что следующий запрос от того же Васи, а не от самозванца?

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

🐟 HTTP - это золотая, но рыбка

HTTP - протокол без состояния. Он как аквариумная рыбка: получил запрос, обработал, отдал ответ и всё, сразу забыл. Каждый новый запрос для сервера чистый лист.

📕 Проблема: как построить stateful-взаимодействие (личный кабинет, корзину, историю операций) поверх stateless-протокола?

📝Решение в лоб: Сессия на сервере

Логика простая:
1. Вася логинится.
2. Сервер генерирует длинную случайную строку - Session ID: s3ss10n_vAsYa_12345.
3. Сервер сохраняет у себя в памяти (или в БД) объект: { "s3ss10n_vAsYa_12345": { userId: 451, role: "user", cart: [...] } }.
4. Клиенту отдает этот Session ID (обычно в куках).
5. Клиент с каждым запросом присылает Session ID.
6. Сервер ищет у себя этот ID и «вспоминает» Васю.

Это называется аутентификация с хранением состояния

Для аналитика это выглядит идеально:
▫️ Сервер всё контролирует.
▫️ Захотел разлогинить Васю — просто удалил запись из хранилища сессий.
▫️ В сессии можно копить контекст (шаги оформления заказа, временные настройки фильтров).

Но давайте наденем шляпу архитектора и посмотрим, что будет под нагрузкой.




♦️Проблема "Липкой сессии"

Представьте: у нас не один сервер, а три (потому что Вася такой не один, их миллионы). Запросы распределяет балансировщик.

Вася логинился на Сервере №1. Его сессия s3ss10n_vAsYa_12345 лежит в оперативке Сервера №1.
Следующий запрос Васи балансировщик отправляет на Сервер №2.
Сервер №2 смотрит в свою память: «Не знаю я никакого s3ss10n_vAsYa_12345, ты кто?». Васю выкидывает на логин.

Это называется Липкая сессия — мы вынуждены настраивать балансировщик так, чтобы запросы одного пользователя всегда падали на один и тот же сервер.

❓Чем это плохо?
🔅 Отказоустойчивость: Упал Сервер №1 - все Васи, привязанные к нему, теряют сессии (корзины, незавершенные заказы). Пользовательский опыт испорчен.
🔅 Масштабирование: Добавили новый Сервер №4. Часть пользователей ребалансируется на него, теряя сессии, потому что их родной сервер не догадывается, что они ушли.
🔅 Неравномерность нагрузки: Если на Сервер №1 приземлился активный юзер, который генерит 1000 запросов в минуту, а на Сервере №2 сидят спящие, то балансировка летит к чертям.

Это решение не масштабируется. Да, можно вынести сессии в Redis/Memcached. Но тогда каждый запрос требует сетевого похода в хранилище. Задержка растет. Архитектура усложняется.

Продолжаем мысль предыдущего поста.

❇️ Альтернатива: "Коробка с секретом"

А что, если серверу не нужно хранить сессию? Что, если клиент сам будет приносить все данные о себе, а сервер будет только проверять: "Точно ли эти данные создал я, и не подделаны ли они?"

Это концепция Stateless Authentication.
Сервер после логина упаковывает данные (userId, роль, expiration time) в JSON, подписывает их секретным ключом, чтобы никто не мог подделать, и отдает клиенту.
Этот пакет и есть токен.
Сервер получает запрос с токеном -> проверяет подпись -> если подпись верна, значит, данные внутри токена истинны и созданы нами. Всё. Никакого похода в БД за сессией (в идеальном мире).
Это и есть JWT (JSON Web Token) в своей сути. Но о его внутренностях поговорим дальше.

Главное:
💠 Сессии - это когда состояние хранит сервер. Клиент - просто держатель ключа от ячейки.
💠 Токены (JWT) - это когда состояние хранит клиент. Сервер — просто проверяет, не вскрывал ли клиент коробку.

Если клиент хранит состояние (токен), как нам срочно заблокировать Васю, если его токен действителен еще 30 минут?
Проблема отзыва токенов — это главная боль JWT. Разберем её в деталях дальше.

JWT. Коробка с секретом, в которую можно заглянуть

В прошлом посте мы остановились на том, что Stateless-токен - это "пакет" с данными, который клиент носит с собой, а сервер только проверяет его подлинность. Сегодня разберем этот "пакет" по кирпичикам и подсветим места, где инженер должен бить тревогу, глядя на дизайн системы.

🟠 Из чего сделан JWT

JWT выглядит как три длинные строки в Base64, разделенные точками:

eyJhbGciOi... .eyJzdWIiOi... .SflKxwRJS...

Это Header . Payload . Signature

〰️ Header — метаданные. «Я — JWT, подписан алгоритмом HS256». Тут же может лежать ссылка на ключ (kid), если их несколько.
〰️ Payload — смысловая часть. Здесь лежат claims (заявки/утверждения). Стандартные: sub (идентификатор субъекта), exp (время истечения), iat (время создания). И кастомные: role, userId, permissions.
〰️ Signature — криптографическая подпись. Сервер берет Header + Точка + Payload, прогоняет через алгоритм (HS256/RS256/ES256) с секретным ключом, и получает хеш. Это — "печать", доказывающая, что payload не меняли.

🔴 Разрушаем главный миф: JWT - это НЕ шифрование

Это самое важное, что мы должны понимать, глядя на JWT.

Base64Url — это кодирование, а не шифрование. Любой, кто перехватил токен, может раскодировать Header и Payload и прочитать их как обычный текст. Прямо в браузере, через atob().

Поэтому:
🔺 Никогда не кладите в payload чувствительные данные (пароли, номера паспортов, полные данные карты).
🔺 Даже внутренние идентификаторы, которые кажутся безобидными (например, internal_user_seq_id), могут раскрыть лишнее конкурентам или злоумышленникам.
🔺 Signature защищает только от подделки, но не от чтения. Это как открытка в прозрачном конверте: все видят текст, но никто не может изменить его, не разорвав печать.

Подводные камни JWT

🟣 Проблема инвалидации

Это ахиллесова пята stateless-токенов. Представьте кейс:

1. Утром Вася логинится. Сервер выдает JWT со сроком жизни 24 часа.
2. Днем начальник узнает, что Васю уволили за нецелевое использование корпоративного принтера. Надо срочно отрубить ему доступ.
3. Админ нажимает «Заблокировать пользователя».
4. Но JWT-то у Васи на руках. Сервер нигде не хранит «список активных токенов» - это же stateless. Сервер видит: подпись валидна, exp не истек - проходи, Вася.

Почему это важно
В требованиях это часто звучит как «возможность немедленной блокировки учетной записи». С сессиями на сервере это тривиально. С JWT - архитектурная проблема.

Решения есть, но все они ломают "чистый stateless»:
🔄 Вести черный список отозванных токенов на сервере (усложнение, снова появляется зависимость от хранилища).
🔄 Делать токены очень короткоживущими (5 минут) и использовать Refresh Token (но это уже OAuth-подход, о нем позже).
🔄 Менять секретный ключ подписи (но тогда разлогинятся ВСЕ пользователи разом).

✅Вывод:
JWT плохо подходит для систем, где требуется мгновенная и точечная инвалидация сессий.


🟣 Раздутый Payload

Классический диалог разработчика 🤦‍♂️ и аналитика 🙆‍♀️:
🤦‍♂️: Чтобы не гонять лишние запросы в БД за профилем, давайте запишем в токен всё: ФИО, email, аватарку, массив ролей из 50 элементов, последние 10 заказов, уровень в игре...
🙆‍♀️: Пользователь получит свой профиль быстрее, звучит хорошо!

На деле - плохо. Этот токен прикрепляется к каждому HTTP-запросу. Загрузка страницы со списком товаров - 30 запросов к API. Каждый тащит с собой раздутый токен размером 4 КБ. Это лишний трафик на мобильных устройствах, лишняя нагрузка на сеть.
✅Правило хорошего тона:
В токене есть только то, что нужно для авторизации (идентификации и проверки прав) в рамках одного запроса. userId, role, tenantId - ок. Данные профиля - нет.


🟣 Хранение на клиенте

Это уже зона ответственности фронтенда, но аналитик должен понимать риски.
🤜 localStorage / sessionStorage: Удобно. Но любой XSS-скрипт (а в большом приложении с кучей сторонних библиотек это не редкость) может просто прочитать localStorage.getItem('token') и отправить злоумышленнику. Всё.
🤜 HttpOnly Cookie: Безопаснее. JavaScript не имеет доступа к такой куке. Но появляется уязвимость к CSRF, с которой тоже нужно работать. + cookie - это автоматическая отправка, что не всегда удобно для мобильных клиентов.

✅ Вывод:
Выбирая способ хранения, мы балансируем между удобством разработки и моделью угроз. Для банковского приложения - только HttpOnly Cookie с кучей флагов (Secure, SameSite). Для внутренней админки за VPN - может, и localStorage простителен (но это не точно).


🦑 Что еще важного

Когда вы видите в требованиях "используем JWT", задайте три вопроса:
🧲 Как мы будем отзывать токен, если пользователя нужно срочно заблокировать?
🧲 Что именно мы кладем в payload? Есть ли там чувствительные данные или то, что сделает токен неподъемным?
🧲 Где и как клиент хранит токен? Соответствует ли это критичности данных?

В следующем посте перейдем к API Key и разберем, почему его нельзя использовать для логина пользователей, даже если очень хочется упростить схему.