⚙️ Куда она закатилась? Надежность. Продолжаем осмыслять.
☝️ Ты думал, что знаешь всё про архитектуру? Давай осмыслим её ещё раз!
Хотел бы осветить следующий доклад, на котором получилось присутствовать онлайн и задавать вопросы после.
Филипп Дельгядо - «Где искать надежность при взаимодействии сервисов?»
Какие реальные взаимодействия стоят за нарисованными квадратами и стрелками? Почему то что принято считается надежным 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://news.1rj.ru/str/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/развитие языка/конференции/жизнь…
🔥18👍7
🌪Архитектурный дзен
Стартовала ежегодная архитектурная конференция ArchDays.
Интересные доклады, общение. До мерча пока не дошёл😅
Отличие от HighLoad++ в большей абстракции. Больше разговоров на тему архитектуры, подходов, сути и специфики роли архитектора.
Позже напишу интересные тезисы с различных докладов.
А какая конференция нравится тебе больше всего? И почему?
Стартовала ежегодная архитектурная конференция ArchDays.
Интересные доклады, общение. До мерча пока не дошёл😅
Отличие от HighLoad++ в большей абстракции. Больше разговоров на тему архитектуры, подходов, сути и специфики роли архитектора.
Позже напишу интересные тезисы с различных докладов.
А какая конференция нравится тебе больше всего? И почему?
❤6
This media is not supported in your browser
VIEW IN TELEGRAM
🔥7👍3
❄️🔥 Горячая дискуссия в первые дни зимы!
Зима близко! Осталось всего две недели до старта дискуссии System Design Interview: Казнить нельзя помиловать.
Начнём с вводной по этому популярному этапу интервью. Далее разберём по полочкам основные тезисы. А ещё приготовили небольшой интерактив для участников!
Стартуем 2 декабря в 17:00 в зале Найроби+Касабланка.
Приходи онлайн, оффлайн. Будет горячо! :)
Зима близко! Осталось всего две недели до старта дискуссии System Design Interview: Казнить нельзя помиловать.
Начнём с вводной по этому популярному этапу интервью. Далее разберём по полочкам основные тезисы. А ещё приготовили небольшой интерактив для участников!
Стартуем 2 декабря в 17:00 в зале Найроби+Касабланка.
Приходи онлайн, оффлайн. Будет горячо! :)
🔥4
Forwarded from HighLoad++
System Design Interview вездесущ. Раньше старшим специалистам достаточно было показать свои навыки в доменной области, чтобы успешно устроиться на свою новую работу мечты. Сейчас же необходимо придумать и построить целую систему всего за 45 минут! Насколько такой навык нужен в реальной работе? Что проверяет такое собеседование?
На HighLoad++ 2024 в рамках дискуссии «System Design Interview: казнить нельзя помиловать» профессионалы взвесят все «за» и «против» — скучно не будет.
Посетить эту дискуссию стоит и менеджерам, планирующим или практикующим system design interview, и сотрудникам.
До скорой встречи, друзья 🙌
На HighLoad++ 2024 в рамках дискуссии «System Design Interview: казнить нельзя помиловать» профессионалы взвесят все «за» и «против» — скучно не будет.
Посетить эту дискуссию стоит и менеджерам, планирующим или практикующим system design interview, и сотрудникам.
До скорой встречи, друзья 🙌
👍13🔥1
VTB API hackathon 2024. Наш финал!
▶️ Дошли до финала! Сегодня питчу оффлайн.
3 трека:
1) Open API
2) gRPC
3) Единая платформа аутентификации API
Выбрали 3ий.
Финал открытый в отличие от летнего архитектурного хакатона от ВТБ. На котором тоже получилось дойти до финала.
✍️ Можете посмотреть созданные решения, намотать на ус интересные приёмы.
🎦 Наша защита в 16:45.
Подключайтесь!
https://apihack.vtb.ru/
Старт выступления: 5:55:15
▶️ Дошли до финала! Сегодня питчу оффлайн.
3 трека:
1) Open API
2) gRPC
3) Единая платформа аутентификации API
Выбрали 3ий.
Финал открытый в отличие от летнего архитектурного хакатона от ВТБ. На котором тоже получилось дойти до финала.
✍️ Можете посмотреть созданные решения, намотать на ус интересные приёмы.
🎦 Наша защита в 16:45.
Подключайтесь!
https://apihack.vtb.ru/
Старт выступления: 5:55:15
👍11🔥5❤2
🏵 VTB API hackathon 2024. Мы призёры!
💪 О самом хакатоне можно сказать одним словом - мощно!
Проведения хакатона, задачи, судейство, организация финала получили высокие оценки от участников!
Везде чувствовалась вовлеченность организаторов. И ответная активность команд.
Финальный питч офлайн - то ещё испытание 😅 И его получилось пройти!
🎥 Сделал ёмкое видео, чтобы передать атмосферу финала. enjoy :)
Полная версия - apihack.vtb.ru.
Мой питч - 5:55:15 (надо же)
▶️ Принимаешь участние в хакатонах? Если да, то почему? Если нет, то почему? :)
#Hackathon
💪 О самом хакатоне можно сказать одним словом - мощно!
Проведения хакатона, задачи, судейство, организация финала получили высокие оценки от участников!
Везде чувствовалась вовлеченность организаторов. И ответная активность команд.
Финальный питч офлайн - то ещё испытание 😅 И его получилось пройти!
🎥 Сделал ёмкое видео, чтобы передать атмосферу финала. enjoy :)
Полная версия - apihack.vtb.ru.
Мой питч - 5:55:15 (надо же)
▶️ Принимаешь участние в хакатонах? Если да, то почему? Если нет, то почему? :)
#Hackathon
🔥22👍11❤3👏2
🏃➡️ Это кто к нам пришёл? Ката! Погнали!
Собираемся в четверг вечером 12.12.2024 в 20:00!
😔 К сожалению, интеграция нашего канала в этом году не состоится. Будем смотреть на следующий.
📆 Поскольку, я уверен, многие из вас уже забили это время под активность архитектурной каты - мы её всё-равно проведём!
😏 Подготовил интересное задание) После его презентации отвечаю на ваши вопросы. И go по командам проектировать!
За 45 минут. Жёстко? Зато интересно)
Прокачивайте командное взаимодействие, применение архитектурных паттернов. И просто получайте удовольствие от совместного вечернего времяпрепровождения😀
😊 Жду всех в наше чате - System Design Chat.
Ссылку на встречу размещу там ближе к времени старта.
Предложения и пожелания можно писать в чат или сюда в комментариях.
#ArchitecturalKata
Собираемся в четверг вечером 12.12.2024 в 20:00!
😔 К сожалению, интеграция нашего канала в этом году не состоится. Будем смотреть на следующий.
📆 Поскольку, я уверен, многие из вас уже забили это время под активность архитектурной каты - мы её всё-равно проведём!
😏 Подготовил интересное задание) После его презентации отвечаю на ваши вопросы. И go по командам проектировать!
За 45 минут. Жёстко? Зато интересно)
Прокачивайте командное взаимодействие, применение архитектурных паттернов. И просто получайте удовольствие от совместного вечернего времяпрепровождения😀
😊 Жду всех в наше чате - System Design Chat.
Ссылку на встречу размещу там ближе к времени старта.
Предложения и пожелания можно писать в чат или сюда в комментариях.
#ArchitecturalKata
👍10
🚞 Забегай в последний вагон!
Ката сегодня в 20:00! Пришла идея дополнить описание задачи ещё парой требований для лучшей проработки создаваемой системы. Но тогда 45 минут явно не хватит :) Поделись мнением, какой формат хочется.
Ката сегодня в 20:00! Пришла идея дополнить описание задачи ещё парой требований для лучшей проработки создаваемой системы. Но тогда 45 минут явно не хватит :) Поделись мнением, какой формат хочется.
Anonymous Poll
37%
Ограниченный скоуп, 45 минут на проектирование. Давай возьмёмся и шустро сделаем!
63%
Можно накинуть побольше и проектировать 60 - 75 минут
Media is too big
VIEW IN TELEGRAM
🔥 Архитектурная Ката 2.0 на низком старте!
Открываю подробности самой каты. Заходи в System Design Чат для регистрации. Ещё можно успеть!
🕗 Желаю всем хорошего вечера.
Если не получилось сегодня быть с нами, обязательно ждём в следующий раз! 😊
#ArchitecturalKata
Открываю подробности самой каты. Заходи в System Design Чат для регистрации. Ещё можно успеть!
🕗 Желаю всем хорошего вечера.
Если не получилось сегодня быть с нами, обязательно ждём в следующий раз! 😊
#ArchitecturalKata
🔥8👍4
🕋🕋 Делаем бэкапы заранее! И не делаем лишних зависимостей у компонентов!
👉 На HighLoad++ зашёл на увлекательный доклад СДЕКа о восстановление IT инфраструктуры после атаки шифровальщиком.
🙄 Один из поинтов был в том, что все, конечно, знают, что не надо плодить лишних связей) Но, всё-равно, создают)
Из-за этого сложно восстановить базовый компонент, который стал связанным со второстепенным, от которого стал зависеть и без которого его нельзя поднять o_O
А если бэкапа для второстепенного нет, то и основной восстановить не получается 😭
✅ Ребята молодцы. В докладе с мемчиками и с долей самоиронии описали как по дням за 1 неделю они нашли самое нужное,не сгорели и восстановили базовый функционал. Сначала эта была выдача(насколько помню) уже текущих заказов. Затем вернули возможность заказы формировать. Затем восстановили какую-то нужную для аналитики, но не первозначимую активность. В докладе также есть советы как не допустить подобной ситуации, решительно и правильно действовать.
💸 Похоже, мы все пришли к вызовам современности - теперь нужны периодические бэкапы не только потому что "хотелось бы, если что...", а потому что "когда нас взломают, нужно как можно быстрее и качественней восстановиться". Растут требования и базовые затраты на IT инфраструктуру 🥹
🧐 Как считаешь, насколько часто нужно делать бэкапы, ограничивать доступ к базам и создавать тайные уголки с самими бэкапами лишь для маленькой группы супер доверенных админов?
👉 На HighLoad++ зашёл на увлекательный доклад СДЕКа о восстановление IT инфраструктуры после атаки шифровальщиком.
🙄 Один из поинтов был в том, что все, конечно, знают, что не надо плодить лишних связей) Но, всё-равно, создают)
Из-за этого сложно восстановить базовый компонент, который стал связанным со второстепенным, от которого стал зависеть и без которого его нельзя поднять o_O
А если бэкапа для второстепенного нет, то и основной восстановить не получается 😭
✅ Ребята молодцы. В докладе с мемчиками и с долей самоиронии описали как по дням за 1 неделю они нашли самое нужное,
💸 Похоже, мы все пришли к вызовам современности - теперь нужны периодические бэкапы не только потому что "хотелось бы, если что...", а потому что "когда нас взломают, нужно как можно быстрее и качественней восстановиться". Растут требования и базовые затраты на IT инфраструктуру 🥹
🧐 Как считаешь, насколько часто нужно делать бэкапы, ограничивать доступ к базам и создавать тайные уголки с самими бэкапами лишь для маленькой группы супер доверенных админов?
highload.ru
Наталья Макарова на HighLoad++ 2024
Большинство из вас в курсе, что мы в CDEK в конце мая заводили наш энтерпрайз с полного нуля. Пока воспоминания свежи, поделимся лайфхаками. Что уже должно быть у вас в коде (и в голове) до того, как все полетит в тартарары? Какие ваши апи самые важные? Какие…
👍7🔥1
Forwarded from Николай Ясинский | SHIFU (Nikolay Yasinskiy)
First Law of Distributed Object Design: Don't distribute your objects.
Первый закон дизайна распределенных объектов: Не распределяйте ваши объекты.
(с) Мартин Фаулер
Первый закон дизайна распределенных объектов: Не распределяйте ваши объекты.
(с) Мартин Фаулер
🔥6
🫶 С Наилучшими пожеланиями в Новый Год!
🏄♂️ Свершений, приятных открытий и душевного тепла!
🚀 2024 год промчался стремительно и насыщенно!
Делюсь основными активностями.
System Design
1) Провёл стрим на дружественном канале, посвященный шардированию. Судя по лайкам зрителям зашло 😊
2) Сделали серию мок интервью по System Design youtube, dropbox. Если собираешься собеседоваться - вот тебе готовые пособия 🥳
3) Встретились офлайн с подписчиками, отпраздновали рост канала. И в целом хорошо провели время :)
4) Создали несколько архитектурных кат. В организации первой здорово помогли Игорь и Евгения! На 2ой декабрьской сошлись 42 team, Za Gotbit, X team. Решения получились классные! Ребята молодцы! Отзывы о кате положительные! #ArchitecturalKata
5) Участвовал в хакатонах. Описал на канале часть. Несколько раз становился призёром в составе различных команд. Крутое последнее достижение - 2ое место на хакатоне от ВТБ. Хакатон - отличное место для проверки своих сил на реальной нужной компании задаче! #Hackathon
6) На ProIT Fest приехал с System Design задачей. Участники в дружеской атмосфере задавали интересные вопросы. Все вместе продуктивно провели встречу 👌
Спасибо Антону за решение!
7) Организовал дискуссию System Design Интервью: Казнить нельзя помиловать на HighLoad++ 2024 Moscow.
Теперь я понимаю сколько нужно подготовки и почему это не так просто 😏 Особенно, когда выступаешь не один. Когда нужно сводить всё в единую согласованную точку. У нас получилось! Для интересующихся такими собеседованиями как со стороны кандидата, так и со стороны компании скоро выложу ссылку. Мне как спикеру она доступна для шаринга.
8) Освятил чёткий фреймворк для прохождения System Design собеседований в БигТех компании.
🙋 Общение со студентами
Рассказывал студентам МГУ, МИРЭА современные реалии IT :)
👥 Новые авторы
На канале появились 2 новых автора:
Нина Пакшина рассказывала про эволюцию http #HTTP
Лариса Соловьева про реальный кейс с имплеменатцией Change Data Capture
🔅 Изюминка года
Ею стала беседа под NDA с одним из первопроходцев HFT. Потрясающая встреча! Я был в изумление от глубины понимания домена, технологий и навыков собеседника. Тот пример, когда 1 человек может реально многое.
💯 Самый популярный...
Приятной неожиданностью стал мой перевод статьи Как Notion обрабатывает 200 миллиардов объектов данных.
На хабре он вызвал положительную реакцию с 7.6 тыс просмотров, и короткий пост-ревью в телеграме с 14.2 тыс просмотров.
Был комментарий, что хотелось бы больше таких ревью. Взял на заметку ✍️
🥇 Эталон решения System Design задачи
Ближе к концу года мы встретились с Евгением - тимлидом Авито - для решения System Design задачи - проектирование LeetCode. Евгений последовательно расписал решение, ответил на множество моих вопросов и оставил после себя законченную схему. Для прокачки welcome :)
✅ Менторство как хобби
Стал преподавателем Отуса, активно делился знаниями как ментор.
Менти проходили успешно технические собеседования в BigTech -🔠 Kaspersky, 🔠 VK, 🔠 Yandex.
Рад, что оказался полезным на их пути. Старался прорабатывать совместно саму специфику прохождения, плюс нужные знания.
🔑 Также посетил тематические конференций - ArchDays, Podlodka TechLead, Стачка, HighLoad++(habr), ...
Стараюсь делиться знаниями, инсайтами для обогащения как архитектурного опыта, так и в целом полезным материалом.
На протяжение всего года я как автор канала создавал разнообразный контент на тему System Design и Архитектуры. Это были описанные встречи, текстовой и анимационный материал для тебя, для удобного восприятия.
4️⃣ Рост канала ~4x
С 500 -> 1900 за год! Без рекламы! Только качественный разнообразный контент и заинтересованные подписчики!
🔜 Дальше -> больше :)
💫 Рад, что дочитали до конца! :) Желаю всего самого хорошего! Cвершений и здоровья в Новом Году!
—
🎄 Спасибо тебе, 2024! Да здравствует 2025!
Ставь:
❤️ - если год для тебя прошёл супер)
💯 - выдался хорошим с приятными событиями
👍 - в среднем год как год, что-то получилось из задуманного
🤷 - сложно ответить было ли положительного больше
🏄♂️ Свершений, приятных открытий и душевного тепла!
🚀 2024 год промчался стремительно и насыщенно!
Делюсь основными активностями.
System Design
1) Провёл стрим на дружественном канале, посвященный шардированию. Судя по лайкам зрителям зашло 😊
2) Сделали серию мок интервью по System Design youtube, dropbox. Если собираешься собеседоваться - вот тебе готовые пособия 🥳
3) Встретились офлайн с подписчиками, отпраздновали рост канала. И в целом хорошо провели время :)
4) Создали несколько архитектурных кат. В организации первой здорово помогли Игорь и Евгения! На 2ой декабрьской сошлись 42 team, Za Gotbit, X team. Решения получились классные! Ребята молодцы! Отзывы о кате положительные! #ArchitecturalKata
5) Участвовал в хакатонах. Описал на канале часть. Несколько раз становился призёром в составе различных команд. Крутое последнее достижение - 2ое место на хакатоне от ВТБ. Хакатон - отличное место для проверки своих сил на реальной нужной компании задаче! #Hackathon
6) На ProIT Fest приехал с System Design задачей. Участники в дружеской атмосфере задавали интересные вопросы. Все вместе продуктивно провели встречу 👌
Спасибо Антону за решение!
7) Организовал дискуссию System Design Интервью: Казнить нельзя помиловать на HighLoad++ 2024 Moscow.
Теперь я понимаю сколько нужно подготовки и почему это не так просто 😏 Особенно, когда выступаешь не один. Когда нужно сводить всё в единую согласованную точку. У нас получилось! Для интересующихся такими собеседованиями как со стороны кандидата, так и со стороны компании скоро выложу ссылку. Мне как спикеру она доступна для шаринга.
8) Освятил чёткий фреймворк для прохождения System Design собеседований в БигТех компании.
🙋 Общение со студентами
Рассказывал студентам МГУ, МИРЭА современные реалии IT :)
👥 Новые авторы
На канале появились 2 новых автора:
Нина Пакшина рассказывала про эволюцию http #HTTP
Лариса Соловьева про реальный кейс с имплеменатцией Change Data Capture
🔅 Изюминка года
Ею стала беседа под NDA с одним из первопроходцев HFT. Потрясающая встреча! Я был в изумление от глубины понимания домена, технологий и навыков собеседника. Тот пример, когда 1 человек может реально многое.
💯 Самый популярный...
Приятной неожиданностью стал мой перевод статьи Как Notion обрабатывает 200 миллиардов объектов данных.
На хабре он вызвал положительную реакцию с 7.6 тыс просмотров, и короткий пост-ревью в телеграме с 14.2 тыс просмотров.
Был комментарий, что хотелось бы больше таких ревью. Взял на заметку ✍️
🥇 Эталон решения System Design задачи
Ближе к концу года мы встретились с Евгением - тимлидом Авито - для решения System Design задачи - проектирование LeetCode. Евгений последовательно расписал решение, ответил на множество моих вопросов и оставил после себя законченную схему. Для прокачки welcome :)
✅ Менторство как хобби
Стал преподавателем Отуса, активно делился знаниями как ментор.
Менти проходили успешно технические собеседования в BigTech -
Рад, что оказался полезным на их пути. Старался прорабатывать совместно саму специфику прохождения, плюс нужные знания.
🔑 Также посетил тематические конференций - ArchDays, Podlodka TechLead, Стачка, HighLoad++(habr), ...
Стараюсь делиться знаниями, инсайтами для обогащения как архитектурного опыта, так и в целом полезным материалом.
На протяжение всего года я как автор канала создавал разнообразный контент на тему System Design и Архитектуры. Это были описанные встречи, текстовой и анимационный материал для тебя, для удобного восприятия.
С 500 -> 1900 за год! Без рекламы! Только качественный разнообразный контент и заинтересованные подписчики!
🔜 Дальше -> больше :)
💫 Рад, что дочитали до конца! :) Желаю всего самого хорошего! Cвершений и здоровья в Новом Году!
—
🎄 Спасибо тебе, 2024! Да здравствует 2025!
Ставь:
❤️ - если год для тебя прошёл супер)
💯 - выдался хорошим с приятными событиями
👍 - в среднем год как год, что-то получилось из задуманного
🤷 - сложно ответить было ли положительного больше
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍14❤9💯6🤷5