System Design: The Evolution of Reddit.com's Architecture

Еще одно хорошее видео про system design. В этот раз это доклад про эволюцию архитектуры Reddit. Это одна из немногих компаний, которая использует EAV модель под такой нагрузкой. Но, что еще более интересно - это рассказы про фейлы, которые у них случались. Крутая история с read репликами, когда они стали терять данные и проблема оказалась в паре очень простых строчках кода.

ССЫЛКА НА ВИДЕО: https://www.youtube.com/watch?v=nUcO7n4hek4

System Design: Scaling Instagram Infrastructure
Хороший доклад про масшабирования Instagram. От инфраструктуры до масштабирования команды разработки.

В Инстаграм достаточно стандартный стек технологий:
🔸 Бекэнд на Django
🔸 Postgres для пользователей, медиа, списков друзей
🔸 Cassandra с пользовательскими лентами и списками активностей
🔸 RabbitMQ для асинронных задач
🔸 Memcached для кеширования

Ежедневная нагрузка (2017-й год):
🔸400 млн. пользовалей
🔸4 млрд. лайков
🔸100 миллионов фото/видео загрузок

Изначально все это было в одном регионе и возникла необходимость мульти региональной инфраструктуры.

Решение:
✅ RabbitMQ: Django+RabbitMQ+Workers деплоится вместе, как одна сущность. Все асинхронные задачи выполняются в рамках одного региона.
✅ Postgres: просто read реплики переехали в другие датацентры и осталась синхронная репликация.
✅ Cassandra: просто настраивается нужное количество реплик
✅ Memcached: это самое интересное, но тут лучше смотреть видео 🙂

ССЫЛКА НА ВИДЕО: https://www.youtube.com/watch?v=hnpzNAPiC0E

System Design: Evolution of Financial Exchange Architectures

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

10 лет назад мы могли говорить про 100 тыс транзакций в секунду и отработку запроса в 1ms. Что поменялось за 10 лет? Ускорислось ли все в 10 раз. Ответ - да, мы сегодня видим 1млн транзакций в секунду и обработку запросов за 0.1ms на запрос (или даже до 0.001ms)

За 10 лет поменялось многое в мире фин. бирж:
🔸Архитектура
🔸Отказоустойчивость
🔸Производительность
🔸Деплоймент

Рекомендую доклад как минимум для расширения кругозора.

ССЫЛКА НА ВИДЕО: https://www.youtube.com/watch?v=qDhTjE0XmkE

Речь Джона Кармака в родном университете в Канзасе

Кармак один из самых крутых инженеров. Если вдруг не знаете кто это, то обязательно почитайте про его проекты 😉
8-ми минутное видео для мотивации в выходной день.

ССЫЛКА НА ВИДЕО: https://www.youtube.com/watch?v=YOZnqjHkULc

В комментах оставлю ссылку на видео с оптимизацией Quake 3 по вычислению квадратного корня (один из лучшех разборов этой оптимизации)

Шифрование/кодирование/хеширование

Часто разработчики путают эти понятия.
К примеру, человек смотрит на JSON Web Token(JWT) и думает, что данные в нем зашифрованы. Или что логин и пароль в HTTP Basic Auth зашифрован, поскольку выглядит как набор случайных символов.

Давайте разберемся в теории, а потом посмотрим на примеры.

Шифрование
Что такое шифрование мы обычно все понимаем. Тут важно только заметить, что есть симметричные шифры (для шифрования и расшифровывания используется один и тот же ключ) и асимметричного шифры (когда у нас есть пара ключей, открытый и закрытый). Также асимметричная криптография может использоваться для цифровой подписи.

Примеры: AES, chacha20, RSA

Хеширование
Основная идея, что есть некая функция (хеш-функция), которая преобразовывает произвольной длины набор данных в набор данных фиксированной длины. То есть, мы можем 1ТБ захешировать в 10 байт (например, посчитать контрольную сумму данных). Главное отличие от шифрования - это то, что хеш-функция работает в одну сторону. Мы не можем из 10 байт контрольной суммы потом получить назад наши исходные данные.

Примеры: md5, bcrypt, MurmurHash

Кодирование
Кодирование не имеет целью сокрытие информации, а просто представление данных в другой форме. Обычно это делается для более удобной передачи, более удобного хранения и тд. (можно шифрование и сжатие отнести кодированию, но часто именно говорят "сжатие", "шифрование", поскольку тогда сразу понятны дополнительные свойства алгоритмов кодирования).

Примеры: base64, multipart/form-data, urlencoded

ЧАСТЫЕ НЕДОПОНИМАНИЯ
🔸JWT пейлоад закодирован base64 и подписан, но не зашифрован
JWT состоит из трех секций, разделенных точкой.
header.payload.signature. Каждая часть закодированы base64.
Идея base64 в том, чтобы бинарные данные представить в виде печатаемых символов таблицы ASCII и соответственно клиент может считать все данные из JWT.

🔸Пароли в базе хешируются, а не шифруются
Пароли в базе должны храниться в виде хешей . Из хеша нельзя получить пароль назад (только перебором) и для усложнения перебора используются соль и хеш-функции, предназначенные для хеширования именно паролей (scrypt, argon2 etc)

🔸HTTP BasicAuth кодирует логин и пароль в base64, но не шифрует
Передает в base64 = передает в открытом виде.
Digest Authentication работает по другому и использует уже md5 хеширование.

🔸В SSH при аутентификации по ключу мы не передаем приватный ключ на сервер
Если вас просят предоставить приватный и публичный ключ, чтобы настроить доступ к серверу, то никогда не давайте приватный. Нужен только публичный. Кроме того, даже во время аутентификации, приватный ключ всегда остается только на вашем компьютере.

🔸Для шифрования трафика в HTTPS используется симметричный шифр, а не пара из публичного и приватного ключей
Многие думают, что для шифрования трафика используется пара из публичного и приватного ключей, но на самом деле используется сессионный ключ и симметричный шифр (типа AES или Chacha20). Публичный и приватный ключ используется только во время установки TLS соединения.

Стоит ли углубляться в детали в следующих постах?
Делать разбор работы HTTPS, base64, хеш-таблиц и тд

Немного офтопа про гонки 🙂

У меня есть хобби - гонки на треке (участвую в "Carrera Time Attack Series"). Поскольку я начинающий пилот, то приходится много всего изучать и прокачиваться.

Чтобы не терять ссылки, я сделал еще один телеграм канал, в которые забрасываю ссылки на полезный контент, связанный с гонками и моим прогрессом. Канал решил вести на английском.

Подписывайся, если интересно 🙂

ССЫЛКА НА КАНАЛ: https://t.me/newbie_racer

Мой переход в Google Cloud (и на позицию Non-Executive Director в WebbyLab) 😎

Не так давно кто-то в одном из чатов спрашивали не думаю ли я пойти в какую-то компанию из FAANG. На самом деле, мысли такой не было, но иногда приходили предложения пройти собеседования. И вот в ноябре 2020 года поступило предложение пройти собеседование в команду Google Cloud. Мне нравится Google, интересны их подходы, я постоянно использую их продукты, а работа в Google Cloud еще близко к моим интересам. Я решил попробовать свои силы. В Google есть 2 вертикали - техническая и менеджерская. Думаю, что мне проще было бы собеседоваться на менеджерскую позицию, но мне интересна была именно техническая позиция. Суммарно у меня было около 20 созвонов до получения оффера, с них 6 собеседований по типу экзаменов, 3 Google Team Fit созвона и разнообразные другие онлайн встречи.

Все собеседования, где нужно было писать код, я писал на JavaScript. Можно выбрать и любой другой язык. К примеру, в 2014-году я использовал Perl на собеседованиях. В тот раз это была позиция Google SRE в главном офисе в Mountain View. Тогда я зафейлил 4-е собеседование, но это отдельная история 🙂

Если вкратце, то занял весь процесс 4 месяца. Я не знал пройду ли до последнего момента, но в результате получил хороший оффер и классную позицию в крутой команде. В результате решил согласиться :) В WebbyLab же я перехожу с должности CEO на позицию Non-Executive Director.

Старт через неделю. Лето я пока еще в Киеве работаю удаленно, а вначале осени релокейт в Варшаву.

Руки чешутся приступить к задачам 🙂. Я не знаю, что из моей работы можно будет обсуждать публично, поэтом пока ничего не могу обещать. Но ожидаю, что качество контента только вырастет. История с youtube каналом тоже не стоит на месте 😉

И вдогонку к предыдущему посту. Скорее всего, в дальнейшем мне нужно будет согласовывать доклады с Google. По сути, в этот четверг (3-го июня в 19:00 EEST) у меня последний доклад вне Гугла.

🔥🔥🔥И планируется не просто доклад, а совместное обсуждение с Еленой Жуковой и Андреем Мелиховым вопроса, как выростить сильных разработчиков и как собирать сильные команды. 🔥🔥🔥

Проходит это все в рамках JavaScript fwdays’21. Регистрируйся! Там много интересных докладов, а первый эфир уже завтра утром! Ребята из fwdays постарались 💪

Есть бесплатные билеты(позволяют посмотреть доклады бесплатно во время конференции) и платные (дают доступ к записям докладов, но регистрация нужна в любом случае!

БИЛЕТЫ ТУТ: http://bit.ly/3eEGHdk

WebbyLab developers baseline
Только что закончили беседу про команды на fwdays. Получилось у нас не сильно структурировано, но душевно 🙂. Просто в формате стрима. И в связи с этим хотел поделиться документом, который вспоминал во время обсуждения.

Этот документ описывает базовый набор общих знаний для разработчика (frontent, backend etc). Это маленькая толика того, что дается в университете и что может пригодиться на работе, поможет в проектировании, поможет в отладке приложений, поможет в собеседованиях.

Мы внедрили это в WebbyLab и сейчас активно дорабатываем, тестируем процесс приемки. Не ожидайте, что там что-то сложное. Это про очень базовые концепции и навыки. Мы специально избегали сложных задач, все-таки это baseline, которым должны владеть все джуны. Но одновременно и опытные разработчики иногда находят что-то новое для себя.

Попробуйте сделать даже просто для себя все эти задачки.

ССЫЛКА НА ДОКУМЕНТ: https://bit.ly/3vO4EFa

Как вам документ? 🙂

Хитрости при кэшировании

Пару дней назад с коллегой на работе обсуждали инвалидацию кэшей и я вспомнил подход, который мы использовали на mail.ua еще в 2008 году. Когда при изменении одной сущности в базе, вы должны инвалидировать множество ключей. Для этого мы тегируем все связанные ключи, которые нужно будет инвалидировать определенным тегом с версией. И когда хотим все инвалидировать, просто увеличиваем глобальную версию тега (хранится отдельно). Затем при вычитке данных из кэша мы смотрим не устаревшая ли версия тега там.

Это интересный подход, который может быть полезен в различных ситуациях. К примеру, такой подход я использовал и при написании движка Excel на JS. Для каждой ячейки есть кэш, и когда пользователь нажимает recompute, то нужно сбросить все кэши в ячейках и затем постепенно наполнять по время расчета. В связи с этим в каждой ячейке хранится версия кэша, если она устарела (то есть меньше глобальной версии, которая инкрементируется при вызове recompute), то кэш считается невалидным.

Очень хорошо описано в этой статье 2008 года: https://habr.com/ru/post/43539/

Рекомендую все серию статей, там много интересных трюков. К примеру, мы тогда использовали такой же "Счетчик онлайнеров". (Термин "фронтенд" относится именно к серверам, а не к UI приложению. Не запутайтесь)

Пишите в комментариях, какие еще интересные подходы приходилось использовать при работе с кэшами 🙂

Серия выпусков про облака на Software Engineering Daily
Когда-то я уже писал про мой любимый инженерный подкаст - SE Daily

На этой неделе вышла целая серия с обсуждениями всех облачных провайдеров: AWS, Google Cloud, Digital Ocean, MS Azure, Oracle Cloud.

✅ AWS with Pete Cheslock
✅ Azure with Troy Hunt
✅ GCP with Liz Fong-Jones
✅ Digital Ocean with John Allspaw
✅ Oracle Cloud with Salman Paracha

Это из вас не сделает специалиста по облачной инфраструктуре, но явно добавит контекcта.
Рекомендую!

Случай с потерянными DNS пакетами

В поддержке Google Cloud есть такие ребята, как TSE (Technical Solutions Engineer) - это такие себе мастера дебага. Они годами работают над решением различных технических проблем заказчика и многие их истории просто великолепные. Одна из таких историй есть в публичном доступе.🙈

По сути, это крутая история про вопрос с собеседования "Что происходит, когда вы адресную строку браузера адрес и нажимаете enter" 🤓
Рекомендую к прочтению!

ССЫЛКА: https://cloud.google.com/blog/topics/inside-google-cloud/google-cloud-support-engineer-solves-a-tough-dns-case

Как вам история? 🙂

Доклад про Developers Baseline на Odessajs 2021

В эти выходные (28-29 августа) буду в Одессе на OdessaJS (https://odessajs.org) с докладом про Developers Baseline (https://t.me/jabascript/125).

Выступаю на OdessaJS уже 4й год. Всегда приятная атмосфера, доклады на берегу моря, крутое автепати 🔥🔥🔥

Если соскучились по оффлайн ивентам, то специально для подписчков канала попросил скидку. Вот промокоды:
✅ speakers_friends@odessajs - 15% скидки
✅ TurskyiFriend@OdessaJS50 - 50% скидки на 4 использования

Пишите в комментах, кто тоже будет на ОдессаЖС 🙂

До встречи в Одессе!

System Design Interview
Многие крупные компании требуют прохождения System Design Interview, еще его называют NALSD (Non-Abstract Large System Design) Interview .

Ваша задача - уметь понять требования к системе и спроектировать ее.

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

И уже делился серией постов со ссылками на интересные доклады:
✅ Real-Time Delivery Architecture at Twitter
✅ The Evolution of Reddit.com's Architecture
✅ Scaling Instagram Infrastructure
✅ Evolution of Financial Exchange Architectures

Но если вы только начинаете, то где изучить азы?

Основная проблема в том, что многие видео на Youtube по System Design сделаны людьми, которые сами просто готовятся к собеседованиям, но такие системы не строили. И часто в этих видео не хватает глубины.

🔥Но есть канал на Youtube, который я очень рекомендую. Канал уже давно не обновляется и на нем всего 6 видео. Автор начал записывать, а потом бросил по какой-то причине, но сразу чувствуется, что человек в теме :)

ССЫЛКА НА YOUTUBE КАНАЛ: https://www.youtube.com/c/SystemDesignInterview/videos
Смотрите все 6 видео от самых старых к самым свежим!

Как Uber реализовал в своем мобильном приложении фейловер переключение между серверами?

В WebbyLab мы всегда задаем на собеседованиях вопрос: "Что происходит, когда пользователь вводит в адресную строку браузера URL, с момента нажатия enter и до момента возврата страницы". Задаем мы его всем: фронтендерам, бекендерам, мобильщикам, тестировщикам, джунам, мидлам, сеньорам и милордам. Важно, что если, человек занимается разработкой интернет-приложений, чтобы он знал хоть немного про то, как работает Интернет. Да, все знать нельзя, но и для разных позиций ожидается разный уровень знаний. На практике я много раз наблюдал ситуацию, когда сотрудники, которые видят более полную картину, приходят к более эффективным решениям.

В контексте этого, решил поделиться хорошей статьей от Uber, как они реализовали failover handler на фронте (хоть и мобильном) -
https://eng.uber.com/eng-failover-handling/

Вышло 3х минутное интервью со мной с OdessaJS 2021 🙂
Получилось позитивно - https://youtu.be/wifIrqzRkug
Спасибо организаторам за крутой ивент!

Также должно быть видео доклада, но скину его скоро отдельным постом вместе с детальным анонсом платформы https://my-talks.net/

my-talks.net - открытая бета нашей платформы для спикерского портфолио.

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

Так появился my-talks.net 😀

Что можно сделать при помощи сервиса?

Для спикера:
✅ Удобно хранить доклады со ссылками на видео в одном месте (легко добавлять доклады, когда с одной темой на нескольких конфах выступал).
✅ Использовать как ссылку в CV (или в профиль Linkedin)
✅ Скидывать организаторам конференции, когда нужно предоставить список докладов (вместо со ссылками на презентации и видео).
✅ Доклады в выдаче Googlе (уделяем много внимания SEO)

Для слушателей же это возможность:
✅ Найти все доклады спикера в одном месте
✅ Подписаться на спикера
✅ Попросить уведомить про появления видео к докладу (прошедшему или предстоящему).

Для организаторов конференций это возможность найти спикера.

Работа по сервису еще в процессе, но движется очень активно. Вот так выглядит список моих докладов на нем - https://my-talks.net/viktor-turskyi

Как помочь сервису:
✴️ Добавить свои доклады или подписаться на спикеров
✴️ Сообщить о багах
✴️ Нарисовать логотип. Нам очень нужен :)
✴️ Предложить идея для монетизации.
✴️ Фидбек по улучшению сервиса
✴️ Скидывайте ссылки, если знаете похожие сервисы (я не нашел ничего такого)

Как вам сервис? 🙂

VSCode в браузере 😎
Вы просто заходите на https://vscode.dev/ и сразу пользуетесь VSCode. Удобно, когда рабочее окружение не требует настройки и можно начать работать в привычных инструментах сразу. VSCode - это только часть экосистемы, нужно закрыть остальные аспекты всего процесса разработки. Github Codespaces как раз пробует решить эту проблему. Интересно будет понаблюдать за другими игроками рынка.

Но главное, чем я хочу поделиться, это докладом Эриха Гаммы (один из авторов gof-овских "Design Patterns") про то, как они в MS 10 лет разрабатывали VScode - история создания и интересные архитектурные решения.
Легкое получасовое видео для вечера пятницы 😉

ССЫЛКА НА ДОКЛАД: https://www.youtube.com/watch?v=hilznKQij7A

Доставили книгу. Детально описывает процессы и тулинг Гугла (написана гуглерами и некоторые используют для оебординга ее). Интересно будет сравнить с реальностью все 🙂
Книга есть в электронке даже
https://abseil.io/resources/swe_at_google.2.pdf

Напишу в канал небольшое ревью после прочтения.

Пишите в комментах, какие книги по разработке вам понравились. Что полезного можно прочитать разработчикам? 🙂

Должен ли фронтендер думать про XSS?

Коротко: Да! Должен!

Я уже не один раз слышал от фронтендеров, что за безопасность должен думать бэкенд разработчик и пускай там делают защиту от XSS. Да, на бэкенде можно снизить риски (к примеру, настроить CSP было бы правильно), но корневая причина находится именно на фронте. И это ответственность фронтендера думать про защиту от XSS.

Кстати, с валидацией данных, мы имеем зеркальную ситуацию: фронтенд может делать валидацию, но бэкенд обязан. 🙂

Почему фронтендер?
⭕ Причина 1️⃣: XSS - это проблема процесса рендеринга данных.
Одни и те же данные можно использовать по разному в разных ситуациях и разных клиентах (браузер, консоль, мобильное приложение). И мы должны рендерить данные безопасно. Сегодня они могут прийти с надежного бэкенда, а завтра с какого-то внешнего, к примеру. Нет причины, чтобы использовать небезопасный рендеринг на клиенте (возможно за редким исключением).

Если этой причины мало, то переходим к следующей 🙂.

⭕ Причина 2️⃣: бэкендер не следит за изменениями фронтенда.
Бэкенд-разработчик на заморачивается у вас там просто textarea на фронте или WYSIWYG-редактор.

Давайте проведем мысленный эксперимент. У нас есть REST API endpoint, который возвращает информацию про пользователя и там два поля: "name" и "bio". Эти два поля отображаются обычным текстом в интерфейсе. И тут приходит продакт-менеджер и говорит, давай дадим пользователям возможность форматировать текст в bio. Ты подключаешь какой-то редактор и в этот момент твое приложение становится уязвимым к XSS, если ты про это не подумаешь.

Почему так произойдет?
❓ Есть ли гарантия того, что бэкендер знает, что нужно сделать изменения на бэке, если задача была чисто фронтовая?
❓ Есть ли гарантия того, что ваш продакт-менеджер поставит бэкендеру задачу про XSS вместе с фронтовой задачей для тебя?
❓ Если ты не знаешь про XSS, то как ты поставишь задачу бэкендеру?
❓ Если ты не знаешь про XSS, то как ты добавишь защиту на фронте?

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

Если этих двух причин мало, то переходим к следующей 🙂.

⭕ Причина 3️⃣: бэкенд должен знать про верстку фронта, чтобы сделать правильную защиту.

Стандартный механизм защиты это использования санитайзера (внешния библиотека типа DOMPurify) Никогда не используйте регулярки для защиты от XSS❗.

Но это настолько стандартная для фронтенда задача, что сейчас утверждается браузерный API (https://wicg.github.io/sanitizer-api/). Только это уже говорит о том, что этим должны пользоваться фронтендеры.

Но проблема еще более интересная. Если вы посмотрите на API, то вы заметите, что санитайзер должен знать в какой элемент рендерится html разметка, поскольку это влияет на алгоритм парсинга.

Цитирую: "If the user data is available in string form and the developer wishes to sanitize it now, but apply the result to the DOM later, then the Sanitizer must be informed about the context that it will be used."

Примеры:
sanitizer.sanitizeFor("div", htmlMarkup);
sanitizer.sanitizeFor("table", htmlMarkup);


То есть бэкенд не просто должен знать, что вы будете использовать строку как html, но и должен знать как у вас сверстана страница.

Общий вывод: фронт не должен ожидать безопасных данных с сервера и должен думать про безопасный рендеринг всегда!

Надеюсь, мне удалось убедить фронтендеров задуматься про XSS 🤓