Автор: Listen IT · YouTube · статья Highload Today

Репликация и шардинг распределяют данные между несколькими серверами, но решают разные задачи. Репликация создаёт несколько копий одного набора данных. Шардинг делит сам набор на части, каждая из которых хранится отдельно.

Ролик Listen IT даёт короткое введение в оба подхода. Реплики можно использовать для резервирования и переноса части чтений с основного узла. Шардинг нужен, когда объём данных или нагрузка перестают помещаться на одном сервере: система выбирает shard key и по нему определяет, где должна находиться каждая запись.

Разница становится особенно важной при отказе. Реплика может заменить основной узел только при наличии механизма failover. У шарда замены вообще может не быть, если его не реплицировать отдельно. Поэтому production-система часто сочетает оба подхода: данные разделены на шарды, а внутри каждого шарда есть несколько копий.

Кому смотреть: backend-разработчикам, которые впервые выбирают способ горизонтального масштабирования базы данных.

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

Автор: Eugene Suleimanov · Proselyte

Почти двухчасовой курс от автора Eugene Suleimanov показывает Keycloak не как «готовую страницу входа», а как отдельную платформу, которой приложение передаёт значительную часть работы с аутентификацией и авторизацией.

Полностью пересказать такой материал в одном дайджесте невозможно. Автор последовательно проходит от realm, clients, scopes и roles до OAuth 2.0, OpenID Connect, SAML, федерации пользователей и межсервисного доступа. Затем собирает практическую систему с двумя приложениями, PostgreSQL и Keycloak, подключает внешние Identity Providers и защищает вызовы между сервисами.

Главная мысль курса — у приложения не одна граница входа. Пользователь может приходить напрямую или через GitHub, учётная запись может храниться в LDAP, а один сервис должен обращаться к другому без участия человека. Keycloak даёт общую точку, где эти сценарии можно описывать и контролировать.

Кому смотреть: разработчикам и архитекторам, которые выбирают между собственной подсистемой доступа и отдельной identity-платформой.

Из этого можно взять в работу: перечислить все способы, которыми люди и сервисы получают доступ к системе, и проверить, не реализует ли каждый компонент собственную несовместимую схему аутентификации.

Источник: Распределенные системы и system design

Когда одной базы уже недостаточно по объёму, чтению и записи, шардирование выглядит неизбежным решением. Но на этом масштабирование не заканчивается — оно только начинается. Как только сообщения распределяются по шардам, приходится отдельно решать проблему порядка, генерации ID, Kafka, WebSocket-соединений и доставки между регионами.

В авторском ролике разбирается system design мессенджера на миллиард пользователей. Требования намеренно ограничены: создать чат, добавить или удалить участника, отправить текстовое сообщение и доставить его в реальном времени пользователям, которые сейчас онлайн. Статусы прочтения, реакции и медиа автор не рассматривает — они могут быть добавлены поверх предложенной архитектуры.

Кому смотреть: backend-разработчикам и тем, кто готовится к system design-интервью, но хочет увидеть не список модных технологий, а цепочку инженерных компромиссов: какое решение принимается первым и какие новые проблемы оно создаёт дальше.

Из этого можно взять в работу: при шардировании сначала зафиксируйте инварианты. В этом дизайне сообщения одного чата должны оставаться в одном логическом потоке, а их ID — возрастать. Именно эти требования определяют и ключ шардирования базы, и распределение сообщений в Kafka.

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. Event Storming — воркшоп-техника, разработанная Альберто Брандолини. Сессия начинается не с рисования схем, а с вопроса: какие события происходят в системе? И именно этот порядок меняет всё.

Типичная архитектурная сессия выглядит так: техлид рисует диаграмму, остальные кивают или спорят о деталях реализации. Знание о домене остаётся в головах у бизнес-экспертов и не попадает в код. Event Storming переворачивает процесс: на стену клеятся оранжевые стикеры с доменными событиями («заказ размещён», «платёж подтверждён», «склад уведомлён»), и сразу становится видно, где у команды нет общего языка — кто-то называет одно и то же по-разному, кто-то предполагает событие, которого на самом деле не существует. Пробелы в знании домена вскрываются за часы, а не за месяцы.

Кому смотреть: техлидам и разработчикам, участвующим в проектировании новых фич или рефакторинге сложной предметной области — особенно там, где бизнес-логика плохо формализована.

Из этого можно взять в работу: следующий раз, когда команда пишет задачу на новую фичу, попробуйте перед техническим дизайном провести 30-минутный мини-Event Storming: попросите каждого участника написать 3–5 событий, которые должны произойти в системе. Несоответствия вскроются моментально.

Автор: Папочка Разработки · Папочка Разработки

Канал «Папочка Разработки», 20 минут. CQRS (Command Query Responsibility Segregation) — паттерн с устойчивой репутацией «понятного на собесе, но непонятного в коде». Видео разбирает, почему так происходит.

Распространённое понимание CQRS: разделить код на команды (пишут данные) и запросы (читают данные), сложить по разным папкам, добавить Handler для каждого — и считать, что CQRS внедрён. Это не CQRS, это просто именование. Настоящий паттерн — про разделение моделей: модель записи оптимизирована для инвариантов и бизнес-правил, модель чтения — для отображения данных в том виде, в котором их хочет видеть клиент. Когда модели разделены по-настоящему, появляется возможность масштабировать чтение и запись независимо, использовать разные хранилища, денормализовать read-side для производительности. Без разделения моделей это просто организация кода, а не архитектурный паттерн.

Кому смотреть: разработчикам, которые используют или планируют CQRS и хотят убедиться, что понимают его правильно — и тем, кто готовится к техническому интервью, где этот паттерн регулярно всплывает.

Из этого можно взять в работу: если у вас уже «есть CQRS» — проверьте: используете ли вы разные модели для чтения и записи? Если read side — это та же доменная модель, просто завёрнутая в Query-объект, вы не используете CQRS, вы используете именование.

Автор: Юрий Самсонов · JUG.ru

Юрий Самсонов — разработчик из Яндекса. Доклад на JPoint 2023 — не обзор GraphQL и не агитация за его повсеместное использование, а конкретный опыт внедрения: что сломалось, что не ожидали, как вышли.

REST-эндпоинты имеют предсказуемую проблему роста: по мере того как клиентов становится больше, у каждого появляются свои требования к форме данных. Один клиент хочет вложенный объект, другой — плоский список. Появляются параметры вроде ?include=user,tags,comments, эндпоинты обрастают опциями, и в какой-то момент backend-разработчик обнаруживает, что его работа — это в основном добавление новых вариаций существующих эндпоинтов под нужды клиентов. GraphQL переворачивает эту ответственность: клиент сам описывает, какие данные ему нужны, и получает ровно их — без over-fetching и under-fetching. Самсонов честно рассказывает о том, что эта свобода стоит: N+1 проблемы, сложность с кешированием, отладка запросов, которые клиент сформировал сам.

Кому смотреть: backend-разработчикам, у которых REST API начинает «расти вширь» под давлением разных клиентов, и тем, кто думает о GraphQL, но хочет услышать не маркетинг, а реальный опыт внедрения.

Из этого можно взять в работу: посчитайте, сколько полей в ответе вашего самого нагруженного эндпоинта реально используется мобильным клиентом. Если меньше трети — у вас есть over-fetching, и это стоит трафика, памяти и CPU прямо сейчас.

Автор: Listen IT · Listen IT

Видео Listen IT, 7 минут. BFF (Backend-for-Frontend) и API Gateway — два паттерна, которые часто упоминают вместе и так же часто смешивают в один. Это разные решения разных проблем.

API Gateway — единая точка входа для всех клиентов: аутентификация, rate limiting, роутинг запросов к нужным сервисам. Он не знает о специфике клиента — будь то мобильное приложение, веб или сторонний партнёр, все получают одинаковый интерфейс. BFF — другое: отдельный backend, специально заточенный под нужды конкретного типа клиента. Мобильному приложению нужны агрегированные данные в компактном формате, чтобы не делать десять запросов там, где один. Веб-интерфейсу нужны другие данные в другой структуре. BFF решает это не изменением общего API, а созданием специализированного слоя для каждого клиента. Разделение полезное — пока не начинаешь дублировать логику между BFF для web и BFF для mobile.

Кому смотреть: разработчикам и архитекторам, проектирующим API для нескольких типов клиентов — мобильного приложения, веба, внешних партнёров — и чувствующим, что один общий backend начинает проигрывать в гибкости.

Из этого можно взять в работу: посмотрите на ваш API и спросите: сколько данных, которые возвращает один эндпоинт, реально используется мобильным клиентом? Если меньше половины — это сигнал, что клиент переплачивает за лишний трафик и обработку.

Автор: Максим Денушев (Точка) · Golang Channel

Максим Денушев работает в банке Точка. Доклад с GolangConf 2024, 31 минута. API Gateway — компонент, через который проходит весь трафик платформы. Переписать его — значит заменить двигатель у летящего самолёта: система должна оставаться доступной, а пользователи не должны заметить, что что-то происходит.

Главная сложность такой задачи не техническая, а операционная. Выбрать новый стек и написать код — это меньшая часть работы. Настоящий вызов — как организовать переход так, чтобы в каждый момент времени система работала корректно для всех клиентов. Денушев разбирает подход, который команда применила: постепенное перемещение трафика через новый Gateway параллельно со старым, профилирование под реальной нагрузкой, работа с проблемами обратной совместимости, которые обнаруживаются только когда через систему идут реальные данные. Это не история успеха без шрамов — доклад честный о том, с какими проблемами они столкнулись и что их не предусмотрели заранее.

Кому смотреть: backend-инженерам и архитекторам, которые стоят перед задачей замены критического инфраструктурного компонента — не только Gateway, но и любого, через который проходит весь трафик.

Из этого можно взять в работу: если вы планируете значительное изменение инфраструктурного компонента — составьте список всего, что через него проходит, и определите, какие клиенты заметят изменение первыми. Это первый шаг к плану миграции, который не ломает продакшн.

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. C4 — архитектурная нотация, созданная Саймоном Брауном как ответ на две типичные проблемы: диаграммы, которые непонятны никому кроме их автора, и схемы, которые устаревают быстрее, чем успевают быть прочитанными.

Большинство архитектурных диаграмм страдают одним и тем же пороком: непонятно, для кого они нарисованы. Схема, адресованная топ-менеджменту, содержит детали реализации, интересные только разработчикам. Схема для разработчиков — слишком крупная, чтобы из неё понять что-то конкретное. C4 решает это через явную иерархию четырёх уровней: Context (система и её окружение для нетехнической аудитории), Container (приложения и базы данных, из которых состоит система), Component (модули внутри одного контейнера) и Code (диаграммы классов, нужны редко). Каждый уровень отвечает на разный вопрос и адресован разной аудитории — и это не абстрактная теория, а конкретный инструмент против диаграмм, которые не читает никто.

Кому смотреть: разработчикам и техлидам, которым нужно объяснять архитектуру коллегам с разным уровнем технической подготовки — и всем, кто хочет перестать рисовать схемы “для галочки”.

Из этого можно взять в работу: нарисуйте C4 Context-диаграмму вашей системы — один прямоугольник в центре, несколько снаружи. Если не можете объяснить за пять минут нетехническому коллеге, что происходит на этой схеме — схема не работает. C4 Context — именно для этой цели.

Автор: Владислав Танков · Podlodka Podcast

Владислав Танков — директор по AI в JetBrains. Это второй его выпуск на Podlodka (#452): первый (#444) был про внутреннее устройство LLM на уровне трансформеров и аттеншенов. Этот — про то, что происходит, когда модель нужно не просто запустить, а запустить в продакшне под реальной нагрузкой.

Большинство разговоров про LLM в продакшне сводятся к «берём OpenAI API и готово». Танков рассказывает про другой класс задач: когда API не подходит — из-за данных, задержки, стоимости или политики безопасности — и нужно думать об инфраструктуре самому. Локальный инференс vs облачный — это не просто вопрос цены, это вопрос контроля над latency, privacy и зависимостью от внешнего провайдера. В JetBrains этот выбор делается для каждого продукта отдельно, и критерии нетривиальны.

Кому смотреть: инженерам и архитекторам, которые строят или планируют строить продукты поверх LLM и хотят понять инфраструктурную сторону вопроса — не теорию трансформеров, а что конкретно потребляет память, откуда берётся latency и где узкое место при масштабировании.

Из этого можно взять в работу: если вы сейчас используете LLM только через API — составьте список требований к задержке, приватности данных и стоимости для вашего конкретного use case. Это займёт час, но может изменить архитектурное решение.

Автор: Александр Данковцев · HighLoad++

Александр Данковцев — Lead Engineer команды Antimonolith в Авито. Команда занимается тем, что помогает сотням сервисов взаимодействовать друг с другом не хаотично, а по правилам. Доклад с HighLoad++ 2024 — про API Gateway как ключевой элемент этой архитектуры.

API Gateway — одно из тех решений, которые выглядят просто («просто обратный прокси с маршрутизацией»), пока вы не начинаете масштабировать. В Авито тысячи микросервисов, сотни команд и постоянно меняющиеся API. Данковцев рассказывает, как Gateway эволюционировал от простого роутера до полноценного инфраструктурного продукта: с собственным языком конфигурации, валидацией, rate limiting, auth-интеграцией и observability. Ключевая мысль: когда Gateway становится платформой, а не конфигом nginx, он начинает требовать того же инженерного внимания, что и любой другой продукт — владельца, versioning, обратной совместимости.

Кому смотреть: архитекторам и техлидам, которые строят или унаследовали API Gateway в системе с более чем десятком сервисов — особенно тем, у кого роутинг пока «просто конфиг».

Из этого можно взять в работу: посмотрите на ваш текущий API Gateway как на продукт: есть ли у него владелец, changelog, способ добавить новый маршрут без ручного merge конфига? Если нет — вы уже несёте технический долг, который растёт с каждым новым сервисом.

Автор: Александр Алексеев · Папочка Разработки

Александр Алексеев ведёт канал о .NET-разработке, где объясняет архитектурные концепции без академической перегруженности. Это видео — один из лучших русскоязычных входных точек в DDD: без Эванса на 500 страниц, но с сохранением сути.

Domain-Driven Design принято считать сложным — и чаще всего путают причину сложности. Дело не в паттернах: агрегаты, репозитории, value objects можно выучить за вечер. Настоящая сложность DDD в другом: он требует, чтобы разработчики говорили на одном языке с теми, кто понимает предметную область. Без этого единого языка — Ubiquitous Language в терминах Эванса — код отражает не бизнес-логику, а то, как разработчик её понял. В больших системах этот разрыв со временем становится главным источником багов и рефакторингов.

Александр разбирает, почему DDD особенно важен именно для сложных, долгоживущих систем и почему его не стоит тащить в простые CRUD-приложения — это отдельный тезис, который стоит услышать до того, как начинать внедрение.

Кому смотреть: backend-разработчикам, которые слышали про DDD, видели аббревиатуру в вакансиях, но не понимают, зачем это нужно и когда это оправдано.

Из этого можно взять в работу: возьми любую сущность в своём коде — например, Order. Спроси себя: это слово означает одно и то же для разработчика, менеджера и бухгалтера? Если нет — у вас нет Ubiquitous Language, и DDD пока не начинался.

Автор: Сергей Константинов · SDCast

Сергей Константинов написал книгу «The API» — бесплатную, в открытом доступе, на русском и английском. До этого разрабатывал API в Яндекс.Картах. В подкасте разбирает то, что в этой теме обычно остаётся за кадром обычных туториалов.

Центральная идея, которую Константинов проводит через всю книгу: закон больших чисел работает против автора API. Если концепцию или сигнатуру вызова можно понять неправильно — её неизбежно будут понимать неправильно всё больше людей по мере роста популярности API. Поэтому нейминг в публичном API — это не вопрос стиля и не задача code review. Это архитектурное решение: каждое имя, вышедшее наружу, становится обязательством.

Отсюда — его подход к проектированию через пирамиду контекстов. Сначала — зачем вообще нужен этот API, какую задачу он решает. Потом — абстракции и ответственность сущностей. И только в конце — конкретная номенклатура. Потому что цена ошибки на разных уровнях сильно отличается: «если исправить плохое именование сравнительно просто, то исправить неверное понимание того, зачем вообще нужен API, практически невозможно».

Отдельная тема — роль архитектора. Константинов прямо говорит: самая большая проблема в развитии API — отсутствие у руководителей продукта экспертизы в этой области. Кто-то должен владеть дизайном API целиком: не отдельными эндпоинтами, а всей системой контрактов — и этот человек должен думать как архитектор, а не как разработчик фичи.

Кому смотреть: разработчикам и архитекторам, которые проектируют публичные или платформенные API. Тем, кто принимает решения о версионировании. Тем, в чьей команде нет явного ответа на вопрос «кто отвечает за консистентность API целиком».

Из этого можно взять в работу: прежде чем назвать новый эндпоинт или поле — спроси, можно ли понять это имя неправильно. Если можно — его поймут неправильно. Это не паранойя, это математика.