Пятничное чтиво

Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.

—————————————


Who Does What? Team Topologies for the Agentic Platform

Когда начали появляться «роли» агентов, задумался о том, сколько времени понадобиться, что бы на агентов начали натягивать идеи из team topology. Прошло меньше года и сегодняшняя статья как раз об этом. Сразу скажу: не уверен, что идея взлетит, но забавно, что рандомные предположения начинают сбываться.

Начинается текст с мысли, что в агентской разработке когнитивная нагрузка стала меньшей проблемой чем пропускная способность. Поэтому авторы решили взять TT для ответа на вопрос: как распределять нагрузку и ее «поглощать». Из ТТ сохраняются виды команд, подход «X as a service» и управлению когнитивной нагрузкой (которая становится показателем производительности). Далее рассказывается что каждая из четырех видов команд делать будет. Так stream-aligned предлагается отдать управление оркестратором ллм и управлением контекста с точки зрения бизнеса. Платформенные команды делают глобальный контекст, занимаются безопасностью, тулами для агентов. Enabling Teams занимаются средой для агентов, обучают работе с агентами и занимаются «ручной» валидацией/верификацией. Далее в тексте описывается как такой подход может быть реализован и как ответственность разделяется между командами.

#team_topology #llm

—————————————

Как мы научили реляционную базу хранить оргструктуру в виде графа на 500к пользователей

2 года назад написал ответ на вопрос, как хранить граф не в графовой бд. Сегодня текст от яндекса, где показано, как хранить оргструктуру (граф) в реляционной бд.

Начинается текст с проблемы: существует «Яндекс 360», который отвечает за ЖЦ организации. Продукт хранит оргструктуру с которой необходимо работать (например, делать рассылку на всех бухгалтеров или узнавать к какому отделу принадлежит сотрудник). Тут включается граф, потому что подразделение — классическое дерево, а орг группы — DAG. А в сумме получаем граф. Изначально хранение оргструктуры сделали в виде набора таблиц, но из-за новых требований (вложенность и размер), в компании решили переехать на графы. Далее инженеры решили посмотреть, как в других отделах (картах, диске) хранят графы, плюс рассмотрели еще 5 вариантов (Adjacency List, Materialized Paths, Nested Sets, Graph Table и Closure Table). Варианты тестировали в экспериментах и по итогу выбрали Closure Table с отличием в хранении путей. В конце описывается, как решение катилось в прод и почему сразу не выбрали графовую бд.

#graphs

—————————————

Event-Driven Patterns for Cloud-Native Banking

Еще один текст о event-driven коммуникациях. Ключевое отличие от статей с медиума — автор рассказывает о том, как в банкинге использовать паттерны. Текст начинается с объяснения что такое событие и чем событие отличается от команды. Далее переход на банковский домен. Тут появляются ограничения в виде регуляторики и работы с деньгами. После описывается, почему event-driven ложится в реализацию работы с денег, через разделение шагов в платежном коде. Потом рассказывается о проблемах, которые могут возникнуть: люди (точнее мышление людей), обучение, отсутствие инструментов, потеря событий и контракты.

Русский перевод

#how_it_works #event_driven