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

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

📍 Существуют различные защиты, тактики отсева нелегитмного траффика. Одна из дополнительных проверок - выдача капчи. У капчи своя история. Она задумывалась как шанс для обеления подозрительного запроса.
Однако сейчас в век нейросетей 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

⚡️ CQRS
4 буквы, смысл один:
"Принцип разделения операций чтения и записи"

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

На интервью нужно уметь оценивать отношение операций чтения к операциям записи.
Зачастую, чтений на порядки больше.
1️⃣ Такие чтения бывают ресурсоёмкие. К примеру, нужно много join'ить, чтобы получить нужную информацию.
2️⃣ Если использовать классический подход - одна база данных для чтений и записей - то каждым таким чтением будем нагружать БД.
3️⃣ Если есть обозреватель, которому нужно получать только определенный вид данных, то не обязательно join'ить на каждый запрос чтения.
Поэтому выделяем отдельную сущность для чтения.

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

Всё. Теперь вы знаете что такое принцип CQRS(Command Query Responsibility Segregation). И при каких обстоятельствах его применять.
Это был easy уровень. Выжимка из большого кол-ва информации в интернете.

middle уровень
🔥 Для тех, кто любит погорячее.

Такую сущность можно выделить ещё более явно. В отдельную Базу Данных. Зачем?
✅ Мы можем выбрать БД, оптимизированную под данный тип данных и под их быструю отдачу.
Также и для БД для операций записи.
✅ Положительный side-эффект от такого выделения - теперь у нас два независимых трака работы с данными!
Рушится запись? Остаётся чтение! И наоборот. Повысили отказоустойчивость системы.
Не можете сделать заказы в онлайн магазине? Печаль. Зато можете просматривать товары. Система отвалилась не полностью.

Изобрели серебряную пулю? Как бы не так.😕
Модель согласованность деградировала до "eventual consistency" - "согласованность в конечном счёте".
Теперь мы не читаем с той же БД, в которую только что записали. Где можно было бы обеспечить транзакционность.
Пишем оптимизированно в одну БД, читаем из другой. А как же свежие данные оказались доступны для чтения?

Есть различные ответы на этот вопрос.
1) Сервис между базами данных подкачивает изменения из БД для записи в БД для чтения.
2) Сервис, который пишет в БД для записи сам откидывает изменение в БД для чтения.
3) Сервис, который пишет в БД для записи кладёт записи и в брокер сообщений. Из этого брокера считывает другой сервис, который обновляет данные в БД для чтения.

❇️ Появилась дополнительная сущность, отвечающая за синхронизацию данных.
❌ Она же является и дополнительной точкой отказа.

⏱ Именно из-за этой синхронизации модель согласованности данных стала "eventual consistency".
Нужно некоторое конечное время, что перенести обновления.
В отличие от строгой согласованности, когда:
"Все пользователи всех нод в одно и тоже время видят одно и тоже значение записи."

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

А в онлайн магазине - пожалуйста. И в системе заказа еды. Или же - в системе по ведению работы с клиентами с многочисленными формализованными отчётами.

senior уровень
📗 Больше о терминах
Операции записи объединяются под термином "command" - команда. Чтобы более точно передать смысл - "отдаём команды на выполнение". Не ожидаем данных. Только подтверждение успешности выполнения/принятия команды.
Операции чтения объединяются под термином "query" - запрос. Это именно получение данных без их изменения.

📔 Event Sourcing
Обозначу, что есть системы, построенные на генерации, обмене, использование событий.
Бывает, что говоря о CQRS подразумевают использование этих event'ов. Но нет.
Это два разных подхода. Которые могут использоваться вместе.

—————
Завтра стартует High Load 2023.
Среди докладов есть "Эволюция и мифы CQRS" Андрея Цветцих. Хочу попасть к нему. Послушаю. Расширю восприятие темы.

#SystemDesignInterview #SystemDesign #CQRS