Нефункциональное требование "Доступность" необходимо как воздух каждому сервису.

Availability

Телеграмм не подключается❗Висит загрузка. Волнительно. Неприятно. Снижается удовлетворенность пользователей от использования сервиса.

Реклама не показывается. Трафик падает. Акционеры в панике скидывают акции 📉. Совет директоров вызывает главного архитектора.
СВ: "Что происходит, дорогой?"
А: "Доброе утро. Зачем меня разбудили так рано?"
СВ: "Посмотри новости."
А: "А, так это плановые ночные работы на нашем единственном сервере с небольшим downtime."
СВ: "😳"
СВ: "Это не допустимо!"
А: "Почему?"
СВ: "Мы теряем деньги. Нам нужна доступность 24/7 !"
А: "Такого требования при проектирование системы не было 🤷"
Архитектор медленно наливает горячий шоколад, разворачивается и идёт в своей пижаме в сторону лифта.

В современном мире всё должно быть доступно:
1) Сотрудник в течение рабочего дня для решения вопросов;
2) Чайник для заваривания крепкого бодрящего чая когда захотелось его попить;
3) Сервис доставки еды для вкусного обеда;
Я хочу зайти в телеграмм нажатием по значку в телефоне или кликом мышки на ПК и через 0.5 секунды увидеть состояние диалогов и чатов.

С точки зрения разработки архитектуры Availability / Доступность значит многое:
1) Система продолжает функционировать даже при падение критического компонента;
2) Система обрабатывает ошибки компонентов без нарушения обработки запросов;
3) У критически важных компонентов должны быть реплики-дублирующие компоненты;
4) Существует мониторинг, который помогает быстро обнаруживать проблемы;
5) Есть возможность быстрого отката функционала;
6) Отсутствует единая точка отказа;
7) Система справляется с быстрорастущим трафиком;
8) Система переживает сбои сети, софт, железа;

2 популярных паттерна для реализации этого требования:
1) Replica - дублирующий компонент c разными вариантами записи, чтения типа master/slave
К примеру, реплицируем БД. Запрос от клиента приходит в master. Master скидывает в slave. Если режим записи синхронный, то ответим клиенту только после записи в slave.
2) Failover - дублирующий компонент готов к обработке текущего трафика.
a) Стратегия active-active. Оба обрабатывают текущий трафик.
b) Стратегия active-passive(standby). Failover мониторит состояние active инстанца. При его падение берёт трафик на себя.

Пример реализации этого паттерна в nginx.

В этом посте про "Доступность" сервиса мы разобрали:
1) Мотивацию использования этого нефункционального требования;
2) Его основные характеристики;
3) 2 паттерна для реализации требования в системе.

Удачи в построение отказоустойчивых систем!

#Requirements #Availability #Replica #Failover

Availability

Подкрепим текстовую информацию видеорядом 🧑‍💻
Создал видеоролик, в котором реализуем нефункциональное требование "Доступности" для небольшого сервиса.

https://youtu.be/qCp-2Cyu4MY

Успешный алгоритм прохождения интервью. Какой он?

🔥 Интервью - это стресс.
Как сделать прохождение комфортным?

💡 Хорошисты и отличники обладают хорошей базой знаний.
Однако этого ещё не достаточно, чтобы успешно пройти специальный экзамен - ЕГЭ. Его специфика породила определённую подготовку. Одно дело знать, другое - уметь применить знания по определенной теме за короткое время в данных условиях.

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

⚡️ Структуру задает кандидат. Хорошо когда она есть. И ещё лучше когда шаги в ней последовательные и логичные. Помогают кандидату двигаться в бодром темпе и не упускать главные моменты.

⚙️ Существуют различные варианты таких шагов. Мне понравился подход Александра. Он драйвит тему интервью. Можно сказать, формирует тренд.

1️⃣ В начале кандидат задаёт уточняющие вопросы, понимает границы системы. Таким образом, синхронизируется с интервьюером.
2️⃣ И далее уже от общего к частному строит систему по шагам.

✅ Поняв и проработав предлагаемую структуру, можно смело пробоваться в наши и зарубежные Big Tech компании.

#SystemDesignInterview #SystemDesign

Consistency

❗ На собеседованиях System Design самый распространенный тип согласованности, которую просят реализовать - "Eventual consistency" - "Согласованность в конечном счёте".

🕐 Когда изменённые на одной ноде данные спустя какое-то время оказываются и на остальных. Пример системы - лента друзей. По слухам, её просят реализовать в 70% случаев на собеседованиях в одну из Top Tech RU компаний.

⚡ В самом начале изучения System Design мне было не просто настроить мозги на что-то кроме Strong Consistency. Когда есть обычный сервис, который общается с обычной БД рядом. И нет никакой распределенности по планете.

🚣‍♀️🚣‍♂️ По дефолту все запросы сериализуются и не конфликтуют когда работаем не изменяя уровень изолированности в БД.

➡ Дела обстоят иначе с появлением распределенности и высоких нагрузок. Клиентские запросы попадают на сервера в разные ЦОДы. Появляются многочисленные параллельные операции записи, чтения. По теореме CAP нам уже нужно выбрать что реализуем в придачу к P:
❇ Availability
или
❇ Consistency

Если нужно видеть одно и тоже значение данных в любой момент времени на любой ноде, нам нужна "Strong Consistency". Необходимы:
1) синхронные операции репликации
2) разрешение конфликтов записи
Такое требование к согласованности данных можно предъявить к созданию, например, банковской системы.

💰⚠ Здесь точность операций с балансом - наше всё. Допустим, по счёту нельзя уйти в минус. Две параллельные операции на две мастер ноды обязательно должны синхронизироваться с разрешением конфликта, чтобы не разъехался баланс.
При этом теряется доступность - ждать ответа приходится долго.

🌠 Можно пожертвовать такой синхронизацией. Для ленты друзей сойдёт и согласованность в конечном счёте. Пост от одного мастера не сейчас, но вскоре долетит до другого. И далее добавится в новостную ленту пользователя. Это уже больше походит на AP систему. Можно делать пост и не ждать обновления ленты у всех друзей, чтобы пользователю вернулось "Ваш пост опубликован и сейчас уже отображён у каждого друга в ленте".
Улучшилась доступность сервиса.

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

#Requirements
https://youtu.be/nRtLkptDSxE

"История одной капчи" или...

Кручу капчу, запутать ботов хочу.

🔐 Тема защиты своего интернет ресурса в последнее время стала суперактуальной.
Компания, в которой работаю, растёт на таком спросе как на дрожжах)

📍 Существуют различные защиты, тактики отсева нелегитмного траффика. Одна из дополнительных проверок - выдача капчи. У капчи своя история. Она задумывалась как шанс для обеления подозрительного запроса.
Однако сейчас в век нейросетей AI научился проходить капчу более успешно, чем человек. Правда, не всегда.

🥷 Недавно была новость, что ChatGPT или аналогичная сеть обратилась в специальный сервис для прохода капчи, чтобы пройти проверку "я не робот".
Такие сервисы предоставляют удобное api для прогрузки капчи им, получения ответа. Подозреваю, что где-то это делают AI, где-то индийцы за 4 доллара в день.
Есть даже примерное время на разгадку определенной версии капчи.
🔑 Именитая ReCaptcha оказалась вполне по зубам для нелегитимного прохождения.

7️⃣5️⃣6️⃣ Наш сервис до недавнего времени имел лишь классическую первородную капчу с перечеркнутыми символами.
Со временем ввели понятие "сложности" от 1 до 10.
Ближе к 10ке - больше символов.

🏞 Для старта ютюб, тм каналов много времени проводил с Кадинским. Я ему запросы, он мне картинки) Запомнилась его круговая капча.
Внутри команды предложил занести такую капчу нам. Предлагающий трансформировался в инициатора. Инициатор в ответственного) Принялся за работу.

Оказывается, попытки уже были. Но подходящих вариантов найдено не было. Небольшой ресерч дал китайскую реализацию для китайского фреймворка thinkphp + js.
Хоть я ни разу не фронтендщик, но в итоге получилось отделить зерна от плевел. Стартовал капчу у себя. Сделал демо для команды.
Вариант вышел рабочий. Надеюсь, что скоро наш фронт его подтюнит и прикрепит к проекту.

✅ Прицел введения этой капчи - улучшение "user experience" владельцев телефонов. Пальцем двигать scrollbar удобнее, чем вглядываться в эти цифры.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Благодарность
Помогли по-человечески с разбором китайского проекта:
1) друг php шник
2) @danilovcodechat - канал Андрея Данилова. Ведёт ютюб канал на тему бэка, немного фронта, контейнеров.
3) @projs_ru - канал js сообщества
4) @shifu_base - канал Николая shifu, который активизировался после нескольких лет затишья. Говорит интересно о разном. В том числе о процессе обучения, жизненных моментах.

https://github.com/isszz/rotate-captcha - проект капчи.

Новое видео
Пост написал в предверии выпуска видео "Самая мощная ДДОС атака в истории человечества".

Знание актуально и в рамках security requirement в system design interview. И в целом, для понимания в каком мире сейчас живём) Хочется ясно объяснить и показать ключевые моменты. Поэтому в процессе создания что-то отбрасываю, упрощаю, дорисовываю. Сделал уже 3/4. До Нового Года должен успеть закончить)

Так что, не переключайтесь :) И берегите себя.

#Security