Yet Another Burakov

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

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

Что делаем:

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

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

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

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

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

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

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

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

The way that consumer groups assign partitions to members of the group gives a powerful combination of ordering and scalability, but it does introduce coupling between the number of consumers in a consumer group and the number of partitions. Users of Kafka often have to “over-partition” simply to ensure they can have sufficient parallel consumption to cope with peak loads.

...

This KIP introduces the concept of a share group as a way of enabling cooperative consumption using Kafka topics. It does not add the concept of a “queue” to Kafka per se, but rather that introduces cooperative consumption to accommodate these queuing use-cases using regular Kafka topics. Share groups make this possible. You can think of a share group as roughly equivalent to a “durable shared subscription” in existing systems.

This is indeed Queues for Kafka - queues done in a Kafka way, with no maximum queue depth and the ability to reset to a specific time for point-in-time recovery.

Don’t try to quit REST

Завтра вещаю на вебинаре, чтобы в очередной (третий) раз окончательно закрыть тему REST API. Наверное, это персональное проклятье. Вспомним, как появилась концепция, под какие задачи, и почему ее актуальность в 2025 стремится к нулю.

Приходите похоливарить, рега тут

#интеграция

Ничего мы вам не гарантировали

Меня умиляют истории, как кто-то в очередной раз сделал надежную exactly once доставку с помощью XXX и YYY. Обычно это либо оголтелый маркетинг, либо техническая наивность.

Существует ровно два гендера гарантии доставки:
• at most once
• at least once

Все, третьего не дано.
Вы не реализуете exactly once доставку, потому что это фундаментальное ограничение мира, такое же как вечный двигатель или перемещение материи свыше скорости света. За доказательством рекомендую обратиться к задаче двух генералов - она во многих задачах IT проявляется, пусть и неявно.

Тогда что такое exactly once?
Это гарантия обработки. Если говорить просто, то это at least once доставка, где каждое взаимодействие обвешано ретраями и идемпотентностью. Единственный способ обработать сообщение строго один раз - это любой ценой донести его до получателя, а потом уже отсеять дубликаты.

Потому нам нужны transactional in/out-boxы - чтобы корректно донести сообщение до брокера, и строго один раз обработать его на консьюмере. И все это поверх at least once гарантии доставки.

Про аутбоксы можно почитать тут.

А здесь хардкорно про устройство брокеров, и как устроена запись-чтение сообщений.

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

Все, хватит салатов, просыпаемся.

Детальный разбор реализации Transactional Outbox, когда у тебя постгря с кафкой. Варианты реализации, проблемы, инструменты - просто и понятно. Отдельно можно скачать презу.

Здесь можно подробнее почитать, зачем нужны все эти аутбоксы, и что это такое.

С Рождеством и добро пожаловать в 2025!

Терпения и спокойствия всем нам 🎇

#оффтоп #манагерское

Внезапно осознал, что в около-образовании уже 6 лет. Началось все с обучения для аналитиков внутри компании, потом вел и делал курс по интеграциям в com-practice, теперь занимаюсь своей школой. А появилась она довольно забавно.

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

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

- Не нуачо? Раз народ сказал, надо идти делать

Так появился ArchWays. Потом решили объединиться с Аней, и он трансформировался в NextWay. Мораль я не придумал, но если вы узнали себя в это истории - спасибо за веру и чудесную возможность))

Ну что, пора вылезать из салатов?

В прошлом году мы запустили Клуб Проектирования NextWay, чтобы вместе качать архитектурные скиллы 🎓💪
Никита Ерилин, эксперт клуба, поделился полезным-архитектурным, чтобы почитать под мандаринки.

System Design Primer
Хорошая краткая выжимка по многим моментам и понятиям, используемым в системном дизайне. Сфокусировано на собеседованиях, но в качестве знакомства с основами или справочника подходит неплохо. Единственное - не заучивайте примеры, а постарайтесь докопаться до мотивации того, почему они предлагают сделать именно так.

Design It! From Programmer to Software Architect
Все еще лучшая книга для погружения в архитектурные практики от Майкла Килинга. Она больше заточена под разработчиков, поэтому там довольно много разжевываний вещей, которые могут показаться банальными, вроде: "Не придумывай требование, спроси ртом у заказчика" - но там есть много разных методик по работе со стейкхолдерами. В рамках собеса такое вред ли пригодится, но в работе поможет.

Книга с кабанчиком
Бессмертная классика от Мартина Клепмана. Может показаться сложной из-за обилия технических подробностей, но ее структура позволяет провернуть один лайфхак: как только вы чувствуете, что глава становится слишком сложной, и вы не понимаете технических деталей – переходите к следующей, они все идут по принципу "от простого к сложному”. Даже если вы по верхам пробежите все главы, получите много пищи для дальнейших размышлений.

Microservices.io
Большая подборка микросервисных паттернов Криса Ричардсона. Самый полезный раздел, на мой взгляд: "Transactional messaging".

@nextway_news

#книжное #оффтоп

А в 2023 открытием года стала Гарри Поттер и методы рационального мышления от Элиезера Юдковского. Точнее приоткрытием, т.к. некоторые главы читал раньше, но сначала не зацепило.

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

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

Книга свободно доступна в онлайне, но есть и печатные издания, если больше нравится.

#книжное #оффтоп

Биология добра и зла Роберта Сапольски стала для меня открытием 2024 года. Безумно интересно и доступно о том, как устроен человек, что определяет его поведение.

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

Например, внутри можно найти:

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

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

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

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

За каникулы прочитать вряд ли получится, но оно того стоит. Если совсем лень, то у Сапольски много лекций и интервью в сети - там тоже много интересного.

А еще очень качественно и приятно печатное издание сделали, с двумя закладочками.

Channel name was changed to «Yet Another Analyst»

#интеграция
Вот такая шикарная инфографика от Юрия Куприянова. Не со всем согласен, мои комменты тут.

Полезая штука, но как всегда буду душнить: пожалуйста, никогда (прописью: никогда) не принимайте боевые решения на основе таких таблиц / критериев / алогритмов - они никогда не будут отражать всех нюансов. А какие нюансы важны в вашем контексте, знаете только вы.

Тогда в чем польза? Систематизировать знания, сверить картину мира, если что-то кажется странным - погуглить и узнать что-то новое.

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

Собирайте грибы, а не требования

Если лень читать:
1. Требований не существует
2. Задача аналитика - не собрать требования

В холиварах на тему “нужен ли аналитик?” часто слышу аргумент: “Задача по сбору требований остается, просто без аналитика ее вешают на другую роль”.

В этом высказывании есть ряд неявных допущений:

1. Существуют некоторые объективные “требования”
2. Существуют люди, которым “требования” известны - стейкхолдеры
3. С помощью особых техник можно собрать все “требования” у стейкхолдеров
4. Если реализовать “требования”, то мы получим результат, который нужен бизнесу

Все хорошо, но есть нюанс: эти допущения выполняются разве что в заказной разработке:

1. Требования - хотелки заказчика
2. Стейкхолдеры - сотрудники заказчика
3. Аналитики записывают хотелки заказчика, мы прикладываем их к договору
4. Реализуем хотелки, получаем деньги - профит

И то при особо злостном следовании “требованиям” заказчик может отказаться принимать работу или отправить нас в блеклист после сдачи проекта.

Когда мы пилим продукт, в роли “требований” могут выступать разве что ограничения регулятора и законы физики. Никаких “правильных требований”, которые можно "собрать", здесь нет. Как и нет людей, которые точно знают, что делать - мы оперируем гипотезами, исследованиями, данными разной степени достоверности.

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

А если без аналитика никак, то почему? Хотим работать по принципу: “Что нам сказали, то и делаем”?

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

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

• Надежность взаимодействий: время отклика, таймайуты, хелсчеки - и как это считать реальными числами

• Проблемы взаимодействий поверх брокеров

• Согласованность и управление транзакциями

Рекомендуется к просмотру перед изучением статьи о способах обеспечения отказоустойчивости при синхронных взаимодействиях.

#оффтоп
Сисдизайн секция здорового человека:

- Вам нужно спроектировать Key-Value хранилище
- Зачем?
- ...
- Спасибо, я не перезвоню

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

Хорошо написано (оригинал):

В психологическом противостоянии заказчика и исполнителя в заказной разработке я вижу две корневых причины: несовпадение меры ответственности и меры определённости.

На заказчике всегда больше ответственности. Если команда разработки что-то не автоматизировала, в конце рабочего дня они встанут и пойдут домой, а заказчик будет делать свою работу в ночи вручную
…

При разработке продукта тоже часто возникает проблема с восприятием неопределенности, но наоборот - грустит разработка

#оффтоп #манагерское

Как интересно работает мозг. Существует 100500 методик, как эффективно давать фидбек. Многие сходятся на том, что в него обязательно нужно включать позитивные тезисы.

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

Периодически слышу конструкции вида: “ты классно сделал ХХХ”, “здорово, что ты YYY”, “в целом все хорошо” - а дальше следует содержательная часть что человека не устраивает.

В такие моменты слушаю и думаю: “Давай уже пропустим эту херню и перейдем к делу. Захочу узнать о хорошем - спрошу прямо”. А человек же старается как лучше.

Очевидно, есть другие люди, с таким же восприятием.

Очевидно, есть люди, которых прямая подача демотивирует.

И дай мне мудрость отличить одних от других

Тут всех приглашают поучаствовать в архитектурной кате. Онлайн, бесплатно.

Отличный вариант добрать опыта проектирования - зачем упускать?

📅 5 декабря, четверг, 19:00 мск

#оффтоп

Пока искал фотку с конфы...

Други, кто-нибудь обитает сейчас на Пхукете? Давайте соберемся на чаек.

Недостающие звенья кэширования

Статья, которую можно использовать для первого знакомства с темой.

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

Дополнил исходный пост, забирайте его полностью.

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