This media is not supported in your browser
VIEW IN TELEGRAM
📬 Представляю твоему вниманию анонс ближайших публикаций на канале.
Активности из прошлого практически выполнены. Осталась летняя онлайн встреча.
▶️ Что же тебя ждёт?
1️⃣ Как пройти System Design Интервью?
Записал и смонтировал видео, в котором на живом примере прохождения собеседования поделюсь пониманием:
1) Какие основные 4 этапа нужно пройти кандидату;
2) Какими 2мя качествами нужно обладать кандидату
для успешного прохождения интервью.
2️⃣ Мультитенантность для Реляционных СУБД + ELK
Наш новый автор Лариса Соловьева расскажет реальный рабочий кейс как получилось разграничить доступ к кластеру БД. А затем и к ELK стеку, в который сливались данные. И всё в идеологии zero-code подхода.
3️⃣ Эволюция http - http2/3
Нина Пакшина завершит свой цикл про эволюцию http описывая последние стандарты этого популярного протокола. #HTTP
4️⃣ Построение HFT Биржи
На хабре увидел под статьей интересное обсуждение высоких нагрузок от одного комментатора. Познакомившись узнал, что он успел поработать много лет в пожалуй самой секретной сфере программирования - High Frequency Trading(HFT) - высокочастотная торговля. Месте, где за наносекунды происходят многомиллиардные обороты. На правах анонимности взял у автора интервью. В нём вкратце обсудим переломный 2008 год для мировых трейдеров. Как появилась высокочастотная торговля. И приоткроем завесу тайны как он создавал ядро HFT биржи.
Да-да. Один.
⭐️ Если есть желание поделится историей, рабочим архитектурным кейсом или написать что-то своё в тему дизайна систем - будем очень рады пополнению авторского коллектива)
❓ Как считаешь, какие ещё интересные разделы архитектуры, проектирования можно освятить в будущих постах?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍2❤1
✅ Как пройти 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
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
👍12🔥12❤1🥰1
Эволюция 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 в своем проекте?
Предыдущие части:
- 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 в своем проекте?
👍20🔥9
⭐️ Управление рисками by ITKatya.
👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).
💵 Недавно в её блоге был анонсирован Master Mind по управлению рисками в IT проектах. Тема меня заинтересовала так как в последнее время выступаю на архитектурных хакатонах. Понял, что прокачка в этой составляющей может дать дополнительные баллы)
📕 Встреча началась с небольшого куска теории. Где рассказывалось про негативные и позитивные(!) риски. Приведена собственная типизация:
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).
🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.
🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄
❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)
⏳ Говорили про бизнес, сроки. Что заранее невозможно всё просчитать. И с этим надо смириться 😌
🙋♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.
🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.
🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.
▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)
👋 С Екатериной познакомился недавно. На её крутом докладе про бережливую архитектуру на майской Podlodka TechLead Crew(где победил как участник).
1) операционные
2) технические
3) функциональные
4) ...
с разбиением на подпункты. Что риск можно митигировать или нивелировать(это другое!).
🏷 Далее стали разбирать конкретный кейс построения системы лояльности выявляя те самые изученные риски.
🌇 При рассмотрение архитектуры оказалось, что можно легко потонуть имея разные сущности лояльности в разных кластерах большой компании. Что логика агрегирующего слоя может случайно протечь вниз. Слой, который, казалось бы, должен только читать. 🙄
❓Обсудили интересный кейс с баллами: "Что лучше - за покупку в 2000 рублей давать 20 рублей или 2000 баллов"?
Как считаешь? Я ответил правильно :)
🙋♀️ Мнения участников встречи наполняли общий контекст. Вопросы находили ответы, благодаря чему получалось больше вовлекаться и держать текущую нить размышлений, дополнять её.
🔥 В конце много говорили про риск выгорания. Даже выбились из тайминга 😅
Приводили конкретные кейсы с работ. К примеру, спроектировал и вывел в мир продукт. Делал командой его 1.5 года. Устал. А у продукта жизнь только началась. И вся операционная деятельность по старту, обслуживанию ложится на твои плечи лида/архитектора/главного-не-к-кому-больше-идти. Которые уже опущены после битв с менеджерами за дедлайны, функционал, поддержку команды и вывода продукта в жизнь. Ещё пару месяцев разгрёб и всё...
И ты виноват. Что не идёшь дальше. Но нет. Оказывается, так часто бывает. Белка не может бегать в колесе вечно. А ещё может не хотеть. И это нормально.
🤗 Завершили пониманием и принятием себя, других, положительной обратной связью для развития в компании культуры взаимовыручки. Можно начинать со "спасибо", "пожалуйста", "благодарю". Твоё отношение начнёт постепенно распространяться и менять мир вокруг.
▶️ А реализовывался ли у тебя риск выгорания? Если нет, как его митигировал? :)
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡7
👩🏻🦰 Из декрета в финалисты хакатона.
🚶♂️ Открываем новую страницу в развитие нашего канала - жизненные истории в IT.
☝️ Какие-то из них будут за именем человека, другие выкладываться анонимно. Если есть что-то интересное, захватывающее или неожиданное - пиши!
⚙️ С аналитиком Элеонорой мы познакомились на платформе проведения хакатона. Она вступила в ряды команды System_Design_World. За счёт упорства и энтузиазма закрыла большой спектр задач в процессе всего мероприятия и при подготовке финального решения. Отрисовала одну из самых крутых схем данных среди всех решений. Лаконично представила наш итоговый архитектурный дизайн. При том, что аналитиком она стала совсем недавно...
—
Элеонора, привет! Представься, пожалуйста :)
👩🏻🦰 Я специалист по государственным закупкам, который, на период мамского отпуска, ищет себя в новой профессии.
Недавно проходил Архитектурный Хакатон от ВТБ. Здорово поработали в одной команде и заняли достойное место!
Ты создала очень крутую детальную архитектуру данных. Я думаю на уровне призёров хакатона. Откуда такие знания и навыки по проектированию схем данных, досконального изучения доменов?
👩🏻🦰 Я только закончила курсы системных аналитиков, даже более того, начало Хакатона пришлось на дедлайны защиты диплома. Схемы данных разминочной задачи проектировала одновременно с проектированием дипломного проекта. Знания и навыки в основном учебные. Схема данных, спроектированная на Хакатоне для меня на текущий момент самая большая.
Подскажи, пожалуйста, откуда ты узнала о Хакатоне и почему решила участвовать?
👩🏻🦰 О Хакатоне я узнала абсолютно случайно, увидев баннер над статьей ВТБ на Хабре. До этого только слышала о подобных мероприятиях. И так как я сейчас в поисках опыта, большого и малого, решила участвовать. Спасибо, Владимир, что позвал в команду.
👍 Как ты оцениваешь проведение Хакатона - его подачу, атмосферу, задачи, оценки?
👩🏻🦰 Мне не с чем сравнивать, но мне понравилось: и позитивные включения организаторов, и своевременные напоминания куратора, и холивары в чате, и интенсивная работа команды, особенно в последние минуты перед сдачей проекта. Из того, что лично мне не хватило, это развернутого фидбека по проекту.
Что ты получила для себя от Хакатона и участвовала бы в подобном будущем?
👩🏻🦰 Я получила опыт работы в команде, познакомилась, пусть и шапочно, с новыми инструментами, а с некоторые пришлось оперативно освоить. И я безусловно, с большим удовольствием, приму участие в подобном в будущем.
Спасибо, Элеонора, за твоё участие, вклад и интервью!
—
Если понравилась IT история и хочешь больше, ставь лайк 👍
Если есть своя - пиши в личку, оформим 👌
🧐 А как ты учился новой профессии? Всё ли проходило гладко и давалось легко? :)
☝️ Какие-то из них будут за именем человека, другие выкладываться анонимно. Если есть что-то интересное, захватывающее или неожиданное - пиши!
⚙️ С аналитиком Элеонорой мы познакомились на платформе проведения хакатона. Она вступила в ряды команды System_Design_World. За счёт упорства и энтузиазма закрыла большой спектр задач в процессе всего мероприятия и при подготовке финального решения. Отрисовала одну из самых крутых схем данных среди всех решений. Лаконично представила наш итоговый архитектурный дизайн. При том, что аналитиком она стала совсем недавно...
—
Элеонора, привет! Представься, пожалуйста :)
👩🏻🦰 Я специалист по государственным закупкам, который, на период мамского отпуска, ищет себя в новой профессии.
Недавно проходил Архитектурный Хакатон от ВТБ. Здорово поработали в одной команде и заняли достойное место!
Ты создала очень крутую детальную архитектуру данных. Я думаю на уровне призёров хакатона. Откуда такие знания и навыки по проектированию схем данных, досконального изучения доменов?
👩🏻🦰 Я только закончила курсы системных аналитиков, даже более того, начало Хакатона пришлось на дедлайны защиты диплома. Схемы данных разминочной задачи проектировала одновременно с проектированием дипломного проекта. Знания и навыки в основном учебные. Схема данных, спроектированная на Хакатоне для меня на текущий момент самая большая.
Подскажи, пожалуйста, откуда ты узнала о Хакатоне и почему решила участвовать?
👩🏻🦰 О Хакатоне я узнала абсолютно случайно, увидев баннер над статьей ВТБ на Хабре. До этого только слышала о подобных мероприятиях. И так как я сейчас в поисках опыта, большого и малого, решила участвовать. Спасибо, Владимир, что позвал в команду.
👍 Как ты оцениваешь проведение Хакатона - его подачу, атмосферу, задачи, оценки?
👩🏻🦰 Мне не с чем сравнивать, но мне понравилось: и позитивные включения организаторов, и своевременные напоминания куратора, и холивары в чате, и интенсивная работа команды, особенно в последние минуты перед сдачей проекта. Из того, что лично мне не хватило, это развернутого фидбека по проекту.
Что ты получила для себя от Хакатона и участвовала бы в подобном будущем?
👩🏻🦰 Я получила опыт работы в команде, познакомилась, пусть и шапочно, с новыми инструментами, а с некоторые пришлось оперативно освоить. И я безусловно, с большим удовольствием, приму участие в подобном в будущем.
Спасибо, Элеонора, за твоё участие, вклад и интервью!
—
Если понравилась IT история и хочешь больше, ставь лайк 👍
Если есть своя - пиши в личку, оформим 👌
🧐 А как ты учился новой профессии? Всё ли проходило гладко и давалось легко? :)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍3
⚡️ Блажен, кто посетил сей мир в его минуты роковые!
😇 Дорогие коллеги, подписчики, друзья!
Со многими из вас я знаком лично.
📈 Канал System Design World рос неустанно на протяжение 1 года с момента своего основания и достиг 1242 подписчиков!
Без единой внешней оплаченной рекламы!
🎓 Канал стал местом сбора крутых специалистов. Неожиданно для меня в момент знакомства на крутейшей конференции по высоким нагрузкам Saint HighLoad++ случалось, что специалисты уже подписаны на канал. К каналу подключались также спикеры.
➕ Стартовала авторская колонка крутых специалистов по темам, находящимся в контексте архитектуры. Из недавнего - была проведена своя архитектурная ката, офлайн встреча. Ещё ранее - интервью про создание System Design Интервью, сами мок интервью, #cheat_sheets, освящение хакатона и другое...
▶️ Скоро должна была состояться онлайн встреча... Новая ката или же мини-хакатон, на судейство в котором уже согласились специалисты, архитекторы, с которыми познакомился на профильных встречах. Да и хотелось делится новыми постами с уникальным контентом, устраивать встречи...
🤔 Я думал, что после фактической потери развиваемого youtube канала можно двигаться дальше. Ведь есть основное ядро заинтересованных в теме архитектуры и System Design членов нашего сообщества в рамках мессенджера Телеграм.
😕 Но случилось, что случилось...
Выше был пост по рискам. Неожиданно реализовался один из них для ведения канала. Риск, который может повлечь за собой большую неопределенность в дальнейшем функционирование самого мессенджера.
Думаю, что сейчас тяжело всем авторам сообществ, которые так много вложили своих сил в их развитие.
Но, конечно же, в самой тяжелой ситуации оказался основатель - Павел Дуров.
☝️ Я знаю, что не легко менять комфортную среду.
Чтобы двигаться дальше я создаю резервы, на которые постепенно будет происходить миграция:
rutube - vladimir_v_it - для видео контента
vk - System_Design_World - наше сообщество
boosty - vladimir_v_it - для желающих донатить на канал в это время на сломе эпох.
Подписывайтесь, чтобы оставаться на связи!
И берегите себя и своих близких.
😇 Дорогие коллеги, подписчики, друзья!
Со многими из вас я знаком лично.
Без единой внешней оплаченной рекламы!
🎓 Канал стал местом сбора крутых специалистов. Неожиданно для меня в момент знакомства на крутейшей конференции по высоким нагрузкам Saint HighLoad++ случалось, что специалисты уже подписаны на канал. К каналу подключались также спикеры.
▶️ Скоро должна была состояться онлайн встреча... Новая ката или же мини-хакатон, на судейство в котором уже согласились специалисты, архитекторы, с которыми познакомился на профильных встречах. Да и хотелось делится новыми постами с уникальным контентом, устраивать встречи...
🤔 Я думал, что после фактической потери развиваемого youtube канала можно двигаться дальше. Ведь есть основное ядро заинтересованных в теме архитектуры и System Design членов нашего сообщества в рамках мессенджера Телеграм.
😕 Но случилось, что случилось...
Выше был пост по рискам. Неожиданно реализовался один из них для ведения канала. Риск, который может повлечь за собой большую неопределенность в дальнейшем функционирование самого мессенджера.
Думаю, что сейчас тяжело всем авторам сообществ, которые так много вложили своих сил в их развитие.
Но, конечно же, в самой тяжелой ситуации оказался основатель - Павел Дуров.
☝️ Я знаю, что не легко менять комфортную среду.
Чтобы двигаться дальше я создаю резервы, на которые постепенно будет происходить миграция:
rutube - vladimir_v_it - для видео контента
vk - System_Design_World - наше сообщество
boosty - vladimir_v_it - для желающих донатить на канал в это время на сломе эпох.
Подписывайтесь, чтобы оставаться на связи!
И берегите себя и своих близких.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
System Design World
💪 Высокие нагрузки - это про нас!
📆 Закончилась 2ух дневная конференция по высоконагруженным отказоустойчивым распределенным системам Saint HighLoad++. На которой мне посчастливилось побывать 😊
🔆 На канале мы проводим System Design Interview по таким системам.…
📆 Закончилась 2ух дневная конференция по высоконагруженным отказоустойчивым распределенным системам Saint HighLoad++. На которой мне посчастливилось побывать 😊
🔆 На канале мы проводим System Design Interview по таким системам.…
🔥12👎6❤5
Разговор под NDA. Тихо про HFT
😎 Нет, он не хакер.
👨💻 Просто делал крутейшие разработки в сверх секретной сфере High Frequency Trading(HFT).
В которой твои подходы и алгоритмы приносят миллиарды валюты в наносекунды.
Об этом никто не говорит. Не говорил. До сегодняшнего дня.
🎤 Предлагаю твоему вниманию интервью с не названным специалистом в финансовой сфере.
Осветили:
1) Подходы к заработку на бирже до финансового кризиса 2008 года
2) Появление HFT +- во время кризиса.
3) Хаки к крупным криптобиржам
4) Создание собственной биржи
😊 Приятного чтения!
vk - NDA talks
🤫 Есть что шепнуть в нашy новую рубрику NDA talks? Пиши. Гарантирую твою анонимность.
😎 Нет, он не хакер.
👨💻 Просто делал крутейшие разработки в сверх секретной сфере High Frequency Trading(HFT).
В которой твои подходы и алгоритмы приносят миллиарды валюты в наносекунды.
Об этом никто не говорит. Не говорил. До сегодняшнего дня.
🎤 Предлагаю твоему вниманию интервью с не названным специалистом в финансовой сфере.
Осветили:
1) Подходы к заработку на бирже до финансового кризиса 2008 года
2) Появление HFT +- во время кризиса.
3) Хаки к крупным криптобиржам
4) Создание собственной биржи
😊 Приятного чтения!
vk - NDA talks
🤫 Есть что шепнуть в нашy новую рубрику NDA talks? Пиши. Гарантирую твою анонимность.
👍8🤔7👎2❤1
⚙️ От Postgres к Data Lake
Интересная статья с верхнеуровневым описанием эволюции внутренностей сервиса.
Notion - крутой органайзер с разнообразным функционалом.
Текстовые заметки, картинки, страницы, ... - представлены в виде "блока" в Postgres.
📶 До 2021 - все блоки хранились в 1 инстансе Postgres.
В 2021 стало 20 млн блоков.
Сейчас их 200 млрд. Как они хранятся?
🔡 Данные разбиты на 480 логических шардов, распределенных на 96 инстанцев Postgres.
БД обслуживала разнообразные запросы:
1) пользовательский траффик онлайн
2) оффлайн аналитику
3) машинное обучение
Было решено вынести от Postgres нагрузку 2), 3).
🔀 Воспользовались ETL:
Postgres -> connector -> Debezium -> Kafka -> S3 <- ...аналитика
⏺️ Проффит:
1) Сэкономленный бюджет
2) Быстрая обработка
3) Новые возможности. Решение помогло быстрее внедрять AI функционал.
Подробности в статье:
https://blog.det.life/how-does-notion-handle-200-billion-data-entities-919b238c2846
Мой перевод на хабре:
https://habr.com/ru/articles/845446/
▶️ А у Вас есть проект с ETL? Какие видите в нём преимущества?
Интересная статья с верхнеуровневым описанием эволюции внутренностей сервиса.
Notion - крутой органайзер с разнообразным функционалом.
Текстовые заметки, картинки, страницы, ... - представлены в виде "блока" в Postgres.
📶 До 2021 - все блоки хранились в 1 инстансе Postgres.
В 2021 стало 20 млн блоков.
Сейчас их 200 млрд. Как они хранятся?
🔡 Данные разбиты на 480 логических шардов, распределенных на 96 инстанцев Postgres.
БД обслуживала разнообразные запросы:
1) пользовательский траффик онлайн
2) оффлайн аналитику
3) машинное обучение
Было решено вынести от Postgres нагрузку 2), 3).
🔀 Воспользовались ETL:
Postgres -> connector -> Debezium -> Kafka -> S3 <- ...аналитика
⏺️ Проффит:
1) Сэкономленный бюджет
2) Быстрая обработка
3) Новые возможности. Решение помогло быстрее внедрять AI функционал.
Подробности в статье:
https://blog.det.life/how-does-notion-handle-200-billion-data-entities-919b238c2846
Мой перевод на хабре:
https://habr.com/ru/articles/845446/
▶️ А у Вас есть проект с ETL? Какие видите в нём преимущества?
Medium
How does Notion handle 200 billion data entities?
From PostgreSQL → Data Lake
❤9👍5
🗣 Поговорим про System Design! Когда?
Anonymous Poll
45%
Через пару недель в четверг в 20:00 Мск
55%
Через пару недель в субботу в 20:00 Мск
This media is not supported in your browser
VIEW IN TELEGRAM
👍15🤔2
🪚❌💚System Design Interview. Казнить нельзя помиловать!
🆒 Все привыкли к классному формату HighLoad++:
1) Крутые доклады
2) Мастер-классы
3) Доброжелательное сообщество
4) Интересные компании, квесты, мерч
5) Кулуарное общение о том, как оно работает на самом деле :)
А что если прокачать эту мощнейшую конференцию ещё?!
Есть идеи как? 💡
Не так давно я познакомился с топовыми спикерами IT сообщества:
Александр Поломодов - СТО Т-банка - пост, видео, книжный клуб
Филипп Дельгядо - архитектор lekton - видео, выступления
📗 Кто интересуется темой IT не раз сталкивался с их докладами в теме управления, технологий.
У каждого своё мнение на обязательность System Design Интервью при устройстве на работу. Которое они готовы отстаивать топя аргументами противоположную сторону.
❓ А что если... Мы их посадим друг напротив друга? Зададим эту тему. И посмотрим, что будет🍿
✈️ Окрыленный описанной идеей предложил им такой батл. Оба с энтузиазмом ответили "Да!".
▶️ В итоге необычная идея, заявка прошла входной конкурс на зимний HighLoad++ 2024 😊
Я буду модерировать дискуссию, вовлекать участников, подкидывать в топку новые тезисы 😏
Кто будет офлайн - отмечайте её в форме "собираюсь пойти", чтобы организаторы угадали с размером зала.
Для онлайна - увидимся на экранах :)
📝 Обсудим эту тему на нашей скорой встречи.
А пока... Как считаешь - казнить или помиловать? И почему? :)
https://highload.ru/moscow/2024/abstracts/12699
🆒 Все привыкли к классному формату HighLoad++:
1) Крутые доклады
2) Мастер-классы
3) Доброжелательное сообщество
4) Интересные компании, квесты, мерч
5) Кулуарное общение о том, как оно работает на самом деле :)
А что если прокачать эту мощнейшую конференцию ещё?!
Есть идеи как? 💡
Не так давно я познакомился с топовыми спикерами IT сообщества:
Александр Поломодов - СТО Т-банка - пост, видео, книжный клуб
Филипп Дельгядо - архитектор lekton - видео, выступления
📗 Кто интересуется темой IT не раз сталкивался с их докладами в теме управления, технологий.
У каждого своё мнение на обязательность System Design Интервью при устройстве на работу. Которое они готовы отстаивать топя аргументами противоположную сторону.
❓ А что если... Мы их посадим друг напротив друга? Зададим эту тему. И посмотрим, что будет
▶️ В итоге необычная идея, заявка прошла входной конкурс на зимний HighLoad++ 2024 😊
Я буду модерировать дискуссию, вовлекать участников, подкидывать в топку новые тезисы 😏
Кто будет офлайн - отмечайте её в форме "собираюсь пойти", чтобы организаторы угадали с размером зала.
Для онлайна - увидимся на экранах :)
📝 Обсудим эту тему на нашей скорой встречи.
А пока... Как считаешь - казнить или помиловать? И почему? :)
https://highload.ru/moscow/2024/abstracts/12699
Please open Telegram to view this post
VIEW IN TELEGRAM
highload.ru
Владимир Невзоров на HighLoad++ 2024
System Design Interview вездесущ. Раньше старшим специалистам достаточно было показать свои навыки в доменной области, чтобы успешно устроиться на свою новую работу мечты. Сейчас же необходимо придумать и построить целую систему всего за 45 минут! Насколько…
🔥25👍4👏1
🌟 Спонтанное интервью-стрим!
🕡 18:00 Teamlead Avito.
Ссылка ближе к этому времени в комментариях.
Сам в шоке 😀
#Stream #Interview
🕡 18:00 Teamlead Avito.
Ссылка ближе к этому времени в комментариях.
Сам в шоке 😀
#Stream #Interview
🔥24
This media is not supported in your browser
VIEW IN TELEGRAM
ТЗ: разработать сервис для удобного добавления и тестирование страховых продуктов.
Прилагается отчётность, БД.
Команда дополнила решение фичами AI для тестирование гипотез в процессе добавления.
☝️ В ТЗ отдельным пунктом есть требование к масштабированию архитектуры.
Решил для финального питча показать его с элементами анимации для WOW эффекта 😊
Ведь в ограниченное время нужно продемонстрировать основной функционал и сделать это красиво)
🙂 Посмотрим, как в итоге зайдёт такое решение)
▶️ Как считаете, на питче нужно защищать решение спокойно, убедительно и сухо? Или с эмоциями, вау эффектами, явно демонстрируя исключительную крутость созданного сервиса?
P.S. Подробный отчёт выложу после подведения итогов👌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍2
👥 Мультитенантность + CDC
📗 Как втащить Change Data Capture в мультитенантный сервис в короткий срок без программистов?
Лариса - крутой архитектор нашей команды "Могём в 23:59" с архитектурной каты МТС, на которой мы заняли призовое 2ое место - специально для канала разобрала реальный рабочий кейс.
I. Что есть:
• Данные записываются и обновляются в PostgreSQL.
• Требование заказчика: "Хотим удобный поиск! Вот тебе аж 2 недели! И загруженная команда разработчиков!"
II. Какой архитектурный паттерн нам поможет?
Change Data Capture(CDC) - захват изменяющихся данных!
III. Что делаем:
• Настраиваем логическую репликацию в PostgreSQL.
• С помощью CDC перекладываем данные в OpenSearch.
• Для его реализации раскатываем и настраиваем pgSync.
• Описываем в json маппинг нужных данных из таблиц PostgreSQL в индекс OpenSearch.
• Катим на прод.
‣ Вуаля! Теперь удобно ищем данные в OpenSearch! Profit!
🎓 Подробности в статье:
https://buildin.ai/share/fe1c7a34-e179-4152-917a-d981ec352e62?code=7PU5ET
▶️ Внедрял новую технологию на свой проект за 2 недели?
📗 Как втащить Change Data Capture в мультитенантный сервис в короткий срок без программистов?
Лариса - крутой архитектор нашей команды "Могём в 23:59" с архитектурной каты МТС, на которой мы заняли призовое 2ое место - специально для канала разобрала реальный рабочий кейс.
I. Что есть:
• Данные записываются и обновляются в PostgreSQL.
• Требование заказчика: "Хотим удобный поиск! Вот тебе аж 2 недели! И загруженная команда разработчиков!"
II. Какой архитектурный паттерн нам поможет?
Change Data Capture(CDC) - захват изменяющихся данных!
III. Что делаем:
• Настраиваем логическую репликацию в PostgreSQL.
• С помощью CDC перекладываем данные в OpenSearch.
• Для его реализации раскатываем и настраиваем pgSync.
• Описываем в json маппинг нужных данных из таблиц PostgreSQL в индекс OpenSearch.
• Катим на прод.
‣ Вуаля! Теперь удобно ищем данные в OpenSearch! Profit!
🎓 Подробности в статье:
https://buildin.ai/share/fe1c7a34-e179-4152-917a-d981ec352e62?code=7PU5ET
▶️ Внедрял новую технологию на свой проект за 2 недели?
🔥13👍1
🥄 Оно тебя кормит! Легаси! А ещё бывают мифические новые проекты. Или они реальны?
За последние 5 лет:
За последние 5 лет:
Anonymous Poll
17%
Создавал 1 новый проект, остальное легаси.
33%
Создавал 2 и более новых проекта, остальное легаси.
15%
Только участвовал в новых проектах, без легаси.
14%
Работал лишь с легаси. Нечего паниковать. Это часть жизни.
2%
Работал лишь с легаси. Это мрак и ужас!
19%
Дают работу, работаю.
🔥3👎2
⚙️ Нужно больше надежности! Неделя надежности!
📆 Закончилась Podlodka TechLead Crew 7. Это онлайн конференция, посвященная техническим аспектам разработки систем.
На прошлой я победил как участник. В призах был свободный вход на любую из следующих встреч) Решил им воспользоваться)
Уровень "класс"! 👍
Сами доклады, общение Q/A, дискуссии в чате. На каких-то докладах присутствовал. Остальные посмотрю в записи.
Что посмотрел, запомнилось:
I. Александр Агейченко - «Надежный как кирпич»
Мир фронтенда чудесный и многообразный. И в возможностях. И в моментах, когда что-то может пойти не так(или всё).
• Улучшаем наблюдаемость.
Отслеживаем ошибки у клиентов:
• Crash-free.
По финтеху 99.6% нормально. Измеряют, к примеру, Firebase, Sentry. Больше крашей -> ухудшение рейтинга в поисковой выдаче.
Также советы по технологиям, ведению проекта.
• Обсуждение про бюджет ошибок, приоритеты.
Если не работает фича с низким бизнес приоритетом у малого количества пользователей - не факт, что её нужно чинить сейчас же.
Возможно, у тебя рядом ещё лёг модуль совершения банковской операции. Соберётся бизнес, тех лиды проекта. И выберут приоритет. Разработчики, зачастую, уже стоят где-то далеко в ожидание тикета.
• Как откатывать?
Задал вопрос по деплою. Оказывается, никак 🤷 Не принято в этом дивном новом мире. Если приоритет не работающей новой фичи большой, то делаем быстро хотфикс. Даже, возможно, в процессе текущей выкладки/обновления. Заставлять пользователя обновиться потом: "Не войдёшь, пока не обновишься!", - не лучшая практика. Оставляем на случаи обновления совсем старых неподдерживаемых версий.
Что ещё можно сделать? Использовать feature flags. Флагами включать, отключать функционал.
Александр дорос до этой менеджерской позиции из разработчика столкнувшись с типичными болями разработки на фронте. Поэтому смотрит на проблему уже как с технической, так и с бизнесовой стороны. Было интересно в конце уже не под запись заспамить вопросами. И что ценно - получить ответы.
Продолжение в следующем посте 👌
❓ А как ты улучшаешь надежность своего сервиса?
📆 Закончилась Podlodka TechLead Crew 7. Это онлайн конференция, посвященная техническим аспектам разработки систем.
На прошлой я победил как участник. В призах был свободный вход на любую из следующих встреч) Решил им воспользоваться)
Уровень "класс"! 👍
Сами доклады, общение Q/A, дискуссии в чате. На каких-то докладах присутствовал. Остальные посмотрю в записи.
Что посмотрел, запомнилось:
I. Александр Агейченко - «Надежный как кирпич»
Мир фронтенда чудесный и многообразный. И в возможностях. И в моментах, когда что-то может пойти не так(или всё).
• Улучшаем наблюдаемость.
Отслеживаем ошибки у клиентов:
Вы даже не представляете какие интересные тексты ошибок иногда показываются клиентам.Жизнь.
• Crash-free.
По финтеху 99.6% нормально. Измеряют, к примеру, Firebase, Sentry. Больше крашей -> ухудшение рейтинга в поисковой выдаче.
Также советы по технологиям, ведению проекта.
• Обсуждение про бюджет ошибок, приоритеты.
Если не работает фича с низким бизнес приоритетом у малого количества пользователей - не факт, что её нужно чинить сейчас же.
Возможно, у тебя рядом ещё лёг модуль совершения банковской операции. Соберётся бизнес, тех лиды проекта. И выберут приоритет. Разработчики, зачастую, уже стоят где-то далеко в ожидание тикета.
• Как откатывать?
Задал вопрос по деплою. Оказывается, никак 🤷 Не принято в этом дивном новом мире. Если приоритет не работающей новой фичи большой, то делаем быстро хотфикс. Даже, возможно, в процессе текущей выкладки/обновления. Заставлять пользователя обновиться потом: "Не войдёшь, пока не обновишься!", - не лучшая практика. Оставляем на случаи обновления совсем старых неподдерживаемых версий.
Что ещё можно сделать? Использовать feature flags. Флагами включать, отключать функционал.
Александр дорос до этой менеджерской позиции из разработчика столкнувшись с типичными болями разработки на фронте. Поэтому смотрит на проблему уже как с технической, так и с бизнесовой стороны. Было интересно в конце уже не под запись заспамить вопросами. И что ценно - получить ответы.
Продолжение в следующем посте 👌
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9
⚙️ Куда она закатилась? Надежность. Продолжаем осмыслять.
☝️ Ты думал, что знаешь всё про архитектуру? Давай осмыслим её ещё раз!
Хотел бы осветить следующий доклад, на котором получилось присутствовать онлайн и задавать вопросы после.
Филипп Дельгядо - «Где искать надежность при взаимодействии сервисов?»
Какие реальные взаимодействия стоят за нарисованными квадратами и стрелками? Почему то что принято считается надежным by default?
Филипп предлагает задуматься над стандартными архитектурными паттернами. Разбирает их надежность. Исходя из опыта описывает различные сценарии что может произойти и как сделать лучше.
• Надежность
💻 ❌ Вдобавок к проблемам самого приложения и транспорта нужно помнить о проблемах с железом.
• Железный пример
Вводная:
Есть сервер. Живёт 55000 часов. Есть резервный. Узнаём, что сервер умер за 1 секунду. За 2 секунды можем восстановиться.
=>
Вероятность потери всех сообщений за эти 2 секунды - 1 раз в миллиард лет.☝️
• Железный пример + Приложение
Приложение падает каждый день из-за утечек памяти. Узнаём за 30 секунд(http таймаут). Вероятность потерять все сообщения за 30 секунд - 1 раз в 6 лет.
• +100 сервисов по 20 экземпляров
Взаимодействие каждый с каждым. 20 млн взаимодействий. Проблемы 4 раза в сутки. 🙁
• Взаимодействия
🤍 ⁉️ Yже давно запросы от клиента напрямую не ходят в сам сервис. Кто-то стоит посередине - api gateway, loadbalancer, service mash.
Если прошёл таймаут на обработку сообщения(клиенту нужен результат быстро или не нужен вообще), то сообщение уже не нужно обрабатывать. Такой наплыв сообщений лишним грузом повисает на плечах сервиса.
Получается, что хоть экземпляр сервиса и доступен, и service mash роутит на него запрос, но обработка уже явно займёт больше таймаута.
=>
• Нужно как минимум реализовывать механизм heartbeat - периодическая проверка, что экземпляр живой.
• И ещё лучше докрутить логику - если этот экземпляр отвечает за 20 миллисекунд вместо 10 в прошлый раз, пошлю запрос в другой. Это будет лучше, чем ожидать долгого ответа пускай от даже, вроде бы, живого экземпляра.
• Паттерны
➕ Знакомая очередь посередине. Она должна развязать producer'а от consumer'а. Как бы не так!
➖ Зависимости стали косвенными! Не понятно - consumer переключился на новую версию или нет!
Упомянуты битвы в крупных компаниях про число партиций в топике, количеств топиков в целом.😣
=>
Приходит на помощь паттерн Transaction Inbox!
Вносим очередь в сам сервис, который и потребляет данные. Заход через его api.
Вывод:
К проектированию надежности стоит подходить со всей серьезностью. Продумывать архитектуру начиная с железа. Учитывать рост нагрузки, сбои. Переосмыслять знакомые паттерны. Смотреть, что лучше всего подойдёт для реализации именно твоих требований с тем техническим, финансовым, административным окружением, что у тебя есть сейчас.
Хочешь ещё разборов докладов? -> ⚡️
Насколько тебе легко работается с очередями?
☝️ Ты думал, что знаешь всё про архитектуру? Давай осмыслим её ещё раз!
Хотел бы осветить следующий доклад, на котором получилось присутствовать онлайн и задавать вопросы после.
Филипп Дельгядо - «Где искать надежность при взаимодействии сервисов?»
Какие реальные взаимодействия стоят за нарисованными квадратами и стрелками? Почему то что принято считается надежным by default?
Филипп предлагает задуматься над стандартными архитектурными паттернами. Разбирает их надежность. Исходя из опыта описывает различные сценарии что может произойти и как сделать лучше.
• Надежность
• Железный пример
Вводная:
Есть сервер. Живёт 55000 часов. Есть резервный. Узнаём, что сервер умер за 1 секунду. За 2 секунды можем восстановиться.
=>
Вероятность потери всех сообщений за эти 2 секунды - 1 раз в миллиард лет.☝️
• Железный пример + Приложение
Приложение падает каждый день из-за утечек памяти. Узнаём за 30 секунд(http таймаут). Вероятность потерять все сообщения за 30 секунд - 1 раз в 6 лет.
• +100 сервисов по 20 экземпляров
Взаимодействие каждый с каждым. 20 млн взаимодействий. Проблемы 4 раза в сутки. 🙁
• Взаимодействия
🤍 ⁉️ Yже давно запросы от клиента напрямую не ходят в сам сервис. Кто-то стоит посередине - api gateway, loadbalancer, service mash.
Если прошёл таймаут на обработку сообщения(клиенту нужен результат быстро или не нужен вообще), то сообщение уже не нужно обрабатывать. Такой наплыв сообщений лишним грузом повисает на плечах сервиса.
Получается, что хоть экземпляр сервиса и доступен, и service mash роутит на него запрос, но обработка уже явно займёт больше таймаута.
=>
• Нужно как минимум реализовывать механизм heartbeat - периодическая проверка, что экземпляр живой.
• И ещё лучше докрутить логику - если этот экземпляр отвечает за 20 миллисекунд вместо 10 в прошлый раз, пошлю запрос в другой. Это будет лучше, чем ожидать долгого ответа пускай от даже, вроде бы, живого экземпляра.
• Паттерны
Брокер должен знать про число партиций. Это легко не поменять.Очень ценная мысль! В http не надо знать каким образом устроен получатель.
Producer знает каким образом consumer хочет чтобы его данные партиционировались. Т.е. producer должен обладать информацией о внутренней реализации консьюмера, чтобы корректно сформировать события, отправляемые в топик.
Упомянуты битвы в крупных компаниях про число партиций в топике, количеств топиков в целом.😣
=>
Приходит на помощь паттерн Transaction Inbox!
Вносим очередь в сам сервис, который и потребляет данные. Заход через его api.
Вывод:
К проектированию надежности стоит подходить со всей серьезностью. Продумывать архитектуру начиная с железа. Учитывать рост нагрузки, сбои. Переосмыслять знакомые паттерны. Смотреть, что лучше всего подойдёт для реализации именно твоих требований с тем техническим, финансовым, административным окружением, что у тебя есть сейчас.
Хочешь ещё разборов докладов? -> ⚡️
Насколько тебе легко работается с очередями?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4⚡3
This media is not supported in your browser
VIEW IN TELEGRAM
⭐️ Новый сезон активностей! Сплошная прокачка в System Design!
1. От Redis к SQLite
⚡️ Изучим как и почему разработчики фаервола избавились от хайпового Редиса в пользу локальной быстрой БД.
2. System Design Interview
👨💻 Посмотрим как тимлид Авито создал leetcode за ограниченное время интервью. Это оформленная запись недавнего стрима. Как и обещал, была запись. Смонтировал, оформил. Думаю, такой хорошей подачи материала ты ещё не встречал)
3. Online про System Design
😊 Обещанная встреча. Заходим, знакомимся, общаемся про базу System Design в форме квиза в дружеской атмосфере. Далее смотрим на алгоритмы балансировки трафика. Далее узнаём как эффективно прокачаться в прохождение собеседований за 1 месяц(да-да, время пришло :) )
4. Архитектурная ката от Яндекс 360
Чудесный HighLoad++ дарит не только лишь доклады, общение и мерч. Ещё и возможности на хорошей волне продолжить знакомства в виде совместной активности.
Благодаря конференции познакомился с коллегами из Яндекс 360. Вместе катим кату в середине декабря - 12.12.24 20:00.
Хочешь участвовать? Вперёд!
👉 Заходи в System Design Chat. Отвечай боту про себя и желание участвовать.
Ставь лайк, если с нетерпением ждёшь озвученных активностей 😊
Какую первую из них хочешь увидеть на канале?
1. От Redis к SQLite
⚡️ Изучим как и почему разработчики фаервола избавились от хайпового Редиса в пользу локальной быстрой БД.
2. System Design Interview
👨💻 Посмотрим как тимлид Авито создал leetcode за ограниченное время интервью. Это оформленная запись недавнего стрима. Как и обещал, была запись. Смонтировал, оформил. Думаю, такой хорошей подачи материала ты ещё не встречал)
3. Online про System Design
😊 Обещанная встреча. Заходим, знакомимся, общаемся про базу System Design в форме квиза в дружеской атмосфере. Далее смотрим на алгоритмы балансировки трафика. Далее узнаём как эффективно прокачаться в прохождение собеседований за 1 месяц(да-да, время пришло :) )
4. Архитектурная ката от Яндекс 360
Чудесный HighLoad++ дарит не только лишь доклады, общение и мерч. Ещё и возможности на хорошей волне продолжить знакомства в виде совместной активности.
Благодаря конференции познакомился с коллегами из Яндекс 360. Вместе катим кату в середине декабря - 12.12.24 20:00.
Хочешь участвовать? Вперёд!
👉 Заходи в System Design Chat. Отвечай боту про себя и желание участвовать.
Ставь лайк, если с нетерпением ждёшь озвученных активностей 😊
Какую первую из них хочешь увидеть на канале?
👍20❤4🔥3👨💻1
Знаю автора очень хорошо. Можно сказать, он мой давний друг 😊
Сейчас активно готовится в
👀 Можно посмотреть как разработчик пропускает через себя алгоритмическую подготовку. С какими трудностями сталкивается. И как осознаёт происходящее и сами задачи.
https://www.tgoop.com/leetcode_bytes_you/3
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Укусанный литкодом
✅ Нацеленность на результат! 💪
На данный момент технические интервью пройдены:
1) Сбер
2) Касперский
3) 2GIS
Плюс компании средней руки типа rubackup, Бюро 1440 и другие.
Укусанный литкодом двигаюсь дальше.
На данный момент технические интервью пройдены:
1) Сбер
2) Касперский
3) 2GIS
Плюс компании средней руки типа rubackup, Бюро 1440 и другие.
Укусанный литкодом двигаюсь дальше.
🤷6❤2👍2
youtube
rutube
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
System Design LeetCode / TeamLead Avito
Тимлид Avito Евгений строит LeetCode.
Дополняем твой багаж знаний по проектированию систем. На этот раз узнаешь как последовательно спроектировать популярный сервис по прокачке алгоритмов LeetCode.
Телеграмм канал Евгения (python/развитие языка/конференции/жизнь…
Дополняем твой багаж знаний по проектированию систем. На этот раз узнаешь как последовательно спроектировать популярный сервис по прокачке алгоритмов LeetCode.
Телеграмм канал Евгения (python/развитие языка/конференции/жизнь…
🔥17👍7