Рекомендованная литература и ресурсы
Куда идти дальше, когда книга закончилась. Без хайпа, без инфоцыганщины — только то, что реально стоит вашего времени.
Ни одна книга не сделает вас архитектором. Даже эта. Архитектура — это навык, который нарабатывается годами проб, ошибок и осознания «вот почему в прошлом проекте всё пошло не так».
Но хорошие книги и ресурсы — это катализаторы. Они дают язык для описания проблем, ментальные модели для принятия решений и, что важнее всего, чужие грабли, чтобы вы не наступали на свои.
Этот аппендикс — не «список книг, которые надо прочитать, чтобы стать архитектором». Это субъективная подборка того, что реально изменило подход к архитектуре у тысяч инженеров. Включая автора этой книги.
Каждая запись — не просто название. Это ответ на вопрос: почему это стоит вашего времени.
#1. Книги-классики
#1.1 «Designing Data-Intensive Applications» — Martin Kleppmann
Если бы мне пришлось оставить одну книгу по архитектуре — это была бы DDIA.
Не потому что она самая лёгкая (спойлер: нет). А потому что она даёт фундаментальное понимание того, как работают распределённые системы «под капотом». Репликация, партиционирование, транзакции, консенсус, потоковая обработка — Kleppmann разбирает каждый механизм до атомарного уровня и собирает обратно с объяснением компромиссов.
Это не книга рецептов. Это учебник анатомии распределённых систем. После неё вы перестанете воспринимать базы данных как «волшебные чёрные ящики» — вы будете знать, почему одна архитектура репликации подходит для вашего сценария, а другая — убьёт продакшен.
Кому: всем, кто серьёзно относится к архитектуре. Junior-ам — для фундамента. Senior-ам — для систематизации. Сложность: высокая. Читать медленно, с блокнотом. Совет: не пытайтесь прочитать за выходные. Это книга на полгода вдумчивого чтения.
#1.2 «Building Microservices» — Sam Newman (2nd edition)
Библия микросервисов без религиозного фанатизма.
Первое издание (2014) вышло на пике микросервисной эйфории и само того не желая, способствовало эпидемии «микросервисов ради микросервисов». Второе издание (2021) — гораздо более зрелое. Newman честно пишет о цене распределённых систем, о том, когда микросервисы не нужны, и о том, как избежать «распределённого монолита» — самой дорогой ошибки, которую вы можете совершить.
Особенно ценны главы про интеграцию сервисов, гранулярность и эволюцию архитектуры. Newman не говорит «делайте так» — он показывает спектр вариантов и цену каждого.
Кому: всем, кто переходит от монолита (или уже влез в микросервисы и хочет понять, как не умереть). Совет: если читаете первое издание — обязательно прочитайте второе. Это почти две разные книги.
#1.3 «Clean Architecture» — Robert C. Martin
Спорная книга. Её обожают и ненавидят примерно с равной интенсивностью.
Uncle Bob предлагает жёсткую архитектурную дисциплину: независимость от фреймворков, тестируемость изоляции, границы между слоями. Его подход (особенно пресловутая «диаграмма с кругами») отлично работает в корпоративных системах со сложной бизнес-логикой, где стабильность и тестируемость важнее скорости разработки.
Но если вы пишете простой CRUD-сервис, который завтра может быть выброшен — следование «Чистой архитектуре» будет overkill-ом чистой воды.
Ценность книги не в конкретных рецептах, а в принципах: инверсия зависимостей, границы архитектуры, различие между «plugin» и «core». Возьмите принципы, отбросьте догму.
Кому: middle/senior разработчикам, которые хотят понять, что такое архитектурные границы. Для начинающих — сначала прочитайте что-то более практичное. Совет: относитесь к диаграмме со слоями как к иллюстрации принципов, а не как к архитектурному плану вашего следующего проекта.
#1.4 «Domain-Driven Design: Tackling Complexity in the Heart of Software» — Eric Evans
«Синяя книга». Оригинал — 2003 год. До сих пор актуальна.
DDD — это не про технические паттерны (Entity, Value Object, Aggregate). Это про то, как сделать сложный бизнес-домен понятным для разработчиков. Evans вводит понятие Ubiquitous Language — единого языка между бизнесом и техникой — и Bounded Context, который становится основой для декомпозиции микросервисов.
Без DDD любая архитектура — просто техническое упражнение. С DDD архитектура обретает смысл: она отражает структуру бизнеса, а не структуру фреймворка.
Честное предупреждение: книга написана сложно. Evans — не самый лёгкий автор. Если на 50-й странице вы захотите её выбросить — это нормально. Попробуйте «Domain-Driven Design Distilled» (Vaughn Vernon) для начала.
Кому: архитекторам и tech lead-ам, которые работают со сложными доменами (финтех, healthcare, логистика). Сложность: высокая. Совет: читайте в паре с командой. DDD — это социальный процесс, а не техника индивидуального применения.
#1.5 «Site Reliability Engineering» — Google (Beyer, Jones, Petoff, Murphy)
Как Google строит и эксплуатирует системы на миллиарды пользователей. Без секретов, без купюр.
Главная идея SRE — относиться к эксплуатации как к инженерной дисциплине, а не как к «работе сисадмина». SLA, SLO, SLI, error budgets, toil automation, incident response — все эти понятия пришли из этой книги (ну, или из практики Google, которую книга документирует).
Особенно ценна глава про Service Level Objectives — как договариваться с бизнесом о том, сколько «девяток» вам реально нужно. Спойлер: обычно меньше, чем вы думаете, — и это нормально.
Есть ещё «The Site Reliability Workbook» — практическое дополнение с примерами внедрения SRE в разных компаниях.
Кому: каждому, кто отвечает за работу системы в продакшене. Совет: не пытайтесь скопировать Google SRE «как есть». У них тысячи инженеров и бесконечный бюджет. Берите принципы, адаптируйте под свой контекст.
#1.6 «The Art of Scalability» — Martin L. Abbott, Michael T. Fisher
Самый недооценённый учебник по масштабированию.
Авторы — бывшие CTO eBay и Akamai — вводят замечательную модель: AKF Scale Cube (также известный как «куб масштабирования»). Три оси:
- X-axis: горизонтальное копирование (клон-и-балансируй)
- Y-axis: декомпозиция по функциональности/сервисам
- Z-axis: шардинг данных
Эта простая модель позволяет понять, по какой оси масштабироваться на каждом этапе. И, что важнее, — в какой последовательности.
Книга написана для C-level аудитории, но техническим специалистам даёт отличную рамку для обсуждения масштабирования без хаоса.
Кому: от tech lead до CTO. Особенно тем, кто переходит от «просто работает» к «работает на миллион пользователей». Совет: прочитайте хотя бы главу про AKF Cube — это окупится на первом же архитектурном споре.
#1.7 «Fundamentals of Software Architecture» — Mark Richards, Neal Ford
Самая «приземлённая» книга по архитектуре. Если Clean Architecture — это философия, то Fundamentals — это инженерная практика.
Richards и Ford (оба из ThoughtWorks) систематизируют архитектурные подходы: layered, modular monolith, microkernel (plugin), event-driven, microservices. Для каждого — когда применять, какие метрики важны, какие компромиссы.
Особенно ценны главы про архитектурные характеристики (качества) и их измерение. Вы наконец-то сможете ответить на вопрос «насколько мы масштабируемы?» не на уровне ощущений, а на уровне метрик.
Ещё один бриллиант — раздел про архитектурные решения и ADR. После него вы перестанете принимать решения «на глаз».
Кому: тем, кто переходит от разработчика к архитектору. Лучшая стартовая книга по архитектуре на сегодня.
#1.8 «Software Architecture: The Hard Parts» — Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
Если Fundamentals — это «архитектура 101», то The Hard Parts — это «архитектура 501».
Авторы берут самые болезненные темы: как делить монолит, как управлять данными между сервисами, как выбирать между синхронной и асинхронной коммуникацией, как строить архитектуру, которая не заставит вас всё переписывать через год.
Никакой теории ради теории — только конкретные дилеммы и способы их решения. Каждая глава — это реальная проблема из практики: «у нас два сервиса, оба должны изменить одни данные — что делать?».
Кому: опытным разработчикам и архитекторам, которые уже столкнулись с «архитектурной болью» и хотят систематизации решений. Совет: читайте после Fundamentals. Это не книга для начинающих.
#1.9 «A Philosophy of Software Design» — John Ousterhout
Маленькая (170 страниц) и очень злая книга профессора Стэнфорда.
Ousterhout утверждает, что главная проблема в разработке — не технологии, а сложность. И предлагает конкретную метрику: complexity is anything that makes code hard to modify. Он вводит понятия deep vs shallow modules, information hiding, и tactical vs strategic programming.
Самая ценная идея: большинство разработчиков пишут код «тактически» — чтобы работало сейчас. Хорошие архитекторы пишут «стратегически» — инвестируя немного времени сейчас, чтобы сэкономить много времени потом.
Книга вызвала споры (особенно в части про комментарии и слои абстракции), но она заставляет думать. А это то, что нужно.
Кому: всем, кто пишет код и хочет писать его лучше. Сложность: низкая. Можно прочитать за вечер. Совет: после прочтения пересмотрите свой код. Вы увидите его иначе.
#1.10 «The Mythical Man-Month» — Frederick Brooks
Классика 1975 года. До сих пор актуальна.
Brooks сформулировал законы, которые не изменились за 50 лет:
- «Добавление людей к опаздывающему проекту делает его ещё более опаздывающим» (Закон Брукса)
- «Нет серебряной пули» — не существует одного технологического прорыва, который раз и навсегда решит проблемы разработки
- Проект, который не укладывается в сроки, скорее всего, не уложится никогда
Это книга не про технологии, а про человеческую природу разработки. Она не даст вам знания про Kafka или шардинг. Но она даст понимание, почему архитектурные решения — это всегда про людей, а не про код (о чём мы говорили в Главе 1).
Кому: всем, но особенно tech lead-ам и менеджерам, которые планируют сроки и команды. Совет: не читайте как техническую книгу. Читайте как книгу о менеджменте и коммуникации в разработке.
#1.11 «Enterprise Integration Patterns» — Gregor Hohpe, Bobby Woolf
«Книга с динозаврами» (библейская). Канонический справочник по интеграции систем.
Если ваша архитектура включает несколько сервисов, которые должны общаться — вы рано или поздно придёте к паттернам из этой книги: Message Router, Pipes and Filters, Splitter, Aggregator, Content Enricher, Claim Check. Грегор Хофпе систематизировал около 65 паттернов интеграции, и эта систематизация стала стандартом индустрии.
Да, книга написана для Java-экосистемы (и конкретно Apache Camel), но паттерны — универсальны. Вы будете встречать их в Kafka Streams, AWS Step Functions, Temporal, и даже в простых микросервисах на Python.
Кому: архитекторам, работающим с распределёнными системами и event-driven архитектурой. Совет: не читайте подряд. Используйте как справочник — заглядываете, когда сталкиваетесь с конкретной проблемой интеграции.
#1.12 «Database Internals» — Alex Petrov
Когда вы перерастёте главы про базы данных в этой книге и захотите знать, что на самом деле происходит под капотом.
Petrov разбирает внутреннее устройство баз данных: B-trees, LSM-trees, буферизацию, транзакции, MVCC, репликацию. Если DDIA отвечает на вопрос «какую архитектуру выбрать», то Database Internals отвечает на вопрос «почему она работает именно так».
Особенно полезна глава про LSM-trees для тех, кто использует Cassandra, ScyllaDB, RocksDB или LevelDB. После неё вы перестанете гадать, почему compaction жрёт CPU — вы будете знать.
Кому: senior-инженерам, которые работают с базами данных не как с «чёрным ящиком». Совет: читайте после DDIA. Они отлично дополняют друг друга.
#1.13 «Understanding Distributed Systems» — Roberto Vitillo
Самая «лёгкая» книга по распределённым системам, которую я знаю.
Vitillo (работал в Microsoft, AWS) берёт сложные темы: консенсус, репликацию, партиционирование, отказоустойчивость — и объясняет их без излишней математики и без академического формализма.
Это не замена DDIA. Это подготовка к DDIA. Если вы пробовали читать Kleppmann и бросили на середине — начните с Vitillo. Он даст ту же базу, но в более доступной форме.
Кому: тем, кто хочет понять распределённые системы, но боится DDIA. Сложность: средняя (но темы — сложные). Совет: прочитайте, а потом беритесь за DDIA для глубины.
#1.14 «System Design Interview» — Alex Xu
Спорная книга в этом списке. Она про прохождение собеседований, а не про архитектуру как дисциплину.
Но у неё есть одно неоспоримое достоинство: она учит структуре мышления. Каждое решение в книге разбирается по шаблону: требования → оценка → дизайн → компромиссы → боттлнеки. Это отличная рамка для архитектурного мышления, даже если вы не собираетесь проходить собеседования.
Проблема книги в том, что решения — поверхностны. «Дизайн Twitter» на 30 страницах даст вам схему, но не глубину. Используйте как тренажёр мышления, а не как учебник.
Кому: всем, кто готовится к system design интервью. Тем, кто уже работает архитектором — скорее для самоиронии, чем для пользы.
#1.15 «Patterns of Enterprise Application Architecture» — Martin Fowler
«Книга с лошадкой» (библия корпоративной архитектуры 2000-х).
Fowler описал паттерны, которые стали стандартом для enterprise-приложений: Repository, Unit of Work, Data Mapper, Active Record, Table/Row Data Gateway, Identity Map, Lazy Load.
Для современной веб-разработки многие паттерны кажутся «очевидными» — но они были очевидными именно потому, что Fowler их систематизировал. Без этой книги не было бы ни Hibernate, ни Entity Framework, ни ActiveRecord в Rails.
Сегодня книга — скорее исторический справочник. Но если вы работаете с legacy-системами (а кто не работает), вы будете узнавать эти паттерны в коде, написанном 15 лет назад.
Кому: тем, кто работает с enterprise-системами или legacy-кодом.
#2. Engineering-блоги компаний
Реальные проблемы, реальные решения. Без абстракций и «в вакууме». Лучший способ учиться на чужих ошибках — читать инженерные блоги компаний, которые делают эти ошибки и честно о них пишут.
#2.1 Netflix Tech Blog
Один из старейших инженерных блогов. Netflix пилит контент с 2012 года — от Chaos Engineering до Content Delivery.
Что читать:
- «Chaos Monkey» — рождение chaos engineering
- «The Evolution of Netflix's API Architecture» — как растёт API
- «Building Netflix’s Distributed Tracing Infrastructure» — observability на масштабе
- «Scaling the Netflix Data Plane» — тысячи сервисов
Почему стоит: Netflix — один из немногих, кто пишет не только про успехи, но и про то, что не сработало. Особенно ценно для энтерпрайза.
#2.2 Uber Engineering
Гигант, который прошёл путь от монолита до hundreds of microservices — и частично обратно.
Что читать:
- «Introducing Domain-Oriented Microservice Architecture» — как Uber упорядочил хаос из 2200+ сервисов
- «Building Uber's Fulfillment Platform» — платформенный подход
- «Real-Time Exactly-Once Event Processing» — сложность распределённой обработки
- «Uber's Big Data Platform: 100+ PB to 500+ PB»
Почему стоит: Uber в 2019-2021 провёл колоссальную работу по осмыслению микросервисного хаоса. Их подход к Domain-Oriented Microservice Architecture — это, по сути, DDD на стероидах.
#2.3 AWS Architecture Blog
https://aws.amazon.com/blogs/architecture
Проприетарный, но полезный. Amazon делится архитектурными паттернами для облака.
Что читать:
- «Strangler Fig Pattern» — паттерн постепенной миграции
- «Implementing Health Checks» — how AWS does it
- «Building a Serverless Data Lake» — архитектура на managed-сервисах
- «Resiliency Patterns» — circuit breaker, bulkhead, saga на AWS
Почему стоит: даже если вы не на AWS — паттерны универсальны. Отличный источник практических архитектурных схем.
#2.4 Google Cloud Blog
Больше, чем просто маркетинг. Google публикует глубокие технические статьи.
Что читать:
- «Spanner: Google's Globally Distributed Database» — семинальная работа
- «Google SRE: How We Run Production Systems»
- «Event-Driven Architectures with Pub/Sub and Kafka»
- «Kubernetes Design and Evolution»
Почему стоит: Google пишет на уровне whitepaper-ов. Их статьи — это, по сути, мини-главы из книги SRE.
#2.5 Engineering at Meta (Facebook)
Meta раскрыла инженерные практики меньше, чем хотелось бы, но некоторые статьи — золото.
Что читать:
- «Scaling Memcache at Facebook» — как работает кэш на миллиарды запросов
- «TAO: Facebook's Distributed Data Store for the Social Graph» — графовая база на масштабе
- «Building a Billion-User Load Balancer»
- «The Evolution of Facebook's News Feed Architecture»
Почему стоит: масштаб Facebook — это уровень, к которому большинство никогда не приблизится. Но понимать, как это работает, — полезно.
#2.6 Discord Engineering
https://discord.com/category/engineering
Маленькая команда, огромная нагрузка. Discord пишет честно, без пафоса, с реальными цифрами.
Что читать:
- «How Discord Stores Billions of Messages» — от MongoDB к ScyllaDB
- «How Discord Handles 18 Million Concurrent Voice Users»
- «From 1M to 100M Users — Discord's Architecture Evolution»
- «So You Want to Build a Chat App» — рефлексия о масштабировании
Почему стоит: Discord — лучший пример того, как архитектура эволюционирует с ростом нагрузки. Никаких «изначально спроектировали идеально» — только реальные проблемы и их решения.
#2.7 Slack Engineering
Особенно ценны статьи о миграции с монолита и multi-region архитектуре.
Что читать:
- «Slack's Migration from Monolith to Microservices» — честный рассказ (спойлер: было больно)
- «How Slack Went Multi-Region» — переезд из single-region в global
- «Flannel: An Application-Level Edge Cache» — CDN для API
- «Scaling Slack's Infrastructure by 10x in One Year»
Почему стоит: Slack — это кейс компании, которая очень долго жила на монолите, переезжала на микросервисы с огромными сложностями, и в итоге нашла свой баланс. Очень честный блог.
#2.8 Stripe Engineering
https://stripe.com/blog/engineering
Платёжная архитектура — это настолько high-stakes, что Stripe вынуждена быть идеальной.
Что читать:
- «Designing for Reliability: Stripe's Data Infrastructure»
- «How Stripe Built a Real-Time Payment Infrastructure»
- «Online Migrations at Scale» — как менять схему БД без даунтайма
- «Building a Serverless Payment Platform» — насколько Stripe де-факто serverless
Почему стоит: Stripe — образец архитектурной дисциплины. Их подход к миграциям, идемпотентности и отказоустойчивости — это уровень, к которому стоит стремиться.
#2.9 Cloudflare Blog
Половина статей — про то, как Cloudflare выживает при DDoS-атаках. Вторая половина — про архитектуру Edge сети.
Что читать:
- «How Cloudflare Mitigated a 2 Tbps DDoS Attack»
- «A Deep Dive into DNS Resolution»
- «Edge Computing: Cloudflare Workers Architecture»
- «How We Built a Global Load Balancer Based on Anycast»
Почему стоит: Cloudflare пишет с невероятной глубиной. Их статьи — это мини-курсы по теме. Особенно ценно для понимания CDN, Edge и безопасности.
#2.10 LinkedIn Engineering
https://engineering.linkedin.com
LinkedIn прошёл один из самых задокументированных переходов от монолита к микросервисам.
Что читать:
- «The Evolution of LinkedIn’s Architecture» — серия статей
- «Building LinkedIn's Real-Time Active User Graph»
- «Kafka at LinkedIn: From Inception to Scale»
- «How LinkedIn Optimized Its Data Pipeline for 50 PB+ Data»
Почему стоит: LinkedIn — первопроходец в Kafka, Voldemort, Samza. Они не просто используют — они создают технологии.
#2.11 Spotify Engineering
https://engineering.atspotify.com
Spotify славится своей культурой инженерии и платформенным подходом.
Что читать:
- «How Spotify Deploys 100 Times a Day» — CI/CD на масштабе
- «Backstage: Spotify's Internal Developer Platform» — рождение IDP
- «Squad Health Check Model» — про организационную архитектуру
- «Moving from a Monolith to Microservices: Spotify's Journey»
Почему стоит: Spotify — лучший пример того, как строить внутренние платформы. Backstage стал стандартом индустрии.
#2.12 Figma Engineering
https://www.figma.com/blog/section/engineering
Figma — это технический вызов на уровне «как запустить Photoshop в браузере». Их инженерный блог — настоящая жемчужина.
Что читать:
- «How Figma Runs WebAssembly at the Edge»
- «Building a Real-Time Collaborative Editor» — CRDT на практике
- «Scaling WebSocket at Figma» — как держать миллионы соединений
- «How We Migrated Our Database Without Downtime»
Почему стоит: Figma решает проблемы, которых нет у 99% проектов. Но когда они появятся у вас — вы будете рады, что читали их блог.
#2.13 Martin Fowler's Blog
Не компания, но человек, чей блог — must-read для каждого архитектора.
Что читать:
- «Microservices: A Definition of This New Architectural Term» — оригинальное определение
- «Strangler Fig Application» — паттерн миграции
- «Continuous Integration» — оригинал
- «Bliki» — вся энциклопедия архитектурных терминов
Почему стоит: Фаулер — не просто пишет, он категоризирует. Его bliki — это архитектурный словарь, к которому вы будете возвращаться.
#2.14 Joel on Software / Stack Overflow Blog
https://www.joelonsoftware.com / https://stackoverflow.blog
Джоэл Спольски написал много лет назад, но его посты — база.
Что читать:
- «Things You Should Never Do, Part I» — почему переписывать код с нуля — плохая идея
- «The Law of Leaky Abstractions» — почему абстракции всегда протекают
- Stack Overflow Blog — кейсы масштабирования (монолит на 1 млрд запросов)
Почему стоит: Спольски — один из лучших технических писателей. Его эссе 20-летней давности читаются как сегодняшние.
#3. Подкасты по архитектуре
Подкасты — отличный способ учиться в дороге, спортзале или за мытьём посуды. Вот те, где говорят про архитектуру, а не про «какой фреймворк круче».
#3.1 Software Engineering Daily
https://softwareengineeringdaily.com
Выпуск каждый будний день. Гости — инженеры из топ-компаний, темы — от брокеров сообщений до архитектуры LLM.
Лучшие выпуски: с авторами DDIA, Building Microservices, SRE. Интервью с инженерами Netflix, Uber, Google, AWS. Формат: интервью, 30-60 минут. Стартовая точка: выпуски с Martin Kleppmann или Sam Newman.
#3.2 The InfoQ Podcast
https://www.infoq.com/podcasts
Более «конференционный» формат. Ведущие InfoQ берут интервью у спикеров QCon и других конференций.
Лучшие выпуски: с архитекторами из Netflix, Amazon, Spotify. Особенно хороши выпуски по DDD и event-driven архитектуре. Формат: интервью, 40-60 минут. Совет: InfoQ также публикует текстовые стенограммы — если не любите слушать.
#3.3 Software Engineering Radio
Один из старейших подкастов (с 2006 года). Академичный, глубокий. Каждый выпуск — по одной теме с экспертом.
Лучшие выпуски: «Architecture of Distributed Systems», «Feature Flags», «CQRS/ES», «Chaos Engineering». Формат: интервью, 60-90 минут. Совет: проверяйте гостя. Качество варьируется, но топ-выпуски — среди лучшего, что есть.
#3.4 The Changelog
Больше про open source и технологии, но с архитектурным углом. Если вышла новая база данных, новый паттерн или новая платформа — The Changelog об этом расскажет.
Лучшие выпуски: с создателями Kubernetes, Terraform, Kafka, Terraform, Temporal. Формат: интервью + обсуждение, ~60 минут. Совет: подписаться обязательно — даже если выпуск не про архитектуру, он расширяет кругозор.
#3.5 Kubernetes Podcast from Google
Если вы работаете с Kubernetes (или собираетесь) — это must-listen. Гости — maintainer-ы ключевых проектов, CNCF, ведущие инженеры Google.
Лучшие выпуски: про evolution of Kubernetes, service mesh, security, cluster federation. Формат: новости + интервью, ~30 минут. Совет: очень плотный и информативный. Не подкаст для фона — требует внимания.
#3.6 Thoughtworks Technology Podcast
https://www.thoughtworks.com/en-gb/insights/podcasts/technology-podcast
ThoughtWorks публикуют «Technology Radar» — их знаменитый отчёт о технологических трендах. Подкаст — это развёрнутая версия Радара.
Лучшие выпуски: про platform engineering, AI-assisted development, архитектурные компромиссы, DDD. Формат: обсуждение внутри ThoughtWorks, 30-60 минут. Совет: один из самых «архитектурных» подкастов. Минимум хайпа, максимум инженерного подхода.
#3.7 Architecture Bytes (Архитектура ПО)
https://t.me/archbytes — русскоязычный
Один из лучших русскоязычных подкастов об архитектуре (в текстовом формате — Telegram-канал). Автор переводит и анализирует ключевые архитектурные концепции, пишет разборы конференций и книг.
Почему стоит: качественный контент по архитектуре на русском — редкость. Если английские подкасты тяжело слушать — начните с этого.
#4. Конференции
Записи докладов — золотая жила. Лучшие доклады не уступают книгам по глубине, а по формату часто выигрывают: 40 минут концентрированной информации с демонстрацией и Q&A.
#4.1 QCon (InfoQ)
Флагманская конференция InfoQ. Фокус — практическая архитектура от инженеров топ-компаний. Минимум вендорского маркетинга.
Что смотреть:
- Доклады про архитектурные решения — case studies от тех, кто это сделал
- Треки по DDD, Event-Driven, Observability, AI-architecture
- Keynote-ы от CTO и Chief Architects
Где смотреть: InfoQ.com публикует записи бесплатно (большинство докладов — через 3-6 месяцев после конференции).
#4.2 KubeCon + CloudNativeCon
https://events.linuxfoundation.org/kubecon-cloudnativecon-cloudnativecon-europe
Главная конференция по cloud-native архитектуре. Тысячи докладов, сотни компаний.
Что смотреть:
- Доклады по Kubernetes, service mesh, serverless, platform engineering
- Case studies миграции на cloud-native
- CNCF проекты — глубокие технические доклады
Где смотреть: YouTube канал CNCF — все доклады бесплатно.
#4.3 Strange Loop
https://www.thestrangeloop.com
Самая «интеллектуальная» конференция в этом списке. Strange Loop собирает доклады на стыке архитектуры, языков программирования, баз данных и распределённых систем.
Что смотреть:
- «The Death of Microservice Madness» — Дейв Томас
- «Making Databases Work at Scale» — изнутри БД
- Доклады по CRDT, consensus algorithms, database internals
Где смотреть: YouTube — большинство докладов опубликованы. К сожалению, Strange Loop не проводилась с 2023 года, но архив — бесценен.
#4.4 AWS re:Invent
https://reinvent.awsevents.com
Огромная конференция с вендорским налогом, но с невероятным количеством технических докладов.
Что смотреть:
- Keynote Вернера Фогельса (CTO AWS) — каждый год
- «Architecture Sunday» — архитектурная секция
- Case studies от клиентов AWS (Netflix, Airbnb, Stripe делятся архитектурой)
Где смотреть: YouTube канал AWS Events (бесплатно).
#4.5 GOTO Conferences
GOTO (бывшие JAOO) — европейская конференция с отличным составом докладчиков.
Что смотреть:
- Доклады Мартина Клеппмана, Сэма Ньюмана, Катерины Калех
- Сессии по event-driven architectures и platform engineering
- Software architecture треки — от теории к практике
Где смотреть: YouTube канал GOTO Conferences.
#4.6 NDC Conferences
NDC (Norwegian Developer Conference) — одна из лучших конференций для практикующих разработчиков и архитекторов. Проходит в Осло, Лондоне, Сиднее и других городах.
Что смотреть:
- Architecture треки — Kevlin Henney, Ian Cooper, Dave Farley
- Доклады по production-ready архитектуре
- Clean Architecture, DDD, микросервисы — без догмы
Где смотреть: YouTube канал NDC Conferences. Все доклады публикуются в течение нескольких месяцев после конференции.
#4.7 Конференции по DDD (DDD Europe / Explore DDD)
https://dddeurope.com / https://exploreddd.com
Специализированные конференции по Domain-Driven Design. Если DDD для вас — не просто «Entity и Value Object», а способ думать о сложности — это must.
Что смотреть:
- Доклады Эрика Эванса, Вона Вернона, Альберто Брандолини
- Практические case studies применения DDD
- Event Storming, Domain Storytelling — техники моделирования
Где смотреть: YouTube — записи предыдущих лет.
#5. Онлайн-курсы и ресурсы
#5.1 MIT 6.824: Distributed Systems
https://pdos.csail.mit.edu/6.824
Бесплатный курс MIT. Одно из лучших введений в распределённые системы. Лекции читаются на уровне «читаем научные статьи и разбираемся, как работает настоящая распределённая система».
Темы: MapReduce, GFS, Raft, Zookeeper, Spark, Kafka, DynamoDB. Формат: видеолекции + лабораторные (пишете Raft с нуля на Go). Сложность: высокая. Лабы — это недели работы.
Почему стоит: после 6.824 вы перестанете бояться распределённых систем. Вы будете знать Raft не «на уровне картинки» — вы его напишете.
#5.2 System Design Primer (GitHub — donnemartin)
https://github.com/donnemartin/system-design-primer
Открытый учебник по system design. 200k+ звезд на GitHub.
Темы: от DNS до CDN, от шардинга до геошардинга. Каждый компонент — с объяснением, зачем он нужен и какие у него компромиссы.
Почему стоит: лучшая бесплатная подборка по system design. Используйте как шпаргалку после книги, а не как учебник.
#5.3 ByteByteGo (Alex Xu)
Платформа автора «System Design Interview». Анимированные диаграммы, объяснения, чек-листы.
Формат: еженедельные рассылки, видео на YouTube, платный курс. Сильные стороны: визуализация сложных концепций. Хорошо для понимания «как это выглядит в целом».
Ограничения: поверхностно. Используйте для общего понимания, не для глубины.
#5.4 A Cloud Guru / Pluralsight
https://acloudguru.com / https://pluralsight.com
Платные платформы с курсами по архитектуре, AWS, GCP, Azure, Kubernetes.
Лучшие курсы:
- «AWS Solutions Architect» — для облачной архитектуры
- «Kubernetes Deep Dive» — для контейнерной оркестрации
- «Software Architecture: From Developer to Architect» — для перехода к архитектуре
Почему стоит: курсы — прикладные. Вы не просто смотрите, вы делаете лабы.
#5.5 High Scalability
Блог (и архив), который собирает архитектурные обзоры известных систем. Формат: «как сделано X» — от Twitter до Stack Overflow.
Лучшие посты:
- «The Architecture of Stack Overflow» — монолитная архитектура на 1 млрд запросов
- «What Powers Instagram: Thousands of Instances, Dozens of Technologies»
- «The Architecture of Twitter: From Fail Whale to Real-Time Scale»
Почему стоит: лучший источник для понимания «архитектуры реального мира». Жаль, в последние годы выходит редко.
#5.6 System Design Newsletter (Substack / LinkedIn)
Еженедельные рассылки по архитектуре:
- The Architecture Newsletter — короткие, но глубокие разборы
- ByteByteGo Weekly — иллюстрированные обзоры
- RapidLoop's "Architecture Notes" — для Kubernetes-архитекторов
- Last Week in AWS — с юмором про облачную архитектуру
Почему стоит: архитектура — это мышца. Еженедельные разборы чужих систем держат её в тонусе.
#5.7 Архитектурное сообщество — где обсуждать
Одиночное изучение — хорошо. Обсуждение — лучше.
- r/softwarearchitecture — Reddit, умеренно активное сообщество
- r/systemdesign — для практики system design кейсов
- Hacker News (news.ycombinator.com) — лучший источник обсуждений архитектурных новостей
- Telegram: @archblogs — подборка переводов key engineering блогов на русский
- Telegram: @highload — русскоязычное сообщество, регулярные обсуждения архитектуры
#Вместо заключения
Вот честный совет: не пытайтесь прочитать всё.
Из этого списка:
- 3 книги прочитайте от корки до корки (DDIA, Building Microservices, Fundamentals of Software Architecture)
- Остальные — читайте по главам, когда сталкиваетесь с соответствующей проблемой
- Блоги — подпишитесь на 2-3 и читайте еженедельно
- Подкасты — выберите один и слушайте в дороге
- Конференции — смотрите доклады по темам, которые болят прямо сейчас
Архитектура — это марафон, а не спринт. Никто не становится архитектором за месяц чтения. Но если вы будете читать по одной книге в квартал, смотреть один доклад в неделю и обсуждать прочитанное с коллегами — через два года вы будете удивляться, как вообще раньше принимали архитектурные решения.
И помните главное: лучшая архитектура — та, которую вы понимаете и можете объяснить. Если вы не можете объяснить своё архитектурное решение тому, кто пишет код — это плохое решение, даже если за ним стоит DDIA и три конференции.
Удачи. И да прибудет с вами низкая связанность.