📦 Файловое хранилище спроектировано. Полюбуйтесь!

✴️ Чёткое проектирование по шагам. Кандидат видел основную линию дизайна. Делал отсылки к дополнительному функционалу. Один из которых - построение аналитическое подсистемы - в конце и реализовал.

🎟 Из фишек самого видео - вставлены визуальные памятки наступления очередных этапов. Добавлены заметки на полях в качестве дополнительного обучающего слоя чтобы польза от просмотра видео для Вас была максимальной.

😊 Приятного и полезного просмотра!

❓ Как считаете, реализация какой части функциональных требований оказалось самой сложной?

https://youtu.be/t4akRxFCAHc

#Interview

📣 Архитектурная ката на финишной прямой!

🎢 Собираемся в команды и поехали 23.06.2024 в 15:00!

🧾 План мероприятия:
1) Общая встреча участников и организаторов. Знакомство. Распределение по командам.
2) Презентация задачи.
3) Q/A секция - уточняющие вопросы от команд, ответы.
4) Проектирование.
5) Презентация решений.

Регистрация заканчивается с наступлением 20.06.2024.

🎬 Для тех, кто не сможет принять участие - запись планируется.

И, всё-же, в онлайн гораздо круче) Поэтому ждём участников любого уровня. Главное, чтобы с горящими глазами🤩

✍️ Отмечайся в чате System_Design_Chat. Вначале ответь боту кто ты.
Затем:
1) Хочу участвовать в Архитектурной Кате 23.06.2024
2) Готов быть лидером команды

👍 - ставь палец, если идея нравится)

#ArchitecturalKata

⭐️ Стартовал архитектурный хакатон ARCHI.Tech от ВТБ

🎓 Вчера состоялся митап-открытие. На нём организаторы описали ожидаемый результат от решения будущей основной задачи, которую предоставят 28.06.24.
Также показали своё решение демо задачи. И разминочную задачу, за которую можно получить дополнительные 3 балла.

📝 Мы сразу же собрались командой и создали скелет решения.
Старались освятить все пункты ожидаемого результата:
1) Функциональная структура
2) Архитектура данных
3) Архитектура системы
4) API взаимодействия с пользователем
5) API взаимодействия компонентов
6) Архитектура развёртывания

⚙️ Причесать решения нужно успеть до 28.06. До этого числа можно и зарегистрироваться.

❓ А ты участвовал в хакатонах? Как считаешь, какая от них польза?

⚡️ Если задача интересна и хочешь увидеть её разбор, ставь лайк, соберёмся после хакатона.

#Hackathon

🧩 HTTP + Нина. Зажигательная комбинация!

😇 Мне посчастливилось улучшить понимание HTTP 2 раза.

1️⃣ Первый - послушал вживую доклад Нина Пакшиной про HTTP3.
Очень ёмко, последовательно и структурировано Нина освятила:
1) Эволюцию HTTP
2) Различие в транспорте 2 и 3 версий HTTP
3) QUIC vs TCP
4) Работу HTTP/3 в Go
Если хочешь улучшить своё понимание работы этого популярного протокола, запись доступна здесь!

2️⃣ Второй - Нина напишет на канале ряд постов про HTTP!😊

💪 Двойная польза
Да-да, реализуется тот самый двойной формат подачи, о чём писал ранее:
1) На канале размещается видео контент;
2) А также полезная информация в формате постов, для тех кому ближе чтение.

👩🏼 Нина - кто ты?
Давайте познакомимся с Ниной ближе - новым автором канала!

Нина, привет! Я знаю тебя как старшую разработчицу Go и активную участницу Московского Клуба Программистов. Ничего не перепутал? 😊

Да, все верно. Когда я присоединилась к Московскому клубу программистов, я программировала ПЛК (контроллеры для автоматизации промышленных объектов) Потом несколько лет писала на Python в онлайн ритейле. И уже три года пишу на Go!

В какой команде ты работаешь, за что отвечаешь?

На своей основной работе в Ленте Онлайн я работаю в команде операций. У меня большой стек задач, который включает сбор статистики, управление персоналом и заказами. В команде мы работаем с большим количеством микросервисов, основная часть из которых написана на Go.

Что больше всего нравится в твоей работе?

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

На митапе ты сказала, что решила сделать доклад, потому что самой было интересно разобраться как в самом протоколе HTTP3, так и в его реализации на Go.
Откуда взялось такое желание?

Я работаю в IT области уже больше 13 лет. Работала в области промышленной автоматизации, кибер безопасности, онлайн ритейле. И постоянно моя работа очень тесно была связана с сетями передачи данных, а конкретно с протоколами стека TCP/IP. За развитием QUIC и HTTP/3 я слежу с 2020 года. И считаю, что за ними большое будущее как в ритейле, так и в промышленных сетях.

Стоит ли использовать HTTP/3 в своих проектах и есть ли у него перспектива?

HTTP/3 уже поддерживается почти всеми популярными браузерами и 30% сайтов в интернете работают с HTTP/3.
Вы можете ускорить взаимодействие пользователей с вашим веб-приложением. А как именно - смотрите доклад или ждите постов!

Классно!

Я уже списывался с тобой по поводу идеи по написанию серии постов про HTTP. Давай ещё раз спрошу в рамках этого небольшого интервью - как тебе идея написать несколько постов по HTTP, поделится своим видением протокола, его эволюцией? :)

Это отличная идея, в самом ближайшем посту я расскажу про первые две версии HTTP - 0.9 и 1.0, а в дальнейшем освещу особенности версий 1.1, 2.0 и 3.0.

Желаю тебе удачи! И если участникам сообщества посты заходят, чтобы смело ставили лайки за твои старания!

👏 - поддержим начинание нового автора!

Ссылка на доклад Нины

#Protocols #HTTP

HTTP

Протокол HTTP (HyperText Transfer Protocol, Протокол передачи гипертекста) был опубликован в 1991 году как часть экосистемы для обмена гипертекстовыми файлами HTML, которая позже получила название WWW (World Wide Web).

HTTP — это простой протокол, главной задачей которого стала отправка с сервера клиенту документов HTML в текстовом представлении. В качестве транспортного уровня HTTP стал использовать надежный протокол TCP поверх IP.

HTTP/0.9

Самая первая версия HTTP, которая впоследствии стала называться HTTP/0.9, была очень простой и поддерживала следующий функционал:

1️⃣ Запрос от клиента с методом GET

GET /page.html

2️⃣ Ответ с сервера с HTML данными:

<html>
    Hello world!
</html>

HTTP/1.0

Сеть WWW начала развиваться очень активно. В конце 1994 года в WWW насчитывалось около 2,7 тысяч сайтов, а в 1996 году — уже более 100 тысяч!

При этом HTTP/0.9 был крайне ограничен в своих возможностях, поэтому в 1996 году появился стандарт HTTP/1.0 с дополненным функционалом:

1️⃣ Новые методы HEAD (получение метаданных о документе) и POST (отправка данных на сервер).

2️⃣ Поле версии протокола, которое отправлялось при каждом запросе с клиента.

3️⃣ Заголовки для запросов и ответов, отображающие дополнительные метаданные:

POST /image.gif HTTP/1.0
User-Agent: Windows 3.1

4️⃣ Поддержка отправки сервером документов, отличных от HTML, с помощью заголовка Content-Type.

5️⃣ Коды статусов ответов, например, 200 (Статус OK) или 418 (Я чайник):

200 OK
Date: Wed, 16, Nov 1994 10:12:34 GMT
Content-Type: text/gif
(image gif)

Несмотря на серьезную доработку протокола, веб-страницы в WWW становились более сложными, насыщенными графикой, мультимедиа и интерактивными элементами. HTTP/1.0 не справлялся с возросшими требованиями, что приводило к значительным задержкам и нагрузке на серверы.

ℹ️ Именно поэтому, появилась новая версия HTTP/1.1, но о ней мы расскажем в следующем посте.

(На изображении справа первый веб-сайт в WWW)

#Protocols #HTTP

Да начнётся Saint Highload++ 2024!

💪 Высокие нагрузки - это про нас!

📆 Закончилась 2ух дневная конференция по высоконагруженным отказоустойчивым распределенным системам Saint HighLoad++. На которой мне посчастливилось побывать 😊

🔆 На канале мы проводим System Design Interview по таким системам. Сделали уже 1ую архитектурную кату. Публикуем посты по этой тематике. Пора выполнить обещание и описать прохождение этой релевантной для канала конференции.

✏️ Сделал это в форме habr статьи.

▶️ Приятного чтения :)

❓ Как часто посещаете конференции и зачем?

#Articles

Продолжение постов об эволюции HTTP

HTTP/1.1

Новая версия HTTP/1.1 была впервые опубликована в 1997 году в RFC 2068, а в 1999 году стандартизирована в рамках RFC 2616.
HTTP/1.1 собрал в себе много важных доработок:

1️⃣ Новые методы: PUT (создание или обновление ресурса), DELETE (удаление), OPTIONS (параметры соединения), TRACE (трассировка запроса), CONNECT (установка туннеля к серверу), PATCH (частичное обновление, добавлен позже в 2010 году в RFC 5789).
Например, запрос:

TRACE /page HTTP/1.1
Host: example.com


Ответ:

HTTP/1.1 200 OK
Content-Type: message/http

TRACE /page HTTP/1.1
Host: example.com

2️⃣ Виртуальные хосты: до этого на одном IP-адресе мог располагаться только один веб-сайт. Обязательный заголовок Host позволяет использовать несколько веб-сайтов с одним IP-адресом:

POST /path HTTP/1.1
Host: example.com

3️⃣ Постоянные соединения (persistent connections): клиент и сервер HTTP/1.1 по умолчанию поддерживают постоянное соединение (с помощью keep-alive TCP/IP). Каждый новый запрос отправляется через это установленное соединение, что экономит время и ресурсы для каждого запроса.

4️⃣ Множество соединений (simultaneous connections): клиенты могут открывать несколько TCP-соединений к одному серверу, что позволяет параллельно загружать ресурсы и уменьшает время загрузки веб-страниц. В современных браузерах обычно используется до 6 соединений на один сайт.

5️⃣ Передача данных частями (chunked transfer encoding): HTTP/1.1 позволяет отправлять ответы частями, что особенно полезно для динамически генерируемого контента. Например, ответ отправляемый частями:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

4
Test
7
Message
0

6️⃣ Конвейерная обработка (pipelining): клиент может передавать на сервер несколько запросов, не ожидая ответов. В ожидании получения дополнительных запросов сервер поддерживает соединение открытым в течение настраиваемого интервала (обычно 15 секунд). Это позволяет уменьшить накладные расходы на установление TCP-соединения.

При всех своих нововведениях HTTP/1.1 имел следующие недостатки:

1️⃣ Ограниченная производительность за счет того, что все запросы в рамках одного соединения выполнялись последовательно. Большое количество запросов в одном соединении создает очередь из запросов (request queuing), увеличивая время обработки запроса.

2️⃣ Количество одновременных соединений ограничивалось браузерами, что замедляло работу. При этом множество открытых соединений потребляло много ресурсов.

3️⃣ Head-of-line блокировка, которая возникает, когда задержка в обработке запроса/ответа блокирует обработку последующих запросов/ответов, использующих то же соединение. Такая блокировка возникает, если количество допустимых параллельных запросов в браузере исчерпано, и последующие запросы должны ждать завершения предыдущих.

4️⃣ Запросы имели огромное количество заголовков, которые дублировали друг друга и не сжимались, генерируя большое количество передаваемых данных и снижая производительность.

ℹ️ Эти недостатки были решены в версии HTTP/2.0, о которой мы расскажем в следующий раз!

❔А какие методы HTTP вы используете в своей работе?

Автор: Нина Пакшина
Нина создала свой youtube канал, где выкладывает видео, посвященное языку Go. Подписывайтесь, если актуально.

#Protocols #HTTP

🎗 Как мы попали в финал Архитектурного Хакатона от ВТБ

▶️ О Хакатоне мне сообщила Нина. Желание поучаствовать материализовалось в клике мышкой на слове "Регистрация" буквально сразу же.

🆒 На площадке была возможность собрать команду из участников. Хотя, можно выполнять задания одному. После создания команды "System_Design_World" разослал приглашения.

🌠 Команда
Хакатон мы также обсуждали сообществом в чате канала. На ранних этапах команде помогал Игорь, Саша. Позже Светлана.
Core командой стали:
1) Я - Владимир, бэк
2) Элеонора, которая приняла приглашение на платформе. Крутой аналитик.
3) Сулейман, с которым знакомы уже давно. Крутой бэк, архитектор.

💪 Разминочное задание - 2/3
За сделанное необязательное разминочное задание нам дали увесистые 2 балла из 3ёх возможных. Мы обсудили что можно улучшить на финальном задание.
Казалось бы, 1 недостающий до идеала балл - это не так уж и много. С другой стороны - это не полученные 33% от лучшего результата 🤔

🕧 Ready?...
18:00, вечер пятницы. Старт 24 часового таймера для решения финальной задачи!
Когда-нибудь проектировал систему за 24 часа?

По текущему рейтингу мы знали, что немало команд выполнило разминочное задание. Получается, что есть команды, нацеленные на успех. Плюс, могут подтянуться "тёмные лошадки", - кто копил силу для финала.
Мы асинхронно накидали на общую доску базовые элементы. А их нужно не мало, т.к. задача оценивается по многим параметрам.
Утром встретились на 2 часа. Затем асинхронно доделывали. На разборе разминочной задачи мы поняли, что необходимо улучшиться в визуальном представление сделанной работы. Что получилось сделать на этот раз. Мы пыхтели до последнего. И в 17:57 выгрузили итоговую презентацию на платформу.

🎁 Важнее - участие. Или нет?
Я шёл на Хакатон ради участия, практики. Хотя, предполагались и денежные призы для 9ых финалистов☝️
Кажется, что это приятный бонус, если дошёл до призового места. Он не был моей целью. Какая же была неожиданность, когда ко мне на следующий день(в воскресенье) постучался представитель Хакатона и позвал на 5 минутный питч для финалистов 😎

5️⃣ Успеть за 5 минут
Думаю, что за этот тайминг получилось рассказать максимум про все основные компоненты, сценарии использования созданной системы. А после ответить на интересующие вопросы.
Самым последним из них был: "Назовите сильные и слабые стороны Вашего решения?". Интуитивно понял, что нужно начинать со слабой(один из кейсов мы как-раз обсудили - что сделаем сейчас для быстрого старта и что потом можем улучшить), а закончить описанием сильных сторон.

🎇 Итог
Конкуренция была мощной. Мы заняли 15 место среди 90 команд. До 9ых призёров нам не хватило какого-то балла :) Торжественное награждение состоялось в этот же день после презентации решений финалистов. Какую грандиозную работу по оценки решений в короткий срок проделали коллеги-организаторы!

💡 Позднее на "After Party" мы поздравляли призёров, смотрели решения друг друга. И это круто - чувствовать открытость людей IT сообщества идти навстречу друг другу, показывать свои решения, обогащаться знаниями! 😊

🔜 В будущем опубликую интервью с членами-команды System_Design_World об их профессиональном опыте, мотивации, впечатлениях от прошедшего мероприятия.

❓ А Вы участвовали в Хакатонах? Какую пользу от них видите для себя?

✅ Как пройти System Design Интервью?

1️⃣ Этапы интервью
По моему опыту прохождения и опыту изучения материалов для подготовки к успешному прохождению этой секции интервью могу выделить 4 основных этапа, которые кандидату необходимо пройти в ходе проектирования заданной системы:

1) Уточнение функциональных и нефункциональных требований
Звёздный час кандидата. Точнее 5-10 минут. За которые нужно собрать фт, нфт, которые есть в голове интервьюера на данную сессию интервью. Понять, прояснить, закомититься по функционалу, который нужно будет реализовать. Также рассчитать нагрузки.

2) API
Построение легкой версии интерфейса взаимодействия с пользователем. Возможны и вариации этого этапа. О них ниже.
Здесь можно определить happy path, data flow.

3) Построение базовой архитектурной схемы
Большими мазками построить основные сервисы, БД, взаимодействия. Должно быть дубово. И работать. В принципе.
Далее можно углубиться в части системы чтобы показать, доказать интервьюеру, что таким образом система реализует обговоренный и согласованный ранее функционал.

4) Уточнение технологий
Sql, NoSql? OLAP, OLTP? statefull, stateless? Python, Go? Rest, grpc? ... Возможный расчёт мощности сервера БД.

2️⃣ Какие могут быть вариации? И причём тут умение коммуницировать?
Нужно быть готовым к отклонению от такой схемы прохождения интервью.

🧐 Пример картинки на ближайшие 45 минут в голове у интервьюера:
"Ожидаю, что кандидат уточнит требования, рассчитает базовые характеристики системы, построит схему данных, базовую схему. Хочу в дополнение намекнуть ему реализовать систему мониторинга".

🤷 Можно проявить чудеса телекинеза и считать, что угадал план этого интервью.

🗣 А можно спрашивать. Явно. Это твой выход. Ты на сцене и прожекторы смотрят на тебя. Прежде чем выступить, нужно понять что от тебя хотят. И уточнять по мере продвижения.
"Нужно ли сейчас реализовывать полноценное api? Или сконцентрироваться на схеме данных?"

3️⃣ Нужные качества кандидата
1. Умение слушать
Помогает понимать подсказки и пожелания интервьюера. Возможно, менять направление дизайна.
2. Проактивность
Именно ты ведёшь интервью. Всегда есть баланс между:
Спросил много -> посчитали, что джун ⚖️ спросил мало -> говорит заученное
Практика помогает найти разумный баланс.

⭐️ Представленная схема с 4мя этапами, вариациями и подсвеченные важные навыки помогут тебе заложить фреймворк для прохождения любого System Design интервью.
Удачи в прохождение!

А какие интервью были недавно у тебя и как они прошли?

https://www.youtube.com/watch?v=KhfeYD0VBOY

#SystemDesignInterview #SystemDesign

Эволюция HTTP: HTTP/2 и HTTP/3

Предыдущие части:
- HTTP/0.9 и HTTP/1.0
- HTTP/1.1

HTTP/2.0

В 2009 году компания Google начала разрабатывать свой протокол SPDY, который частично решал проблемы версии HTTP/1.1. Позднее нововведения данного протокола были приняты при разработке стандарта HTTP/2.0, опубликованного в 2015 году в RFC 7540.

Основные изменения в HTTP/2.0:

1️⃣ Мультиплексирование: одно соединение может использоваться для отправки и получения нескольких независимых сообщений и файлов одновременно.

2️⃣ Бинарный формат: данные передаются в бинарном формате, а не в текстовом виде, как в предыдущих версиях.

3️⃣ Сжатие заголовков: заголовки передаются в сжатом виде с помощью алгоритма HPACK (RFC 7541). Это позволяет увеличить производительность и скорость передачи данных.

4️⃣ Серверные push-уведомления: сервер может отправлять ресурсы клиенту до того, как он их запросит, что улучшает производительность.

HTTP/2.0 значительно увеличил производительность и скорость загрузки веб-страниц, сформировав современный интернет. В настоящее время версия HTTP/2.0 используется на около 70% веб-сайтов в интернете.

Однако, несмотря на значительные улучшения, HTTP/2.0 столкнулся с проблемами, обусловленными ограничениями транспортного протокола TCP.

Недостатки HTTP/2.0:

1️⃣ Head-of-line блокировка: несмотря на мультиплексирование, с точки зрения транспортного протокола TCP передача файлов выглядит как единый поток байтов. Поэтому, если хотя бы один пакет из файла будет потерян, передача остальных файлов будет остановлена, пока потерянный пакет не будет получен.

2️⃣ Шифрование: в HTTP/2 шифрование не является обязательным. И хотя основные браузеры запретили использовать HTTP/2.0 без шифрования (если сервер не поддерживает TLS, то браузер автоматически переходит на версию HTTP/1.1), в самом стандарте нет жестких требований.

3️⃣ Недостатки транспортного уровня: протокол TCP является безопасным протоколом. Для установления соединения он использует трехэтапное рукопожатие, прежде чем клиент с сервером сможет обмениваться данными. Для установления соединения между клиентом и сервером необходимо затратить время для 3 круговых запросов (3-RTT) для TLS 1.2 и 2-RTT для TLS 1.3.

ℹ️ Именно поэтому началась работа над новой версией HTTP/3.0.

HTTP/3

В 2022 году был опубликован RFC 9114, описывающий HTTP/3.

Вместо TCP, протокол HTTP/3 работает поверх протокола QUIC, который использует UDP. HTTP/3 реализует все возможности предыдущей версии, но благодаря новому транспортному уровню имеет ряд нововведений:

1️⃣ Новый транспортный уровень: в основе QUIC лежит протокол UDP, который не требует создания соединения. Также QUIC позволяет создавать мультиплексированные каналы с помощью стримов, которые не имеют блокировки Head-of-line.

2️⃣ Расширенная безопасность: в QUIC интегрирован протокол безопасности TLS 1.3. Большая часть пакета QUIC зашифрована.

3️⃣ Быстрое установление соединения: в QUIC рукопожатие транспортного уровня и уровня безопасности объединены. Поэтому для установления соединения необходимо 1-RTT (а для некоторых случаев и 0-RTT).

4️⃣ Гибкость в передаче данных: протокол QUIC гарантирует надежную доставку сообщений: гарантия доставки и порядка сообщений. Но также поддерживает работу стримов в режиме DATAGRAMS — негарантированная доставка без подтверждения потоков (например, для создания видео-стриминга).

5️⃣ Миграция соединений: благодаря использованию connection ID, QUIC поддерживает миграцию соединений: в случае изменения сети передачи данных, например, с GPRS на Wi-Fi, нет необходимости заново устанавливать соединение.

В настоящий момент более 25% сайтов и почти все браузеры по умолчанию поддерживают HTTP/3. Последняя версия HTTP/3 не является финальной, поэтому данный стандарт будет развиваться и дорабатываться.

Подробнее об HTTP/3 вы можете узнать из доклада: Нина Пакшина, "Чего ожидать от HTTP/3 + Go". Подписывайтесь на канал.

На этом серия постов об эволюции HTTP заканчивается.

Планируете ли вы использовать HTTP/3 в своем проекте?