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

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

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

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

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

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

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

⚡️ 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