System Design World

🏃‍➡️ Это кто к нам пришёл? Ката! Погнали!

Собираемся в четверг вечером 12.12.2024 в 20:00!
😔 К сожалению, интеграция нашего канала в этом году не состоится. Будем смотреть на следующий.

📆 Поскольку, я уверен, многие из вас уже забили это время под активность архитектурной каты - мы её всё-равно проведём!

😏 Подготовил интересное задание) После его презентации отвечаю на ваши вопросы. И go по командам проектировать!
За 45 минут. Жёстко? Зато интересно)

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

😊 Жду всех в наше чате - System Design Chat.
Ссылку на встречу размещу там ближе к времени старта.

Предложения и пожелания можно писать в чат или сюда в комментариях.

#ArchitecturalKata

🏵 VTB API hackathon 2024. Мы призёры!

💪 О самом хакатоне можно сказать одним словом - мощно!
Проведения хакатона, задачи, судейство, организация финала получили высокие оценки от участников!
Везде чувствовалась вовлеченность организаторов. И ответная активность команд.

Финальный питч офлайн - то ещё испытание 😅 И его получилось пройти!

🎥 Сделал ёмкое видео, чтобы передать атмосферу финала. enjoy :)

Полная версия - apihack.vtb.ru.
Мой питч - 5:55:15 (надо же)

▶️ Принимаешь участние в хакатонах? Если да, то почему? Если нет, то почему? :)

#Hackathon

VTB API hackathon 2024. Наш финал!

▶️ Дошли до финала! Сегодня питчу оффлайн.

3 трека:
1) Open API
2) gRPC
3) Единая платформа аутентификации API
Выбрали 3ий.

Финал открытый в отличие от летнего архитектурного хакатона от ВТБ. На котором тоже получилось дойти до финала.
✍️ Можете посмотреть созданные решения, намотать на ус интересные приёмы.

🎦 Наша защита в 16:45.
Подключайтесь!

https://apihack.vtb.ru/
Старт выступления: 5:55:15

System Design Interview вездесущ. Раньше старшим специалистам достаточно было показать свои навыки в доменной области, чтобы успешно устроиться на свою новую работу мечты. Сейчас же необходимо придумать и построить целую систему всего за 45 минут! Насколько такой навык нужен в реальной работе? Что проверяет такое собеседование?

На HighLoad++ 2024 в рамках дискуссии «System Design Interview: казнить нельзя помиловать» профессионалы взвесят все «за» и «против» — скучно не будет.

Посетить эту дискуссию стоит и менеджерам, планирующим или практикующим system design interview, и сотрудникам.

До скорой встречи, друзья 🙌

❄️🔥 Горячая дискуссия в первые дни зимы!

Зима близко! Осталось всего две недели до старта дискуссии System Design Interview: Казнить нельзя помиловать.

Начнём с вводной по этому популярному этапу интервью. Далее разберём по полочкам основные тезисы. А ещё приготовили небольшой интерактив для участников!

Стартуем 2 декабря в 17:00 в зале Найроби+Касабланка.
Приходи онлайн, оффлайн. Будет горячо! :)

🌪Архитектурный дзен

Стартовала ежегодная архитектурная конференция ArchDays.

Интересные доклады, общение. До мерча пока не дошёл😅

Отличие от HighLoad++ в большей абстракции. Больше разговоров на тему архитектуры, подходов, сути и специфики роли архитектора.

Позже напишу интересные тезисы с различных докладов.

А какая конференция нравится тебе больше всего? И почему?

⭐️ System Design LeetCode / TeamLead Avito

✔️ Смонтировал для тебя состоявшийся стрим с Евгением - тимлидом из Авито. Вышло ёмкое учебное пособие по прохождению интервью за 1 час :)

➡️Канал Евгения - https://t.me/afonasev_blog (питон, конференции, развитие языка, жизнь IT).

👍Gо прокачиваться:
youtube
rutube

❓Какой дизайн хочешь увидеть следующим?

🏃 В погоне за BIG TECH!

➕ Расширяем контекст подготовки к прохождению собеседований в BIG TECH компании новым каналом "Укусанный литкодом".

Знаю автора очень хорошо. Можно сказать, он мой давний друг 😊
Сейчас активно готовится в 🔤🔤🔤🔤🔤🔤. Пройдёт ли в этот раз? :) Достаточно ли 100 намеченных решенных задач для этого?

👀 Можно посмотреть как разработчик пропускает через себя алгоритмическую подготовку. С какими трудностями сталкивается. И как осознаёт происходящее и сами задачи.

https://t.me/leetcode_bytes_you/3

⭐️ Новый сезон активностей! Сплошная прокачка в 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. Отвечай боту про себя и желание участвовать.

Ставь лайк, если с нетерпением ждёшь озвученных активностей 😊
Какую первую из них хочешь увидеть на канале?

⚙️ Куда она закатилась? Надежность. Продолжаем осмыслять.

☝️ Ты думал, что знаешь всё про архитектуру? Давай осмыслим её ещё раз!
Хотел бы осветить следующий доклад, на котором получилось присутствовать онлайн и задавать вопросы после.

Филипп Дельгядо - «Где искать надежность при взаимодействии сервисов?»
Какие реальные взаимодействия стоят за нарисованными квадратами и стрелками? Почему то что принято считается надежным 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 переключился на новую версию или нет!

Брокер должен знать про число партиций. Это легко не поменять.
Producer знает каким образом consumer хочет чтобы его данные партиционировались. Т.е. producer должен обладать информацией о внутренней реализации консьюмера, чтобы корректно сформировать события, отправляемые в топик.

Очень ценная мысль! В http не надо знать каким образом устроен получатель.
Упомянуты битвы в крупных компаниях про число партиций в топике, количеств топиков в целом.😣
=>
Приходит на помощь паттерн Transaction Inbox!
Вносим очередь в сам сервис, который и потребляет данные. Заход через его api.

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

Хочешь ещё разборов докладов? -> ⚡️
Насколько тебе легко работается с очередями?

⚙️ Нужно больше надежности! Неделя надежности!

📆 Закончилась Podlodka TechLead Crew 7. Это онлайн конференция, посвященная техническим аспектам разработки систем.
На прошлой я победил как участник. В призах был свободный вход на любую из следующих встреч) Решил им воспользоваться)

Уровень "класс"! 👍
Сами доклады, общение Q/A, дискуссии в чате. На каких-то докладах присутствовал. Остальные посмотрю в записи.

Что посмотрел, запомнилось:
I. Александр Агейченко - «Надежный как кирпич»
Мир фронтенда чудесный и многообразный. И в возможностях. И в моментах, когда что-то может пойти не так(или всё).

• Улучшаем наблюдаемость.
Отслеживаем ошибки у клиентов:

Вы даже не представляете какие интересные тексты ошибок иногда показываются клиентам.

Жизнь.

• Crash-free.
По финтеху 99.6% нормально. Измеряют, к примеру, Firebase, Sentry. Больше крашей -> ухудшение рейтинга в поисковой выдаче.
Также советы по технологиям, ведению проекта.

• Обсуждение про бюджет ошибок, приоритеты.
Если не работает фича с низким бизнес приоритетом у малого количества пользователей - не факт, что её нужно чинить сейчас же.
Возможно, у тебя рядом ещё лёг модуль совершения банковской операции. Соберётся бизнес, тех лиды проекта. И выберут приоритет. Разработчики, зачастую, уже стоят где-то далеко в ожидание тикета.

• Как откатывать?
Задал вопрос по деплою. Оказывается, никак 🤷 Не принято в этом дивном новом мире. Если приоритет не работающей новой фичи большой, то делаем быстро хотфикс. Даже, возможно, в процессе текущей выкладки/обновления. Заставлять пользователя обновиться потом: "Не войдёшь, пока не обновишься!", - не лучшая практика. Оставляем на случаи обновления совсем старых неподдерживаемых версий.
Что ещё можно сделать? Использовать feature flags. Флагами включать, отключать функционал.

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

Продолжение в следующем посте 👌

❓А как ты улучшаешь надежность своего сервиса?

👥 Мультитенантность + 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 недели?

😲 WOW эффект для жюри хакатона!

➕ Участвую в очередном хакатоне.
ТЗ: разработать сервис для удобного добавления и тестирование страховых продуктов.
Прилагается отчётность, БД.
Команда дополнила решение фичами AI для тестирование гипотез в процессе добавления.

☝️ В ТЗ отдельным пунктом есть требование к масштабированию архитектуры.
Решил для финального питча показать его с элементами анимации для WOW эффекта 😊
Ведь в ограниченное время нужно продемонстрировать основной функционал и сделать это красиво)
🙂 Посмотрим, как в итоге зайдёт такое решение)

▶️ Как считаете, на питче нужно защищать решение спокойно, убедительно и сухо? Или с эмоциями, вау эффектами, явно демонстрируя исключительную крутость созданного сервиса?

P.S. Подробный отчёт выложу после подведения итогов👌