Вышла 3я и последняя часть цикла статей про мифы REST

🧮 Как считать доступность в микросервисах

На первый взгляд: берём uptime каждого сервиса и радуемся:
- Service A: 99.9% 
- Service B: 99.9%
"Значит система тоже 99.9%" - скажем мы.
А вот и нет. В композиции сервисов действует другая математика.

🔗 Последовательная цепочка
Если запрос проходит через 3 сервиса (последовательная цепочка Client → API → Auth → DB), у каждого из которых 99.9%, то:

0.999 × 0.999 × 0.999 = 0.997 ≈ 99.7%

Цифра получилась меньше.
Формула для последовательной цепочки:

Availability_total = Π Availability(i)

⛓️ Параллельные запросы
Если запрос обрабатывается параллельными независимыми вызовами сервисов А и В (каждый по 99%), то:

1 - (1 - A)(1 - B) = 99.99%

Общая надежность получилась выше.

Канал есть в MAX

Почему "пять девяток" почти невозможны без деградации UX

Чем ближе система к абсолютной доступности, тем чаще приходится жертвовать качеством UX. И снова поднимается тема фундаментального компромисса. К слову, все мои доклады на конференциях именно про поиск компромиссов в разных аспектах при построении систем.

🎖 Иллюзия непрерывной доступности
Любая распределённая система подвержена сбоям: сетевые задержки, частичные отказы, деградация зависимых сервисов. Стремление к "пяти девяткам" означает, что система должна продолжать отвечать почти всегда, даже если часть компонентов не работает. Но отвечать - не значит работать идеально.
Именно здесь возникает ключевой конфликт: либо пользователь получает быстрый, но неполный или устаревший результат, либо он ждёт (или получает ошибку), пока система восстановит целостность данных и всех зависимостей.

🎖 Контролируемое ухудшение
Один из главных инструментов достижения высокой доступности - мягкая деградация. Система продолжает функционировать, но с урезанным функционалом.
Примеры:
▪️ отключение рекомендаций при недоступности ML-сервиса;
▪️ показ кэшированных данных вместо актуальных;
▪️ упрощённый интерфейс без тяжёлых компонентов.

С точки зрения SLA это победа: сервис доступен.
С точки зрения UX - компромисс: пользователь получает "второсортный" опыт там, где точность данных явно не влияет на финансовые и репутационные потери бизнеса.
Важно, что деградация должна быть предсказуемой и управляемой, иначе она превращается в хаос.

🎖 Запасные пути
Заранее подготовленные сценарии на случай сбоя.
▪️ переход на кэш
▪️ использование реплик или вторичных источников данных
▪️ возврат значений по умолчанию
▪️ очереди и отложенная обработка

Проблема таких сценариев в том, что:
▪️ снижается точность
▪️ устаревшие данные

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

Канал есть в MAX

🔝 Eventual consistency (моя любимая) и доступность

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

Это напрямую влияет на UX:
🔻 пользователь может не увидеть только что созданный объект;
🔻 разные экраны показывают разные версии данных;
🔻 возможны «скачки» состояния.

В high-load системах только так и выживают, но для пользователя - это источник когнитивного диссонанса.


🔃 Так что же выбрать: точность или доступность?
В основе всей проблемы лежит фундаментальный выбор:
🔸При доступности выигрываем uptime, но проигрываем точность данных
ИЛИ
🔸При согласованности выигрываем точность данных, но проигрываем время отклика.

На практике это проявляется так:
быстрый ответ → возможна неточность
точный ответ → выше риск таймаута или ошибки


И вот тут начинается работа системного аналитика, как мастера задавать неудобные, но правильные вопросы.
🟩 где допустима устаревшая информация?
🟩 какие операции должны быть строго консистентны?
🟩 какой уровень UX деградации приемлем?


Поэтому надежность мы рассматриваем под иным углом: про непрерывность взаимодействия любой ценой.


🟪 Как формализовать деградацию?
Всего 3 вопроса для фиксации в требованиях:
1. какие функции отключаются
2. какие данные упрощаются
3. как это отображается в UI
И ваша деградация становится управляемой.

Итог:
Максимальная доступность - это инженерный идеал, но в жизни она может только мешать. Чем ближе система к максимальной доступности, тем чаще она вынуждена работать "вполсилы". Поэтому нужно осознанно выбирать, где допустима деградация, и делать её максимально безболезненной для пользователя.

Канал есть в MAX

Друзья, привет! Уже на этой неделе встречаемся на Analyst Days в Петербурге.

От меня традиционно немного хардкора 🙂
В прошлый раз разбирали CAP, а в этот раз поговорим про PACELC и то, как этот подход помогает принимать более взвешенные архитектурные решения.

На докладе разберём:

- как структурированный анализ ограничений PACELC в штатных сценариях влияет на требования к согласованности данных;
- как это отражается на выборе архитектурных паттернов и технологических ограничений;
- как заранее оценивать последствия архитектурных решений для бизнеса и сильнее аргументировать проектные компромиссы.

Буду рада увидеться и обсудить всё это вживую!

22 мая, в 10.00
Секция В

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

📃 Что такое файловый asset?

Аналогия из жизни
Если представить, что система — это офис, то файловый asset - это любая бумажка или предмет, который может понадобиться разным сотрудникам: договор с клиентом, фото товара и тд

📇 Asset (актив) - это не просто файл. Это "файл + паспорт к нему"
В БД мы храним:
- id пользователя, загрузившего файл
- Дата загрузки
- Размер файла
- Права доступа к файлу
- Адрес в хранилище

Но сам файл лежит отдельно!

🔖 Почему это важно?

Новички часто делают так:
кладут файл в папку на сервере и пишут в базе путь C:\files\dog.jpg. А потом сервер ломается, папку переносят, и ссылки в базе становятся невалидными.
Правильно: в базе хранить ID файла (например, ast-123-456), а где он лежит - это решает специальный сервис.

Увидимся на HighLoad в Питере!

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

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

В этом посте — три доклада из программы Saint HighLoad++ 2026 с разбором подходов, которые помогли справиться с такими задачами.

1️⃣ FinOps: Anomaly Management как версия управления инцидентами. Максим Бурцев (Купер.тех).

В рамках развития практик FinOps в Купере столкнулись с необходимостью управления «финансовыми аномалиями» – отклонениями в расходах на облачные ресурсы. Решение оказалось интересным и элегантным: вместо того, чтобы изобретать процесс с нуля, они переиспользовали «кубики» из зрелых и уже показавших свою эффективность процессов управления инцидентами и проблемами. Максим расскажет о том, как это работает, почему это проще, чем кажется на берегу и как это поможет вам перестать переплачивать за облака и сервера, используя уже имеющийся стек технологий и процессов.

2️⃣ Как жить без строгой консистентности и не терять деньги. Дарья Борисова (ПСБ).

Фундаментальный доклад, из которого вы узнаете (или вспомните) что такое CAP и PACELC, зачем нужна Saga и 2PC. А также на реальных примерах убедитесь, что идемпотентность, дедупликация и reconciliation — обязательные механизмы выживания систем.

3️⃣ Как колоночное хранилище может помочь legacy? Михаил Шишкин (ООО Газинформсервис).

В старых нагруженных корпоративных проектах часто можно встретить активное использование временных таблиц в СУБД. Нередко подобные решения оказываются очень чувствительными к росту объема поступающих в систему данных. Чтобы оживить один из таких проектов без его модернизации в ООО Газинформсервис воспользовались одним из ключевых преимуществ колоночных хранилищ и применили его к этому «проблемному» паттерну.

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

До встречи на Saint HighLoad++ 2026 🖐️

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

🔹 Тип 1. Файловое хранилище (NAS, NFS, HDFS)
Как работает: Как обычная папка на компьютере, только расшаренная по сети. Есть иерархия: папки → подпапки → файлы.
Пример из жизни: Общая сетевая папка в офисе, куда все скидывают отчеты.
Проблема: Если два человека одновременно редактируют один файл, система ставит lock (блокирует для остальных). При миллионах пользователей это приводит к тормозам.
Когда можно использовать: Во внутренних системах компании с 50 сотрудниками. Не для интернет-магазина.


🔹 Тип 2. Блочное хранилище (EBS, SAN)
Как работает: Представь флешку. Сервер видит её как обычный диск (диск D: или /dev/sda). Форматируешь, создаешь файлы.
Проблема: Этот диск можно «прицепить» только к одному серверу. Другой сервер уже не сможет читать файлы с этого диска одновременно.
Пример: База данных хранит файлы на своем локальном диске.
Когда использовать: Для временных файлов, кеша, логов на одном сервере. Не для общего доступа.


🔹 Тип 3. Объектное хранилище (S3, MinIO)
Как работает: Нет папок, есть объекты. У каждого объекта есть:
-Уникальный ключ (например, user123/avatar/2024/photo.jpg)
-Тело (сами байты файла)
-Метаданные (как паспорт)
Главное отличие: Вы не ходите по папкам. Вы просто говорите: "Дай объект с ключом X".
Почему это стандарт для веба:
Бесконечное масштабирование. Можно хранить миллиарды файлов, в отличие от папок.
HTTP-доступ. файл можно отдать как ссылку https://...
Неизменяемость или версионирование. Вы не меняете файл по тому же адресу, а создаете новую версию.

 Это как огромный склад с ячейками. У каждой ячейки есть номер. Вы не создаете папки, а просто говорите: "Положи в ячейку 123-456". И потом: "Дай содержимое ячейки 123-456".

🙌 Что такое S3?
S3 (Simple Storage Service) - это сервис от Amazon. Самое популярное объектное хранилище в мире.
Большинство других хранилищ (MinIO, Yandex Object Storage, VK Cloud S3) совместимы с S3. Это значит, что код, написанный для Amazon S3, будет работать и у них.

Как выбрать хранилище под задачу?

1. Аватарки, фото товаров, документы пользователей в веб-сервисе -> Объектное (S3/MinIO)

2. Локальный кеш на сервере -> Блочное

3. Внутренний файлопомойка для 10 сотрудников -> Файловое

Как называть файлы в объектном хранилище
(чтоб не было больно)

Допустим, выбрали S3. Теперь вопрос: как придумывать ключи (имена объектов)?

❌ Что нельзя делать
Плохо: Ключ = оригинальное имя файла document.pdf
Пользователь может назвать файл ../../../config.json - жди взлома системы.
Два пользователя загрузят report.pdf — файл перезапишется, данные будут утеряны.

Плохо: Все файлы складывать в одну папку assets/ и туда все подряд.
S3 тормозит, если в одном префиксе больше 100 000 объектов (на самом деле не строго, но для понимания - да).


✅ Что можно делать

📔 Хороший паттерн для старта:

assets/{user_id}/{category}/{uuid}.{ext}

Пример: assets/12345/avatar/a1b2c3d4-5678.jpg
Почему так:
user_id - быстро найти все файлы пользователя
uuid - уникальный идентификатор, никогда не повторяется
Папки на самом деле в S3 виртуальные, но для человека удобно


📔 Продвинутый паттерн (для больших объемов):

{md5_hash[:3]}/{uuid}.{ext}

Пример: a1b/123e4567-e89b-12d3.jpg
Первые 3 символа хэша нужны, чтобы равномерно размазать файлы и S3 не тормозил.

Друзья!
🏆🏆🏆🏆🏆🏆
В четверг в 16.00 начнём розыгрыш билета. (Чтобы сделать вам приятное перед праздниками 😊)

Розыгрыш, как обычно, будет заключаться в правильном ответе на 2 вопроса.
Первый правильно ответивший получает онлайн-билет на конференцию!

Ставьте напоминания и будьте готовы!

Я не буду впаривать вам идеальную архитектуру

Посмотрите это видео от Дарьи Борисовой из ПСБ и узнайте, какую задачу решала ее команда, какие важные вопросы стояли перед ними, и что вы сможете вынести из ее доклада на Saint HighLoad++ 2026 ✅

🏅🏅🏅🏅🏅
🎯🎯🎯🎯🎯🎯🎯
Приступаем к розыгрышу онлайн-билета на конференцию 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 оставил приятное впечатление. Организаторам — респект, а аналитическому сообществу — пожелание не бояться сложных тем и задавать неудобные вопросы. Именно так мы и растем профессионально.

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