#архитектура

В прошлом году мы запустили кейс-клуб, где регулярно собираемся и предаемся System Design’у здорового человека.

Что делаем:

• Разбираем реальные задачи из жизни, а не Key-Value Storage, URL Shortener и прочую дичь, которую вы никогда не будете пилить в реальной жизни

• Учимся использовать архитектурные паттерны и технологии там, где они действительно уместны

• Увеличиваем техническую насмотренность за счет кейсов из разных индустрий: финтех, ecomm, телеком и другие

Примеры кейсов:
- выпуск и доставка банковской карты
- история покупок и быстрый заказ на маркетплейсе
- программа лояльности в экосистеме

Ближайшая встреча в воскресенье, будет кейс три в одном: A/B-тесты, feature toggling, таргетированная реклама - все в одной архитектуре.

Ждем всех, кто хочет начать осознанно проектировать, а не судорожно вспоминать главы Хью на каждом проекте и собесе, заходите.

Прекрасное рядом. До истории с /getClientInfo не дотягивает, но тоже хорошо.

Интересно, а с кэшированием у них нет проблем?

Модели потребления сообщений
- Чем топики отличаются от очередей?
- Если кратко - это разные модели потребления

Что такое модели потребления?
Здесь сложнее, т.к. это понятие не слишком популярно в индустрии. В данном контексте модель потребления - это логика работы брокера при передаче сообщения потребителю.

Мой вариант классификации, который подробно разбираю на вебинаре:
• Queue
• Pub-Sub
• Log

Модели определяет два признака:
• Сколько потребителей может прочитать одно сообщение
• Что происходит с сообщением после прочтения

Часто выделяют две модели вместо трех: queue-based, log-based - т.е. объединяют модели Queue и Pub-Sub. Мне эта версия кажется менее наглядной, но тоже хорошо подходит для осмысления вопроса. Можно познакомиться в статье или послушать подкаст о брокерах.

А топиками могут называть что угодно: как модель очереди в реббите, так и реализацию лога в кафке.

#брокеры #интеграция

В душе я немного китаец, поэтому оставлю авторитетный прогноз на год грядущий.

Ближайшие 2-3 года особым успехом будут пользоваться астрологи, тарологи, биоэнергетики - в серьезные кризисы люди обращаются к эзотерике.

Немного перепадет карьерным консультантам, коучам, психотерапевтам - за счет итшечки и около.

Не упусти свой шанс

#ненависть #оффтоп

Глядя на околообразование, все больше прихожу к мысли, что лицензировать нужно не школы и программы, а преподавателей и авторов. Чтобы как с адвокатом или хирургом - нет лицензии, не подходи к людям. И какую-нибудь Клятву Аристотеля придумать.

Кто ждал запись - вот она

#API

В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.

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

Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.

Классная мини книга про вебсокеты.

• История и проблематика
• Детали работы протокола
• Масштабирование и отказоустойчивость

#интеграция

#интеграция #архитектура

На фоне стабильной тенденции к переходу из аналитиков в архитектуру не менее стабильно возникает вопрос: “А как это делать вообще?”

Есть минимум два варианта:

— закопаться в книгах по архитектуре и штурмовать вакансии архитектора

— понять, что уже есть для нужной роли, и постепенно двигаться к ней, отбирая у кого-нибудь подходящие задачи

Я уже старый и ленивый, поэтому предпочитаю эволюцию. Допустим, есть богатый опыт в проектировании интеграций. Логично начать наращивать на него дополнительные скиллы, расширяя спектр задач.

Сначала копнем в работу сетей и инфры, чтобы понять влияние на выбор технологий. Здесь же разберемся, как и почему работает балансировка. Дальше начинаем думать о надежности, и учимся использовать circuit breaker’ы, адаптивные ретраи и другие паттерны отказоустойчивости. Где-то рядом придется задуматься о производительности и кэшировании, а там и выборе технологии под кэш. А потом потребуют развесистый бизнес-процесс реализовать на несколько сервисов, и вот вам проектирование распределенной системы с транзакциями.

Таким образом получаем трек: локальные интеграции -> интеграционная архитектура -> полноценный сисдизайн. Останется еще с хранилищами попрактиковаться.

По этой логике мы проектировали курс интеграция и архитектура в распределенных системах. Вместе пройдем путь от уверенной работы с API, до проектирования сложной интеграционной архитектуры в распределенных системах.
Первый поток зашел на удивление хорошо, некоторые успели даже собесы пройти в процессе.

#интеграция

Я не раз писал, что для осмысленных рассуждений о выборе технологии интеграции нужно минимальное понимание сетей и инфры, которая лежит под знакомыми рестами и соапами. Поэтому решил сделать стрим на эту тему. Вторник 25.02, вечер, заходите.

Рега тут

Эти выхи буду на WAW. Кто еще там? Го чай пить и знакомиться.
А завтра утром веду воркшоп по сисдизайну - заходите, чтобы посмотреть, чем мы в нашей архсекте занимаемся.

Выложили запись собеса сисаналитика в Т-Банке. Наверное, лучший из всех, что видел на ютубе.

Очень продуманы задания и вопросы, отлично подготовлены материалы, максимально конструктивное и экологичное общение со стороны интервьюера. Общение происходит на примере сквозного кейса, а не очередных 100 вопросов для собеса.

Категорически рекомендую как нанимающим лидам, так и кандидатам.

У меня лишь один вопрос остался: если вот это все делает аналитик, то чем вообще занимается разработка?

WAW 2025

На выхах добрался до WAW, который оставил неожиданно приятные впечатления. За счет небольших размеров получилось очень лампово и душевно, было время обсудить интересное. Только 1,5 дня мало((

Выделялись три основных темы: сисдизайн, лидерско-манагерское, AI. Трек сисдизайна получился особо удачно, спасибо Ане Вичуговой, Зое Степчевой и скромному мне. Надеюсь, никого не упустил?

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

Я же делал воркшоп по сисдизайну, где разбирали кейс доставки карты в сокращенном виде. Прошло бодро и активно, 5 из 6 команд дошли до конца, все довели решение до рабочей версии.

Несколько закономерностей, которые заметил еще в рамках нашего кейс-клуба:

Реализация НФТ
Характерное поведение аналитика: определить требования к нагрузке, доступности, масштабированию… и забыть про них. Не происходит валидации, как мы реализовали требования на уровне архитектуры, основное внимание уделяется бизнес сценариям. Не надо так;)

Легаси системы
Когда мы используем существующий ландшафт (т.е. почти всегда), нужно не забыть про характеристики и ограничения легаси систем. Иначе весь наш хайлоад рассыпется на какой-нибудь вендорской коробке.

Масштабирование
Нагруженные сервисы, стоит запускать в нескольких экземплярах. Если нет данных, чтобы оценить нагрузку и ресурсы, можно начинать с двух в качестве дефолтного варианта. Дальше будем смотреть, сколько нужно добавить. Ну и не забыть о балансировке.

На другие секции удалось только мельком заглянуть, ничего конкретного не скажу.
Спасибо оргам и всем участникам за конфу, встретимся через год ❤‍🔥

#конференции

Отправка событий от бека к фронту

Лень монтажить вебинар, пока вынесу с него интересный вопрос:

- Если WebSockets, HTTP/2, SSE позволяют слать сообщения с бека на фронт, то почему в основном говорят о WebSockets для двухстороннего взаимодействия?

Server Sent Events
Чтобы получать события с сервера клиент кидает GET-запрос с указанием в заголовках, что хочет сохранить соединение и получать события. Если сервер так умеет, то создается длительное соединение, и он начинает слать сообщения клиенту, пока кто-нибудь соединение не закроет.
Работает SSE поверх HTTP/1.1 и выше.

Позволяет слать события только в одну сторону: сервер —> клиент.
Прост в реализации, не нужно затаскивать в проект новый протокол и тулинг под него, кто-то считает устаревшим.

Если честно, я даже не знаком с людьми, которые использовали SSE. Нашел пару примеров:
⁃ В SuperJob их юзают просто чтобы не заморачиваться, как я понял.
⁃ Тут их используют для реализации subnoscriptions в GraphQL. Ну ок, есть логика

У вас был такой опыт? Поделитесь в комментах, плз.

HTTP/2
Взаимодействия между клиентам и сервером делятся на стримы. Каждый стрим состоит из одного request-сообщения и одного response-сообщения. Каждое сообщение может состоять из одного и более фреймов.

Причем сервер может начать слать фреймы ответа до того, как получил от клиента все фреймы ответа. Причем количество фреймов неограничено, и я необязан указывать его в первом фрейме сообщений. Такой вот стримминг внутри стрима получается. Внезапно, правда?

Получается, что внутри стрима мы можем слать фреймы в двух направлениях. НО - создать стрим может только клиент. Т.е. парадигма request-response в протоколе сохраняется.

В теории так сделать можно, но разрабы нас за это сожгут, так мы предлагаем ручками лезть в потроха протокола. Так можно и сразу с TCP напрямую работать. Или кто-нибудь знает готовые либы под это?

На практике проще сразу брать gRPC, который использует эту механику. Но это новый стек, новые проблемы.
Либо заюзать те же SSE.

Почитать: Хардкорный разбор HTTP/2

WebSockets
Полнодуплексный протокол, в котором мы устанавливаем соединение, клиент кидает GET запрос с нужными заголовками и вместе с сервером переключается на общение поверх вебсокетов. Клиент и сервер могут в произвольном порядке слать друг другу сообщения, пока кто-нибудь не закроет соединение
Работает поверх TCP.

Позволяет слать события только в обе стороны: сервер <—> клиент.
Сложнее в реализации, чем SSE, т.к. многие не умеют его готовить, нужно затаскивать новый протокол и тулинг в проект.

Почитать: основы вебсокетов, мини книга с погружением.

Вместо итогов
Для отрисовки курьера на карте или обновления курса валюты, пока пользователь не ушел с экрана, хватит SSE.
Если делаете риалтайм борду или чат, где события постоянно летят в обе стороны - проще с вебсокетами.

#интеграция

#манагерское

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

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

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

Как предприниматель (у мен одного ощущение, что слово “бизнесмен” сейчас воспринимают как пошлый атавизм из 90х?) в гробу я видал всю эту вашу итшечку и смузи-фичи. Каждое утро я просыпаюсь и думаю, как бы вообще ничего не делать и побольше заработать. Вчера продал пару новых проектов крупным партнерам и собрал концепт нового стратегического направления. Нужно быстро запустить все за пару недель, максимум месяц. В смысле, какой проект важнее? Все важно, они издеваются что ли?! Даже сроки внятные назвать не могут.

Ну и что?
Чтобы заниматься наиболее интересными для себя вещами, придется понять и принять интересы других. И будет это ой как непросто. А задача манагера на разных уровнях - развивать это принятие и понимание в обе стороны.

#архитектура

Есть академические штуки, о которых много говорят, но непонятно, как их применять на практике.

Например, CAP-PACELC теорема. Она рассматривает синхронизацию между нодами хранилища и задает нам два простых вопроса:

— Если сбой, что важнее: консистентость или доступность?

— Если штатно, что важнее: консистентность или скорость отклика?

Круто, и что мне с этим делать? Я архитектуру кафки и постгри проектировать не собираюсь. Чтобы кто-то садился и задавался вопросом: “Какую же модель мне выбрать для сервиса заявок: CP или AP??” - тоже никогда не встречал. Тогда зачем мне это кроме шаблонных собесов?

А если посмотреть шире?
Наш сервис-система-компания - это миллионы-миллиарды объектов, которые постоянно меняют свое состояние. Меняют в рамках определенных правил, ограничений, процессов, которые ведут к бизнес-цели. Фактически, мы занимаемся непрерывной синхронизацией состояний этих объектов.

Но что мы синхронизируем? Не только реплики хранилища или инстансы сервиса, мы точно так же синхронизируем состояние платежа между процессингом заказов, платежным сервисом и бухгалтерской системой. Даже с реальным миром синхронизируемся, когда говорим о состоянии заказа - курьер доставил его физически или нет?

Есть пара: процессинг заказов и платежный сервис, что критичнее
— консистетность или доступность?
— консистентность или время отклика?

А для пары процессинг заказов и бухгалтерия?

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

Получается, с самой верхней абстракции курьер-заказ до простенького ретрая мы постоянно думаем о согласованности, вокруг которой крутятся CAP-PACELC теоремы. Вот и бесполезный академизм на практике.

Часто фундаментальные концепции из computer science не дают конкретные рекомендации для локальных задач, но позволяют расширить сознание, чтобы более системно и целостно подходить к проектированию.

#архитектура

Выложили записи докладов с ArchDays’2024.

Был живьем, но большую часть времени провел на архкате. Буду теперь досматривать.