#32 Почему микросервисы могут разорить, а монолит выручить: инсайты из практики

В этом выпуске мы поговорили с Владимиром Ивановым, Senior Engineering менеджером в Bolt, о системном дизайне и его роли в создании крупных сервисов. Обсудили, как подойти к проектированию, начиная от простых односерверных решений и заканчивая распределёнными системами с балансировкой нагрузки, резервированием и шардированием баз данных. Разобрали, чем на самом деле отличаются реальная жизнь и собеседования по системному дизайну, затронули тему микросервисов и того, когда они действительно нужны, а когда нет. Поделились практическими советами, как соотносить бизнес-требования с техническими решениями, и почему разработчику важно мыслить шире, чем просто написание кода. Не пропустите — в выпуске много живых кейсов и инсайтов из реальных проектов!✅ Подписывайтесь на канал «Организованное программирование» в Telegram: ttttt.me/orgprog – Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): podcast.ru/1734325321 – Смотреть в YouTube: youtu.be/5A7ncMHfB1gПолезные ссылки: Business Oriented System Design Course: vvsevolodovich.dev/business-oriented-system-de… />twitter.com/vvsevolodovich t.me/@vvsevolodovich t.me/@architectureweekly youtube.com/@architectureweekly;
<ul><li>() - – Введение и анонс
</li>
<li>() - – Проблемы с самокатами: рост количества, отсутствие инфраструктуры, ужесточение законодательства.
</li>
<li>() - – История системного дизайна: различия между российским и западным подходами, восприятие дизайна в индустрии.
</li>
<li>() - – Три типа компаний: продуктовые, сервисные и оффлайновые – их подход к системному дизайну.
</li>
<li>() - – Образование в IT: почему большинство разработчиков не готовы к проектированию сложных систем.
</li>
<li>() - – Проблемы с обучением системному дизайну: нехватка учебных материалов, передача знаний только через практику.
</li>
<li>() - – Сложности оценки системного дизайна: нет универсальных метрик, важность инженерного мышления.
</li>
<li>() - – Проектирование сложных систем: аналогии с машиностроением, влияние изменений на всю систему.
</li>
<li>() - – Влияние организационных и бизнес-требований: почему IT-решения часто усложняются искусственно.
</li>
<li>() - – Кейсы из бизнеса: пример с биллингом Bolt и необходимость технологических изменений.
</li>
<li>() - – Влияние команды: квалификация и мотивация разработчиков определяют эффективность решений.
</li>
<li>() - – Базовые навыки архитектора: облачные технологии, сети, безопасность, управление данными.
</li>
<li>() - – Организация работы в IT: роль стейкхолдеров, инвесторов и технических специалистов.
</li>
<li>() - – Найм правильных людей: 70% разработчиков не могут стать эффективными менеджерами.
</li>
<li>() - – Оптимизация решений: использование облачных платформ и их влияние на разработку.
</li>
<li>() - – Риски облачных технологий: необходимость осознанного подхода, стоимость и ограничения.
</li>
<li>() - – Взаимодействие с бизнесом: как упрощение требований сокращает время разработки.
</li>
<li>() - – Веб-разработка и системный дизайн: важность понимания архитектурных решений.
</li>
<li>() - – Масштабирование и доступность: почему стабильность требует сложных решений.
</li>
<li>() - – Проблемы с производительностью: важность кэширования, индексов и оптимизации баз данных.
</li>
<li>() - – Архитектурные ошибки: неоправданное усложнение систем и «архитектурные астронавты».
</li>
<li>() - – Стадии компетентности: путь от неосознанной некомпетентности к экспертному уровню.
</li>
<li>() - – Вопросы для оценки решений: какие риски могут убить продукт.
</li>
<li>() - – Бэкапы и отказоустойчивость: примеры реальных провалов и их последствия.
</li>
<li>() - – Практическое тестирование: важность проверки резервного восстановления данных.
</li>
<li>() - – Региональные требования и блокировки: как они влияют на хранение данных.
</li>
<li>() - – Ошибки хранения данных: почему нельзя хранить их внутри приложения.
</li>
<li>() - – Kubernetes и масштабирование: как правильно строить отказоустойчивые системы.
</li>
<li>() - – Микросервисы vs. монолит: плюсы и минусы подходов.
</li>
<li>() - – Разница между интервью по системному дизайну и реальной архитектурой.
</li>
<li>() - – Оценка зрелости разработчика: что показывают вопросы на собеседовании.
</li>
<li>() - – Стоимость решений: баланс между затратами, производительностью и бизнес-логикой.
</li>
<li>() - – Итоги: системный дизайн как ключевой навык, анонс курса по бизнес-ориентированному системному дизайну.</li>
</ul>

<a href="boosty.to/mokevnin">★ Support this podcast ★</a>

#32 Почему микросервисы могут разорить, а монолит выручить: инсайты из практики | Владимир Иванов

Kapitelklicken springt direkt hin

Shownotes