Оформил впечатления о сегодняшнем HighLoad++ в хабр статью.

Милости прошу 😊
https://habr.com/ru/articles/776816/

#conference

Успел закончить монтаж интервью до Нового Года😊

✅ Создал новый канал "Владимир в IT" 🎉
Посвящён интервью, конференциям, новостям из мира IT.
🎓 Также буду выкладывать наработки по программированию - посты, видео.

😊 Приятного просмотра!
🎄 С Наступающим!

https://t.me/vladimir_v_it/28

Блокировки в Базах Данных в нагруженных системах.

❗️При большом количестве конкурентных запросов возрастает риск обращения к одним и тем же данным.
😔 Поэтому обычную выборку данных, их изменение и последующее обновление уже не получится сделать также просто как на локально поднятой БД, к которой доступ имеете только Вы.

❓Как же изменить данные и оставить их в согласованном состояние?

На этот вопрос ответит переведенная мною на днях и выложенная на хабр статья:
https://habr.com/ru/articles/784750/

📖 Alex Xu. Куда ж без тебя.

💡 Если мы хотим продвинуться в теме System Design, то с книгой "System Design Interview" от Alex Xu никак не разминуться.
Её ценность каждый читатель оцениваем сам. Кто-то считает, что представленные шаблоны не правильные. Другому материал книги оказывается полезным ☝️

📝 В своё время при прочтение книги написал рецензию в комментариях на хабре.
Это не размышление об очередном паттерне или лайфхаке как шустро пройти интервью. Скорее оценка годности материала.

🎓 На мой взгляд, если хочется продвинуться в теме дизайна систем, книгу почитать стоит. И также самому сделать вывод, насколько материал оказался полезен.

https://habr.com/ru/companies/piter/articles/598791/#comment_24626358

#Books

Клеппман Мартин. "Высоконагруженные приложения". Переоценённая находка

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

🥺 Легкого старта с ней у меня не случилось. Лишь позже я понял, что первое данное мне впечатление "лёгкой для понимания книги" сбило с толку.
Когда происходил затык с пониманием, сразу же приходила эта фраза. Которая далее порождала неуверенность в себе: "Ведь для людей она лёгкая! А ты тут разобраться не можешь".

3️⃣ Не так давно описал как прочитал её почти 3 раза, чтобы лучше разобраться в понятиях.
💡 Сделал вывод, что не Клеппманом едины. Что нужно много разных источников информации, чтобы лучше разобраться даже в одном небольшом разделе.

#Books

Шардирование. Разносим данные по серверам.

#cheat_sheets

📗 Книгу "Web scalability for startup engineers" советуют как более лёгкую, в сравнение с Клеппманом.
Встретил её совсем недавно.

Давайте по ней изучим Шардирование. Сделал перевод начала раздела стараясь выразить суть и уложится в формат поста телеграмма.

Сценарий
📈 Возрастают нагрузки на 1 сервер с Базой Данных. Необходимо разделить данные по серверам.

Проблема
➡️ Для получения данных, нужно не опрашивать все сервера, а пойти на целевой - где эти данные находятся.

Решение
🔑 Использовать ключ шардирования - сущность, которая позволит определить целевой сервер.

Пример
📦 Онлайн магазин. Сервис изначально имел одну Базу Данных. Для горизонтального масштабирования необходимо распределить данные по серверам.
Необходимо понять, по какому признаку произвести распределение. Поскольку пользователи в магазине не взаимодействуют друг с другом, можно распределить по пользователям.
Тогда при необходимости обновления или получения данных о пользователе запрос пойдёт в определенный инстанс БД.
Пользователя можно идентифицировать по полю user_id - уникальному идентификатору пользователя. Такой id и будет называться ключом шардирования.

Алгоритм шардирования
⚙️ Осталось понять какой user_id к какому серверу будет отнесен. Для этого выбирается алгоритм маппинга/роутинга/маршрутизации/распределения.
Для простоты, у нас есть 2 сервера БД == 2 шарда. В качестве алгоритма будет определение чётности.
Его можно реализовать с помощью операции взятия остатка от деления: user_id % 2 => 1, 0
Получаем распределение данных по признаку "чётности".
Шардировать можно средствами самой БД. Или же создать дополнительный слой/сервис для маршрутизации.

#Books #Sharding

Почему взлетел "Тинькофф"?

Расписал начало нашего интервью с техническим директором Тинькоффа Александр Поломодовым в текстовую статью.

Затронутые темы:
1️⃣ Развитие компании, переход на свою технологическую платформу;
2️⃣ Вклад в сотрудников, возможности роста за достижения;
3️⃣ Рождение System Design Interview. Мотивация введения этого этапа интервью.

https://habr.com/ru/articles/784860/

📖 Нужно больше шардирования!

⚡️Ребята с #faangtalk пригласили выступить со своей темой.
Поскольку последний контекст был про шардирование, решил про него глубже и шире рассказать.

📍Рассмотрим исторический контекст, алгоритмы шардирования, проблемы миграций данных.
Также посмотрим, как AliExpress внедрил свой велосипед для шардирования PostgreSQL баз данных для управления 8 ТБ данных.

🎦 Встретимся у них 20 февраля.

#Sharding

Mock Interview. URL shortener.

💡Важный аспект подготовки к интервью - практика.
В случае System Design интервью её можно получить как на самом интервью, так и заранее - сходив на мок интервью.

✅ Нашёл руководителя одного из подразделения BigTech компании для проведения мока со мной.
Задача выпала такая:
"Разработать сервис по сокращению url"

▶️ Держа в голове схему прохождения принялся за дизайн.
Получалось бодро проходить по шагам интервью. Неожиданно для себя шустро делал вычисления🙂
Порой интервьювер замолкал. Воспринимал это за сигнал для проявления инициативы.
Спрашивал - "Подойдёт ли такое решение? Переходим к следующему этапу?".
Ведь собеседование - это обоюдный процесс. Монолог здесь не проходит.

⏰ Уложились в 53 минуты.
После была дана ценная обратная связь.

Сделал обзор этого мока. Сократил до 8 минут выделяя основные этапы:
Обзор mock интервью по System Design. Url shortener.

#Interview

🌠 Mock Interview. URL shortener. II.

📝 В этот раз интервьюировал уже я.
Делал краткие заметки по ходу интервью.

⚙️ Этапы интервью
Немного изменил условия. Собеседник бодро шёл по пунктам проектирования.
1. Начал с уточнений функциональных, нефункциональных требований. Очертил скоп задачи.
2. Рассчитал нагрузку.
3. Создал подробное REST API.
4. Нарисовал небольшой дизайн.
5. Расписал 2 версии генерации короткого url.
6. Ответил на дополнительные вопросы.
7. Обратная связь.

При этом, добротно комментировал. В инициативном порядке переходил к следующим пунктам.

❓Редкие вопросы
Видя его бодрый настрой старался не сбивать. Из самых больших вопросов спросил:
1) "Что будет, если короткой ссылки не окажется?" До этого был расписан лишь "happy path" в api.
2) "Давай вернёмся к требованиям и проверим, всё ли реализовали?". Чтобы натолкнуть на мысль по поводу самого сервиса генерации. До этого был описан лишь алгоритм, без подробностей кто его будет исполнять. И как с этим кем-то будут взаимодействовать его бэкэнд stateless сервисы.
=> Дорисовал оранжевый ромб. Объяснил взаимодействие.

💤 Медленная SHA
Я хотел сказать, что SHA может оказаться медленной.
Потом вспомнил, что условие "Получать url как можно быстрее" было в ранее решаемой мною задачи. А здесь я его не указал.
Можно взять на заметку, что криптографические функции медленные. Если есть требование по скорости и есть другой вариант(здесь 2ой - последовательное деление по модулю числа) - лучше выбрать его.

⏱ Тайминг.
ts - завершенная активность
5 - чтение задачи, уточнение ф/нф требований, цифр
11 - подсчёт места для хранения данных
19 - создание API
22 - верхнеуровневый дизайн системы
33 - описание алгоритмов
43 - размышление о storage - SQL, NoSQL, sharding
46 - финал, ответ на вопрос по требованиям
50 - доп вопрос(*) - "Как будем мониторить систему? Как понимать, что она работает?"
55 - доп вопрос(**) - "Стартап пользуется популярностью. Решили ввести платный функционал. Пользователь сам можем задать свой короткий желаемый url."

#Interview

🔱 Не боги горшки обжигают

▶️ Доступность, отказоустойчивость, избыточность - популярные термины из мира System Design.
⛔️ Почему же сверхнагруженная и быстрая биржа "не сумела в System Design"? Почему лишь один сервер? И не совсем горячий failover.
Там нет таких собеседований на входе? Или дело в другом?

#Question #RealLifeExample

📹 Mock Interview. URL shortener. III. English version.

✍️ Закрепим тему 3им решением.
Сегодня в онлайн проведём интервью с англоговорящим коллегой.
Если есть пожелания по дополнению требований, условий задачи - you are welcome :)

✅ Кандидат поддержал идею наблюдателей.

🕗 8 p.m. GMT+3 / 20:00 по Москве.

https://meet.google.com/wky-yehd-saw

#Interview