2pegramming

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

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

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

AI Doesn't Fix Your Real Bottleneck

Часто вижу истории истории о том, как ллм ускоряет TTM компании в десятки раз. Помня о теории ограничений и очередях, каждый раз интересно разобраться в деталях такого ускорения (и реальное ли ускорение ттм на самом деле). Поэтому сегодня статья от автора learning DDD, в которой автор задается похожим вопросом.

Начинается текст с кратким объяснением теории ограничения. Т.е. ускоряя «узкое» место процесса — ускоряем процесс целиком. Ускоряя другое место — делаем хуже (появляются очереди и увеличиваются запасы). Дальше, автор, задается вопросом, а что за «узкое» место в SDLC и делает предположение, что не написание кода, а понимание кода, который изменяется. Далее мыль приходит к тому, что чем больше кода пишется, тем больше страдает понимание существующего кода. А как решение, автор предлагает посмотреть в сторону модульности (и сложности) и связей между элементами системы. Ну и в конце найдете рекламу balancing coupling, как способе работы с модульностью.

#SDLC #llm

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

Choose Boring Technology

Может показаться, что работа над архитектурой и принятие решений по технологиям строится вокруг построения звездолетов и новых технологий. На деле, в реальности, выбор сводится к безопасным решениям, которые на деле скучны. А что-то «не скучное» выбирается только когда проверенные решения не справляются. Поэтому сегодня рубрика «интернет археология». Статье больше 11 лет и главная мысль текста — выбирайте проверенные технологии.

Текст начинается с определения «скучной» технологии. При этом, скучное =/= «плохое», так есть «хорошие» скучные технологии (постгрес, как пример). Для автора это изученная технология, особенно причины отказа. Т.е. автор приводит к «известному неизвестному» и «неизвестному неизвестному». Далее автор подводит к тому, что основная цель software — сопоставить бизнес проблему с техническим решением. И что термин «лучший» инструмент для работы — трактуется по разному. Ну и в конце найдете, когда стоит выбирать новые технологии.

#decision_making

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

The Cost of Cognitive Debt

Еще одна статья о проблемах в процессах, где используют ллм и «неизвестное неизвестное» (и модульность как решение). Так вышло случайно, правда. Если Влад говорил о модульности как решении проблемы, то в статье выше, автор приводит термин «когнитивный долг». Долг связан с ухудшением понимания системы. А для измерения долга предлагается использовать метрику Cost of Cognitive Debt.

Начинается текст с того, что когнитивный долг не выдумка автора. В 1985 году Peter Naur писал о том, что в разработке, кроме кода, есть еще «теория» в головах людей, которые писали код. И без этой «теории» теряются причины возникновения кода. А в с нейронками, такой причины изначально может не быть. Далее, идут рассуждения о том, как оценивать «понимание». Для этого предлагается матрица «когнитивная сложность» и «серьезность» (в плане влияния на бизнес). Ну и в конце, как возвращать когнитивный долг.

#SDLC #tech_debt

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

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

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

Как защитить платежный API от двойных списаний с помощью идемпотентности

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

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

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

#communications #idempotency

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

Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы

Рубрика «интернет археология» в канале. По ссылке выше — пост 12 летней давности (2014 год), в которой автор описывает собственное представление легаси и как с ним работать. Предвосхищая вопрос «а зачем об этом думать, когда нейронкам это не надо?»: в тексте есть секция с анализом, который может сделать нейронка. Но вот знать что именно анализировать и зачем — тут нейронка не поможет.

Сам текст состоит из 4 частей: определение легаси, риски легаси, анализ и что с легаси делать (и как). В определении легаси пункты очевидны (отстутвие документации, тестов, старые технологии, код «плохой»). Также описаны 4 варианта появления легаси. В рисках описывается что не так может пойти с легаси (ттм, который ниже требуемого, потеря денег и так далее). В секции анализа, автор, предлагает задать 10 вопросов о технической составляющей системы, по которым можно сказать на сколько система поддерживаема. В последней части предлагается четыре способа взаимодействия с легаси (оставить, переписать с нуля и два подхода модульного переписывания. В конце найдете список литературы.

#modernization #legacy

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

Systems Thinking in Accident Investigations

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

Вообще, текст строится вокруг расследования инцидента, произошедшего во время Alaska Airlines Flight 1282 рейса. На высоте 4.5 км произошла разгерметизация, в результате чего, дверь в середине корпуса «вылетела». Причина оказалась в том, что забыли установить 4 болта, но ценность текста не в причине, а в том, как люди думали «почему это произошло». Благодаря этому, автор подводит к «многоуровневой защите», где катастрофа проходит через «стены», которые должны были ловить проблему до аварии. Но в случае катастроф — ошибка, проходя через «стены», приводят к жертвам. Ну и понравилась итоговая мысль о том, что отчеты по инцидентам раскрывают скрытую структуру изучаемой системы.

#system_thinking

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

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

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


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

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

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

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

You Don’t Need Ordered Events, You Need Smart Events

Сегодня еще одна статья о event-driven коммуникациях. Вместо обсуждения того, как дергать брокер, автор решил сфокусироваться на том, что должно быть в событии и как ордеринг обеспечить за счет данных в событии. Единственное о чем надо знать — текст специфичен для aws стека.

Начинается текст с описания того, что должно по данным лежать в событии. Причем рассуждения касаются мета информации в событии, а не данных «бизнес-логики» (единственное, поспорил бы с автором о entityID и его формате). Далее затрагивается тема ордеринга, причем автор, вместо перекладывания ответственности на продюсер и брокер, предлагает пойти через версии данных. Пример реализации и отсылки к dynamoDB также присутствуют. К концу автор сравнивает Amazon SNS и EventBridge по ordering, filtering и другим свойствам. Ну и понравилось, что в самом конце указывается, когда о нормальном ордеринге думать придется (если предположили, что в fintech — угадали).

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

#event_driven

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

The startup's Postgres survival guide

Автор текста выше сразу пишет, что изначальная цель статьи — создание гайда по постгресу, который был бы полезнее официальной документации. В итоге получился набор советов разделенных на три группы:
- советы по чтению, записи и схемам;
- советы вокруг планировщиков, автовакуума и bulk операций;
- остальные советы.

О каждом совете писать смысла не вижу, поэтому в общих словах опишу что ждать от каждой из групп. В случае чтения/записи и схем даются советы о том, как спроектировать схему бд, как индексы помогают (включая составные), ну и упоминается очевидный совет о вызове стороннего кода/системы в транзакции. В случае планировщиков — как относится к планировщику, что делать, когда вместо индекса постгрес идет другим путем, как bulk операции обрабатывать. Последняя группа советов относится к FOR UPDATE SKIP LOCKED, партицированию и советам по миграции больших таблиц.

Если пишите код агентами — в начале текста найдете ссылку на скилы по работе с постгресом.

#psql

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

Introducing Meerkat: an experiment in global consensus

Мне нравится разбираться с алгоритмами консенсуса (правда раз в пару лет), поэтому сегодня тематическая статья. Разработчики из cloudflare сделали meerkat — собственную реализацию consensus service, которая еще разрабатывается. И как написали в статье, сервис публичным не будет в ближайшее время.

Текст начинается с описания проблемы: проблемы вокруг согласования control-plane data на масштабах cloudflare. В компании пробовали raft, но из-за специфики работы лидер нод возникли проблемы, из-за чего было принято решение делать собственное решение на основе QuePaxa алгоритма. Далее описывается что от strong consistency требуется в компании, из-за чего авторы подводят к термину linearizability (свойство упорядочиваемости операций). После рассказывается о fault tolerance. Тут разработчикам важно, чтобы при деградации клиент мог продолжать работу, с чем raft не помогает. Далее рассказывается о meerkat: описывается архитектура, как работает эвент лог и как благодаря логу достигается strong consistency. В конце meerkat сравнивается с raft алгоритмом.


#how_it_works #distributed_systems

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

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

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

What Is an Architecture Metamodel?

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

Начинается текст с объяснения термина метамодели (какие типы объектов входят в модель и как они связаны между собой). Далее автор переключается на инфраструктурные модели, так как в инфре проще определить метамодель. После говорится о логическом уровне, где application может значить что угодно. Рассказывается о фреймворках (TOGAF и c4, при этом, сложно с4 назвать фреймворком), где метамодель заранее продумана. Также описывается system-Level, тут придется учитывать SoI, подсистемы, элементы и сервисы. При этом, автор описывает возможные виды сервисов и элементов, что полезно. В конце описывается solution уровень, где придется думать о продукте, solution, application и сервисе. В самом конце описывается как связать все уровни и зачем запариваться о метамодели.

#architecture

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

Building Service Topology at Scale

Еще одна статья от netflix, в которой рассказывается, как в компании строили динамическую «карту» системы. Это вторая часть, первая упоминалась в канале 19 июня. Проблема, которую решали — в компании хотели понимать связи между сервисами, чтобы считать blast radius, понять как структура системы выглядит и так далее. И если в прошлой статье объяснялось почему и зачем в компании заморочились, то во второй части описывается как именно делали «карту».

В начале описывается, почему забор информации раз в N времени не подошел, вместо чего решили выбрать streaming-based подход. Так как данные собирались из трех мест — возникла проблема с трафиком, который, в облаке, проходит не на прямую, а через компоненты (балансеры, гейтвеи, прокси). Эти компоненты не надо учитывать, поэтому пришлось фильтровать «шум» в три шага. Далее описываются дополнительные проблемы, которые вскрылись: лаг консьюмера кафки, проблемы с GC из-за роста трафика, увеличенное потребление памяти и сложность от reactive streams. Каждая из проблем подробно описывается с выбранным решением. В конце найдете общие уроки и выводы от всей затеи.

#how_it_works #observability #distributed_systems

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

How Event Catalog contribute at the Event-Driven Governance

Если выбираете event-driven коммуникации — готовьтесь к тому, что придется заморочиться с наблюдаемостью системы, стандартизацией и обновлением схем. Связано это с тем, что добавить новое событие «в тихую» проще, чем в синхронных коммуникациях. Плюсом редко используют контрактное тестирование/генерацию диаграм. Автор статьи выше предлагает решение в виде Event Catalog (статья «продажная»).

Текст начинается с описания проблем от event-driven коммуникаций. После чего, автор сразу переходит к Event Catalog — централизованному хабу, для управления, discovery и поддержки событий. Для этого используется 6 видов объектов (domains, systems, services, events, flows, entities). Далее показывается пример с order service, где можно схему посмотреть, описание события и изменения событий.

В текстене хватило минусов и проблем с подхода, но если планируете заниматься ITAM-like вещами и инвентаризацией. И, при этом, не встречались с event catalog до этого — советую посмотреть текст и вдохновиться.

#event_driven

Третий поток «Коммуникации систем», старт 30 сентября

В течение месяца будем искать формальные и функциональные связи (привет EventStorming и концептуальная модель данных), разбираться в характеристиках каждого из видов коммуникации, определять размеры событий и в каких случаях подойдет синхронный вызов, а в каких — асинхронный. Отдельный лонгрид посвящен миграции с одного вида коммуникации на другой и исправлению ошибок. А также поговорим о том, как «продавать» решения бизнесу и коллегам, а также в каких доменах подойдут event-driven (и другие виды) коммуникации.

Будет полезно тем, кто работает с монолитами, так и тем, кто работает с распределёнными системами и планирует свои монолиты разобрать.

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

Домашка тоже будет, с упором на практику. По размеру меньше, чем в АС, но времени может занять больше пары часов в неделю. Будем «чинить» уже существующую систему и применять знания из курса на практике.

Полная программа и треть первого урока — на странице курса. Учиться начинаем 30 сентября, закончим в середине ноября. Промокод на 10% скидку — popugi10. Действует до 9 сентября.

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

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

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

Enabling Evolutionary Architecture through the Preservation of Change Locality

Когда говорят об архитектуре, в 90% случаев подразумевают структуру/систему здесь и сейчас. На деле, техническая (да и социо-техническая) система постоянно развивается и эволюционирует. Даже придумали отдельное направление — evolutionary architecture, в котором система проектируется с учетом постоянного изменения. Статья выше как раз о таком подходе.

Текст начинается с примера, когда команду попросили добавить изменение адреса доставки. Изначально предполагалось, что это небольшая фича которая превратилась в кросс командное взаимодействие и проблему границ системы. Через пример объясняется зачем нужна evolutionary architecture — чтобы команда делала изменения с собственным контекстом, без затрагивания других частей системы/команд. Т.е. необходима «локальность» изменений (change locality). Дальше рассматривается как границы системы влияют на локальность и как когнитивная нагрузка может быть звонком проблем. В третьей части текста даются советы, которые помогут с evolutionary architecture.

#system_evolution

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

System Design For Beginners: Everything You Need in One Article

Сегодня лонгридище о system design. Причем, когда я вижу подобные статьи, сразу их пропускаю, так как обычно статьи о подготовке к system design interview, но сегодня без этого. Текст от 2024 года, поэтому без упоминания llm и GenAI. Еще, учитывайте, что текст для junior/middle разработчиков, поэтому хардкора ждать смысла нет.

Пересказывать текст смысла не вижу, поэтому кратко напишу что ждать. Текст — сборная солянка на кучу тем в одном месте. Найдете как вводную в system design, с объяснением, что такое сервер. Так и информацию о коммуникациях (latency, event-driven, брокеры, отдельный блок о кафке, консистентности), о базах (виды и чем отличаются, как скейлить, CAP теорема, но без pacelc). Блоки, связанные с архитектурными стилями, тоже присутствуют, как и с распределенными системами, инфрой и так далее.

Русский перевод, единственное, там 4 части и перевод не закончен.


#system_design

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

Cell-Based Architecture for Resilient Payment Systems

Очередной текст о том, как в компании Х решали проблемы. Сегодня это American Express, которая решала проблемы с resiliency с помощью cell-based architecture.

В начале текста, по классике, описывается проблема. Так как компания занимается деньгами, то resiliency ключевое свойство. Достигается за счет cell-based architecture, благодаря чему изолируются сбои (деградация не переходит в outage), скейлинг становится проще, как и low-latency processing. Далее описывается, что такое cell-based architecture — архитектурный стиль для клауда, в котором связанные сервисы группируются в ячейки (cell), а ячейки работают независимо друг от друга.

Далее описываются пять принципов, на которых строится система:
- репликация данных в каждый cell;
- если репликация невозможна — используется deterministic routing до ячейки за нужными данными;
- если ячейка не может бизнес логику обработать, то запрос роутится в другой cell;
- если ячейка отказала в момент работы бизнес логики, то запрос также роутится в другую ячейку;
- строгий контроль и уменьшение зависимостей для cells.

#how_it_works #cell_based_architecture

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

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

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

What is Systems Based Management?

Пару месяцев назад решил найти авторов на substack, которые пишут о general system theory/system engineering/system dynamic. Оказалось, что подобного контента мало (который был бы мне интересен) и, из примерно 100 авторов, нашел только одного, чьи посты читаю регулярно (если знаете других — делитесь в комментариях). По ссылке выше как раз этот автор с мыслями о том, как думать о менеджменте системно. Сразу напишу, статья больше философская, чем практическая.

Начинается текст с популярного предположения, что на результаты бизнеса влияет «функция индивидуальных качеств» (усилие, талант, индивидуальность и так далее). Вместо этого, автор предлагает посмотреть на управление со стороны системы, в которой работает человек. Т.е. отказаться от мотивации людей, так как люди изначально мотивированы работать, но через время «сгорают». Следовательно, нужна система, в которой изначальная мотивация медленнее «сгорает». Дальше предлагается проверить, насколько текущая компания зависит от «героев», которые спасают проекты. В конце рассуждается о том, что вместо управления на данных можно пойти через эксперименты, благодаря чему можно посмотреть на системную динамику.

#managment #system_thinking

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

ADR \(Architecture Decision Record\) или Мы же теперь умные?

Если поискать по каналу, то ADR упоминается в 11 постах (пример, второй и третий). Сегодня лонгрид о том, что такое ADR, из чего состоит документ, зачем нужно записывать решения, как внедрить и так далее.

Текст состоит из 9 частей + дополнений. В начале автор описывает проблему связанную с потерей контекста вокруг решений (если не можете вспомнить почему выбрали микросервисы — это оно). Кроме этого, указывается еще три анти паттерна с которыми ADR помогают (паттерны из fundamentals of software architecture). Дальше рассказывается что такое adr, какая у документа структура и чем архитектурно значимые решения отличаются от других решений. Дальше рассказывается о трех ролях вокруг документа (автор, принимающий решение и администратор) и о том, как разные роли (тимлиды, архитекторы, разрабы, etc) используют adr. Плюсы и минусы тоже перечисляются, как и способы внедрения. Понравилось, что упоминаются метрики «эффективности» (использовать на собственный страх и риск).

Если до этого не сталкивались с ADR, хотите углубить знания или думаете внедрять документы — обратите внимание на статью.

#adr

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

What's new in Postgres 19

Я жду новую версию постгреса из-за добавления графов прямо в схему бд. Но графы не единственное, что планируется в 19 версии. Статья выше рассказывает о еще трех фичах, на которые стоит обратить внимание.

В список попали: REPACK, отключение JIT по дефолту и улучшения вокруг query planner. Если коротко, REPAC — замена VACUUM FULL и CLUSTER. Единственное отличие, репак может работать без блокировки таблиц (т.е. можно писать/читать во время работы команды). В тексте найдете примеры выполнения команды, описание трех возможных опций (без сортировки/с сортировкой и неблокирующий вариант) и объяснение того, как REPACK работает. В случае JIT, отключение по дефолту, позволяет «тоньше» настраивать поведение базы и включать JIT только когда надо. А по поводу улучшеного планера — в статье найдете пример оптимизации с объединением данных и pgplanadvice, который «пинит» план на ID запроса (если правильно понял)

#psql

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

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

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

Evolutionary Database Design

Если говорить об изменении технической системы — рефакторинг базы данных попадает в личный топ 1 самых проблемных активностей. По этой причине приходится уделять много времени моделированию данных. Поэтому сегодня лонгрид от thoughtworks, в которой рассказывается как справляться с эволюцией базы данных.

Текст начинается с примера, где необходимо из одной строки бд получить три. Далее авторы пишут вводную часть связанную с тем, что нужны эволюционные изменения нужно вносить контролируемо и вносить изменения итеративно. Плюс, авторы говорят об ограничениях у описанных подходов, связанные с multi-tenant приложениями (где баз для изменения сотни).

Дальше описываются 11 принципов. В тексте найдете как очевидные принципы (изменения только через миграции и CI, изменения лежат в гите, частый деплой, у каждого разраба собственный инстанс бд). Так и не очевидные: описание шагов разных видов рефакторинга бд (разделение таблиц, перенос данных и так далее), использование SQL DDL и DML.

#system_evolution #db

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

Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo

Когда работал в toptal, встретился с ситуацией, что прогон всех юнит/интеграционных тестов занимал часы (с парализацией в 60+ потоков). Для ежедневной работы ждать часами билд идея так себе, поэтому, с помощью сетей петри, сделали библиотеку для запуска тестов только вокруг связанного кода. С похожей проблемой столкнулся stripe (1.2 миллиона тестов), о чем пишет в статье.

Текст начинается с понятия Selective Test Execution (STE) — выборочный запуск тестов, связанных с фичей. Для этого в компании сделали «статический анализатор зависимостей», т.е. граф того, какой кусок кода с каким тестом связан. Для этого прогоняются тесты и записываются файлы с кодом, которые были вызваны. (при каждом изменении кода граф перестраивается). Реализация связана с метамагией руби и в тексте найдете описание обработки пограничных случаев и разграничение scope тестов. Дальше описывается, как CI/CD решает какие тесты запустить, основываясь на полученном графе. Отдельно советую почитать о том, как версионирование граф зависимостей тестов под билды.

#testing

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

How to Write an Effective Software Design Document

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

После начинаются советы по компонентам из которых состоит дока: заголовок, метаданные (автор, кто утвердил, когда сделана, статус и так далее), цель текста, background, цели проекта, диаграммы и так далее. Из интересного: автор советует добавлять глоссарий, правовую информацию, таймлайн проекта и осисание свойств (security, SLO).

Если искали «темплейт» для Solution Architecture Document или хотите улучшить техническую документацию в компании — стоит ознакомиться.

#documentation

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

Ссылки уходят в ежегодный летний отпуск на месяц с 1го июля. Увидимся в начале августа. Спасибо что читаете и пишете комментарии ❤️

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

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

How Spotify Recommends Your Next Favorite Song

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

Начинается текст с объяснения collaborative filtering. Идея в том, чтобы создать матрицу с коэффициентами, основанных на том, как пользователь реагирует на треки (пропуски, повторения и так далее). После автор рассказывает о том, что к поведению пользователя добавляется «культурный» пласт. Тут парсятся блоги, тексты песен, журналистика и строятся векторы для маппинга песен на жанры или «эмоции». А для песен, загруженных несколько минут назад, файл прогоняется через «deep acoustic feature extraction pipeline». Далее описывается, как отдельные алгоритмы работают вместе, где тут используется кафка и что лежит в кассандре.

В конце текст переходит в техническую плоскость. Дается таблица технических решений. А также описываются трейдофы решения: точный/приблизительный поиск, выбор между eventual и immediate consistency и так далее. Текст выглядит как сгенерированный нейронкой, но о процессе обработке информации почитать было интересно.

#how_it_works

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

Жизненный цикл API

«Жизненный цикл» чаще используют для обсуждения SDLC (жизненный цикл разработки), хотя жизненный цикл относится и к коду, сервисам, схемам асинхронных событий и так далее. Статья выше о том, что происходит с API от планирования до выведения из эксплуатации.

Текст начинается с описания основных этапов ЖЦ: планирование, проектирование, реализация, тестирование, развертывание, сопровождение и вывод из эксплуатации. Каждый этап подробно описывается. Так в планировании, стоит задуматься о solution requirements и ответить на вопросы о том, кто пользователи, какие сроки и так далее. В этапе проектирования описываем схемы, в реализаци — пишем кодпро. В тестировании автор упоминает о видах тестов (интеграционное, контрактное, сквозное и т.д.). Отдельно порадовало упоминание «квадрантов agile-тестирования». В конце описываются идеи вокруг управления API и «фантазии» о будущем API.

#api

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

How I’d Design a Global Payment System

В канале редко упоминаются статьи в духе «я спроектировал аналог Х», так как 99% таких текстов о том, как проходить system design interview. Но сегодня решил сделать исключение, так как автор решил заморочиться и выйти за пределы интервью.

Текст начинается не с постановки проблемы, а с терминологии. Даются определения payment gateway и payment processor (первое о передачи данных между устройством и банком, второе — о проведении платежа). Далее автор описывает то, что будет проектирование: проведение платежей, регулярные платежи, рефанды и разрешение споров. Плюсом задаются характеристики (миллионы запросов, 4 «девятки», масштабируемость и так далее). Далее описывается три слоя из которых будет система: фронтенд, бек (конечно же на сервисах с кафкой) и как хранить данные данные. Понравилось, что показывается схема данных для каждого из сервисов. Ближе к концу описывается flow транзакций в 8 шагов, включая антифрод. А в конце описываются quality тактики, которые автор выбрал вокруг reliability, scalability и security.

К границам сервисов и названию топиков кафки есть вопросы, но это дискуссионная тема статьи.

#system_design

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

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

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

How Netflix Maps Thousands of Microservices in Real-Time

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

Текст начинается с описания мотивации компании: повторяющиеся вопросы о структуре распределенной системы от инженеров, которые систему чинили или меняли. Плюсом, полезно было бы сразу понимать, что заденет изменения в сервисах. Для этого решили собирать информацию с трех мест: eBPF network flow logs, IPC metrics (для эндпоинтов) и распределенные трассировки. Далее положили собранную информацию в графовую бд, подключили grpc, настроили фильтрацию (включая фильтрацию по времени работы) и получили «карту» системы. Причем, данные хранятся не как снапшот, а с привязкой ко времени, что позволяет собирать временные проджекшены.

#how_it_works #observability #distributed_systems

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

Fundamental concepts of plugin infrastructures

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

Начинается текст с примера на python, где автор решает сделать blog engine для генерации html. Далее объясняется, при чем тут плагины и показывается подход, который нравится автору: через plugin registry, хуки и discovery через загрузку модулей. Во второй части текста описываются четыре концепции, о которых стоит помнить: discovery, registration, mount points и extension API. В конце рассматривается как в mercurial и wordpress реализованы эти четыре концепции.


#microkernel #plugin_system

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

Как найти медленный запрос в PostgreSQL: три инструмента мониторинга

Продолжение статьей о том, как оптимизировать запросы в постгрес. В тексте найдете описание трех инструментов:

- pg_stat_statements. Отслеживает статистику выполнения запросов к бд, попутно группируя одинаковые по структуре запросы. Как примеры использования, приводится поиск частых и медленных запросов, а также запросов с низким уровнем кеширования;
- auto_explain. Автоматически выполняет EXPLAIN ANALYZE для медленных запросов с записью плана в лог. Тут важно следить за количеством записанных логов;
- log_min_duration_statement. Записывает в лог запросы, которые выполняются медленнее, чем заданный порог. Тоже важно следить за размером лога.

Так как каждое из трех инструментов расширения — ставить каждое придется через изменение postgresql.conf (в статье описаны шаги для включения и настройки). В конце найдете «эвристику» для выбора, какое из расширений включать в зависимости от нагрузки и окружения (дев/стейдж/прод).

#psql

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

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

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

Сколько стоит ваш техдолг: методики, цифры, российская специфика

В канале раз 5 упоминались статьи связанны с тех долгом, например «вводная» статья упоминалась год назад (остальные статьи по тегу). Сегодня еще один текст о долге, только авторы решили посчитать «долг» в рублях.

Текст начинается с объяснения, почему тех долг не видит бизнес и наоборот. Авторы связывают отчетность и фокус внимания бизнеса, куда не попадает техническая составляющая, не говоря уже о долге. Далее предлагается три способа подсветить долг бизнесу: прямые опросы людей, добавление тега «tech dept» в «джиру» и git churn (показывает процент перезаписанного кода за время). В конце предлагается три способа «оценки» долга в деньга:
- Считаем время, потраченное на затупы из-за тех долга и умножаем на часовую ставку. Берем цифру и показываем, сколько денег можно сохранить;
- Берем SonarQube и SQALE, полученное значение умножаем на часовую ставку, идем к бизнесу и повторяем первый вариант;
- Считаем cost of delay. Тут нужно посчитать задержку выхода фичи, в итоге получаем два числа: сколько времени фича реально делалась и сколько делалась бы без задержек.

P.S.: Учтите, что статья в блоге компании, которая «продает» собственное приложение. На базовую информацию не влияет, но мало ли.

#tech_debt

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

PostgreSQL 19: Native Graph Queries Are Here

Случайно узнал, что осенью поменяю планы и буду ковыряться с постгресом. Связанно это с тем, что в сентябре выходит 19 версия, где главная, для меня, фича — нативная поддержка графов (хотя возможно гта победит графы). Почему-то уверен, что графы появились благодаря RAG и LLM. Синтаксис запросов уже описан в ISO SQL:2023 Part 16, а язык запросов назвали SQL/PGQ (Property Graph Queries). Статья выше объясняет как будет выглядеть работа с графами в пг.

Пересказывать статью не буду, кратно расскажу как работает. Для начала работы с графами определяем property graph. Делается это через CREATE PROPERTY GRAPH, где явно указываются vertex (ноды, вершины) и edges (связи) таблицы (причем таблиц может быть больше одной). А что бы сделать запрос, используется SELECT * FROM GRAPH_TABLE (property_graph MATCH ...). Плюс стандарта в том, что язык запроса похож на cypher.

В статье найдете примеры и, что радует, автор описал ограничения: fixed-depth pattern matching. Ну и другие фичи 19 версии тоже описываются.

#psql #graph

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

What Is the 3-2-1 Backup Rule and Why It's Evolved to 3-2-1-1-0?

Я не DBA, поэтому о правиле 3-2-1 слышал, но использую только для 3 наборов данных и это не о коде. Если что, 3-2-1 о том, что нужны 3 копии, на 2 видах носителей и 1 копия должна быть в другом гео месте. Поэтому удивился, когда увидел 3-2-1-1-0 схему, думая что 3-2-1 уже заморочена для 80% проектов, но киберпреступления повлияли на бекапы.

Начинается текст с объяснения 3-2-1 подхода, быстро переходя в ответ на вопрос — почему такого подхода уже не хватает (спойлер: с шифровальщиками не помогает). Поэтому, как эволюция подхода, предлагается добавить 1 иммутабельную копию, отключенную от интернета и 0 ошибок от проверки восстановления (поэтому 3-2-1-1-0). Далее рассказывается, как реализовать новое правило: локальный бекап на диске, второй бекап на другом носителе, cloud copy, копия на ленте/в облаке с object lock и автоматизация накатки бекапов. В конце описываются best practices и FAQ (вопросы — пересказ статьи).

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

#db #backups

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

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

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

Scaling ArchUnit with Nebula ArchRules

Статья от нетфликса, в которой инженеры делятся опытом решения проблем с обратной совместимостью совместимостью библиотек. А так как нетфликс использует джаву, то для решения взяли ArchUnit («тесты» для структуры проекта на джаве).

Текст начинается с проблемы: библиотека обновилась с breaking changes, из-за чего развалились сервисы на джаве. Как решение управления жизненным циклом библиотек выбрали archnunit, потому что работает поверх байткода (т.е. работает в jvm стеке), позволяет добавлять правила и содержит низкоуровневый API для сложных правил. В самом начале работы, инженеры, решили настроить работу с централизованным стором правил для проектов (чтобы не копировать правила из проекта в проект). Далее описывается как запускаются правила и как работать с артефактами библиотеки. В конце описываются некоторые примеры правил (безопасность, применение nullable аннотаций и так далее)

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

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

#archUnit #fitness_functions

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

A Field Guide to Alternative Storage Engines for PostgreSQL

Статья из серии «а что, так можно было?» (я не настоящий DBA). В 2019 году в 12 постгресе сделали table access method API. Предполагалось, что будут добавляться новые способы для хранения данных (колонки для аналитики, undo-log для OLTP и так далее). Автор текста выше решил написать, что из себя представляет экосистема.

Текст начинается с объяснения принципов работы API. Тут важно, что TAM API не является «настоящим» pluggable storage layer, только tuple-shaped abstraction. При этом, индексы тоже не работают. Ну и механизмы разбиваются на 4 группы:
- Heap replacements;
- Columnar;
- Lakehouse-backed (тут постгрес — интерфейс запросов поверх внешнего колоночного механизма);
- Специализированные TAM модели (тут автор упоминает три решения, одно связана с TimescaleDB и уже умерло).

Для каждой группы автор приводит примеры реальных проектов, кратко объясняя как TAM работает. А в конце делится советами по выбору подходящего TAM (если конечно решитесь).

#psql

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

Building a mental model for Stripe payments

Мне нравятся статьи в которых описывается реализация домена (8 лет жду аналога книги Фаулера). Статья выше — почти такая статья, потому что текст, в краткой форме, описывает принципы работы и объясняет работу стейт машины для PaymentIntent.

Начинается пост с примера: делаете магазин, доходите до страницы оформления заказа — начинаются проблемы. Как минимум, придется думать о взаимодействии с платежными системами, банком клиента, anti fraud процессах, соблюдении нормативов и так далее. Далее рассказывается о PaymentIntent объекте: намерение получить платеж от клиента. Сам объект отслеживает жизненный цикл платежа от старта и до конца (картинка с sequence diagram прилагается). Далее описываются пять этапов, через которые проходит платеж (оформление заказа, токенизация, аунтификация, capture и расчет со сверкой). В конце описывается, как работать с вебкухами страйпа, что бы знать что с платежом происходит.

Если устанете читать — на сайте сделали «терминал», где запускается змейка (вызывается на <c>).

#payments #domain_implementation

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

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

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

A Promising New Metric To Track Maintainability

Стараюсь пропагандировать ADD, где ключевая идея — принятие решений на основе характеристик. В случае с исчисляемыми метриками — вопросов нет. Сложности начинаются с «субъективными» и не исчисляемыми метриками, например с maintainability или modifiability. Поэтому сегодня статья, где предлагается математическую модель для расчета maintainability.

Начинается текст с предположения, что coupling и cyclic dependencies помогут с расчетом, но, из-за вертикального и горизонтального разбиения, значения считать сложно. Как решение вводится понятие verticalization, благодаря которому, получается Maintainability Level через работу с циклами графа. Во следующей версии метрики, вводится штраф за «длину» цикла. После чего автор занимается fine tuning метрики. Для систем с малым количеством компонентов, метрика работала плохо. Вторая ситуация возникла, когда метрика показала «хорошее» значение, но разработчики были не удовлетворены поддерживаемостью. Проблема оказалась в структуре модулей, которую решили дополнительным условием.

#maintainability

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

Why senior developers fail to communicate their expertise

Проблемы в коммуникации между техническим отделом и «бизнесом» — база. Причин много: отличия в «важности» (у одних — сложность реализации фичи, у вторых — как инвестора на деньги разорить), разные цели от системы и так далее. Причин много, но автор статьи решил пойти по пути разбивки «бизнеса» на два цикла: вывод продукта на рынок и работа с платящими клиентами.

Начинается текст с ситуации, когда бизнес приходит с гениальной идеей: «меняем разработчиков на LLM». От подобной идеи у разработчиков дергается глаз из-за сложности (complexity). Через конфликт, автор вводит первый цикл (в котором находятся продажники, продакт-менеджеры, CEO): компания выводит продукт на рынок и получает фидбек. В таком цикле главная проблема — неопределенность, которая решается скоростью получения фидбека. Во втором цикле, где компания предоставляет услугу пользователю и получает деньги, главное — стабильность, а со сложностью проблема. Далее автор связывает два цикла через «компанию» из-за чего получается несогласованность между людьми в разных циклах. В конце предлагаются решения, о чем уже прочтете в статье.

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

#ppl_communications

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

On mashing up modelling techniques for fun and profit

Статья заинтересовала идеей смешивания context map из ddd и c4 в одну модель. Если что, идея context map в отображении bounded context из DDD и связей между контекстами. А главная ценность — отображение паттернов коммуникаций из DDD. Добавив информацию о «типах» коммуникаций контекстов в с4, получаем больше информации о взаимодействии частей системы не только на техническом, но и на социо уровне (а software system — socio-tech system).

Начинается текст с показа автором модели совмещенного context map и c4, которую сделали для воркшопа. А после объяснения плюсов подхода показывается как подобные модели делать. Сначала делается c4 level 1 с интеграциями, после чего добавляется level 2. Далее добавляются паттерны коммуникации на level 2 (open host, anti-corruption и так далее). После чего добавляются контексты и объясняется в чем плюсы и минусы подхода. В конце дается название подходу (Model Storming). Единственное что огорчило — нет конкретных инструментов, а статья сугубо идейная.

#c4 #ddd

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

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

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

Seeing like a spreadsheet

Надо признаться — я фанат таблиц (которые sheets). И с каждым годом больше и больше верю, что если бизнес модель нельзя описать в таблицах, то лучше два раза подумать, перед тем как связываться с таким бизнесом. Автор статьи описывает собственные размышления о том, как таблицы поменяли бизнес в америки.

Начинается текст с того, как работали до появления таблиц: как страдали коммуникации и почему бизнес был чаще семейным. Далее появляются заводы, следовательно требования к контролю увеличиваются, что приводит к развитию инструментов координации. Но проблемы проверки и расчетов никуда не девались, что привело к появлению таблиц в 60-70тых годах. Далее автор описывает появление VisiCalc (визуальный калькулятор) — прародителя современных таблиц, благодаря которому появился сначала lotus, а потом и excel. В последней части автор описывает как таблицы повлияли на симуляцию и финансы и в конце подвязывает нейронки.

#sheets

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

Путеводитель по матанализу, который скрывали от вас в вузе

На прошлой неделе упоминал статью с попыткой автора «натянуть» концепции из матанализа на код. Пока читал статью, понял, что матан уже забыл, поэтому сегодня — краткое интро в матанализ. Причем не список терминов, а логика развития идей Аристотеля, которые в конце придут к матанализу (в институте был только Коши, поэтому статья и появилась в канале). Сразу скажу, по ссылке лонгрид, также отмечу, что комментарии посмотреть тоже стоит (всего их 325 штук).

Текст целиком пересказывать не буду из-за объема (3 части и 11 глав в сумме). Вместо этого расскажу о том, что самому было интересно прочитать. Во первых, понравилась, сама идея объяснения анализа через логические рассуждения, без эпсилон-дельта приколов (пример логического доказательства найдете в самом начале). Также понравилось, как размышления философов подвязали с бесконечностью и множествами. Плюсом, понравилось как вывелось определение производной через «о-малое».

#math

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

Payment systems don’t move money. They move promises.

Статья из серии «как работает Х». В тексте выше, автор, объясняет как работает payment processing, при чем тут две системы («быстрая» и «медленная», которые называет clocks) и почему в момент оплаты ничего, кроме «обещания оплаты» не происходит.

Начинается текст с объяснения того, как работает «быстрая» система (говорит, что клиент намерен что-то сделать с доступным балансом). При этом, банк, в этот момент, не включается в процесс. В него только уходит намерение, которое может обрабатываться от секунд, до дней. «Медленная» система уже получает событие из банка и работает с ledger. Далее описывается «стандартная» ошибка: posting to the ledger inside the bank callback (нормального перевода не придумал, поэтому цитатой), что приводит к расхождению данных, дублям и другим проблемам. Далее описывается payout table, таблица, в которую пишутся намерения из «быстрой» системы и которую обновляет колбэк из банка. Ну а ledger уже использует payout table. А в конце, автор отвечает на популярные вопросы (зачем нужен баланс и ledger в разных местах, почему не взять CQRS или сагу и так далее).

#payment #fintech

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

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

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

Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo

Очередная статья, в которой компания описывает, как решала проблемы в технической системе. Сегодня страйп, который сделал один из самых больших руби монорепозиториев (50+ миллионов строк). А возникшая проблема — как перестать гонять миллионы тестов на каждый PR. Спойлер: написали собственный анализатор измененных файлов, на основе которого запускаются только нужные тесты. Мне тема интересна, потому что в топтале (когда я там работал), тесты гонялись полчаса в 60+ потоков. А для решения похожей проблемы для подобной проблемы использовались сети петри.

Текст начинается с описания проблемы: 50к сборок в неделю, 1.2 миллиона тестов, каждый раз гонять такое количество тестов возможности нет. Для решения проблемы в компании решили построить граф зависимостей, основанный на том, какие файлы вызываются во время прогона тестов (единственный способ для руби из-за «динамичности»). Сделали это с помощью библиотеки на с++, которая перехватывает «открытые» файлы на уровне ОС. Далее описываются корнер кейсы: что делать с тестами, которые только ищут файлы, что делать с областью видимости, как работает планировщик и выбирает тесты для нового кода. В конце описывается, где хранится мета по тестам (спойлер: в монге) и как хранятся «релизы».

#how_it_works #testing

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

Математический анализ для разработчика: что действительно нужно понимать

В институте проходил и матанализ и линал, в реальной жизни пригодился только линал (матрицы, вектора и пересечения плоскостей). А вот с матанализом не срослось, мозги вправило, но неопределенные интегралы, градиенты и любые эпсилоны больше нуля так и остались воспоминанем. Статья выше — попытка предположить, где абстракции из матанализа могут помочь в анализе кода.

Так, автор начинает с области видимости функции. В качестве примера используется функция 1/x, которая не определена в точке 0, что приводит к ошибкам. Далее рассказывается о пределах, который привязывается к bigO. После рассматривается непрерывность и производные. Причем производная привязывается к определению «скорости» роста метрик (latency в случае текста). Далее рассматривается приближения и разложения Тейлора (когда сложная функция раскладывается на бесконечную сумму степенных функций) и многомерный анализ. Хоть текст написан нейронкой (уверен на 90%), статья дает повод подумать о том, где и как использовать абстрактные понятия в работе.

#math

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

How to Pick a Database for Your System \(Without Guessing\)

Еще одна статья о том, как выбирать базу данных, на основе требуемых свойств. В отличии от других статей, упоминавшихся в канале, автор решил выбирать по PACELC, а не CAP. Хотя текст и начинается с объяснения CAP теоремы, автор приходит к обсуждению ситуации, при которой availability и consistency не достижимы одновременно. Благодаря этому происходит переход к PACELC. А после показывается как выбирать между 6 бд (упоминается кассандра, монга, постгрес, редис, динамоДБ и cockroachDB). Для этого автор предлагает в основе выбора использовать характеристики из PACELC и вид бд. А в качестве дополнительных критериев — internal mechanisms и юзкейсы каждой из бд.

#db

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

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

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

How Instacart Built a Search for Billions of Products

Статья от компании instacart (аналог купера), в которой рассказывается о том, как решалась проблема поиска. Идея в том, что люди по разному ищут продукты. Запросы выглядят как «здоровые продукты», «соус для пасты 227г» и так далее. При этом, результат семантического поиска и поиска по ключевым словам должен соответствовать ожиданиям. Для этого, в компании, решили сделать два параллельных способа поиска, о чем в статье рассказывается.

Текст начинается с описания проблемы с параллельными флоу поиска. Причем, особенность поиска в том, что товары быстро появляются и также быстро «пропадают» со склада. Для этого ввели два параметра для оценки поиска — полнота и точность. Далее описывается, почему отказались от elasticsearch (переиндексация на изменения подвела) и как переезжали в постгрес. Следующий этап — добавление семантического поиска с помощью FAISS, который заменили на pgvector. В конце найдете информацию о проблемах подхода и рассуждения о скейлинге поиска.

#how_it_works #search

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

Going Critical

С начала этого года разбираюсь в network science, поэтому сегодняшняя статья по теме. Текст выше о диффузиях в сетях, т.е. о том, как «информация» распределяется в сети (пожары, мемы в интернете, сплетни, вирусы и так далее). Причем статья интерактивная, что редкость для подобных текстов. А если думаете зачем читать о сетях — подобным образом можно симулировать отказы в software systems.

Начинается текст с создания «простой» модели в виде сети 7х7, в центре которой «зараженная» нода. При этом, «заражение» происходит с 100% вероятностью для заражений. Далее вводится понятие SIR model, которая состоит из нод в трех состояниях (восприимчивый, зараженный, удаленный). Но такая модель не симулирует ситуации, когда «зараженная» нода перестает быть зараженной и становится снова восприимчивой. В таких случаях помогает SIS simulation (вместо удаления, нода снова становится восприимчивой). Далее рассказывается о critical threshold, точке «перелома» между субкритической и сверхкритической сетью. Также рассказывается о том, как симулируются «заражения» в разных частях сети, иммунитеты у нод, влияние degree (количество связей у ноды, причем, через degree можно «симулировать» города). Ближе к концу найдете примеры симуляции «знаний». А в конце автор рассматривает feedback loop между технологиями и знаниями (знания создают технологии, которые увеличивают знания).

#network_science

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

The Map of System Topologies

Текст выше — не статья в привычном смысле, скорее это попытка систематизировать архитектурные стили и паттерны вокруг структуры кода. Т.е. автор раскидал паттерны на плоскости, в результате чего получил пять «регионов», о которых и рассказывается в статье.

В начале текста описывается методология, которой придерживался автор. Так предлагается делить паттерны на техническое разделение (слои), бизнес разделение (сервисы) и шардирование. В результате чего, от шардирования пришлось отказаться, как и от экзотики (в итоге я насчитал 40 паттернов). Далее, автор выделяет пять групп:
- Monolithic, система целиком — один компонент;
- Layered, система делится технически на слои;
- Services, система делится по бизнес функциям;
- Fragmented systems, система состоит из множества мелких частей;
- Plugins, система состоит из cohesive core и модулей.

В самом тексте подробно описывается каждая группа, причем с разбивкой на виды. Так монолиты бывают с плагинами, с auxiliary layers и так далее. А в конце найдете выводы автора по топологии.

#patterns

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

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

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

Why Root Cause Analysis doesn't work in Complex Systems

Главная идея Root Cause Analysis — у каждой проблемы существует причина. Поймете причину — проблема больше не повториться. Звучит логично, но для «сложных» систем причины не явно связаны между собой, о чем рассказывает автор в статье выше.

Текст начинается с объяснения идей и подходов из Root Cause Analysis. Тут найдете упоминание диаграмм Исикавы (если видели диаграммы в виде скелета рыбы — это оно). А также описываются «5 why?» и другие методы. Далее описываются недостатки RCA: наличие проблем возникающих из суммы причин, а RCA в такие проблемы не умеет. Эта мысль раскрывается через feedback loops, где изменения в одном месте, усиливает/ослабляет эффекты в других частях системы.

В качестве альтернативного подхода, к анализу проблем, автор предлагает рассмотреть теорию ограничений (которую автор называет протосистемным подходом), flow diagrams и карты feedback loops. А в последней части текста автор предлагает 3 подхода к улучшающему вмешательству (PDSA и эксперименты)

#system_analysis #system_thinking

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

Anti-patterns in event modelling - Passive-Aggressive Events

Отсутствие событий — ситуация, с которой сталкиваюсь в каждом первом проекте, где реализуют асинхронную коммуникацию. Под «отсутствием событий» подразумевается то, что сообщения, которые передаются либо являются данными (UserEvent), либо командами (CalculatePrice), а не событием (фактом того, что что-то произошло). Статья выше о «скрытых» командах, т.е. «событиях», которые автор называет пассивно-агрессивными.

Начинает автор с аналогий из реального мира, где встречается пассивно-агрессивный тон. Далее подводится идея, что подобный тон в событиях говорит о «скрытых командах», т.е. сообщение передает информацию, но ждет, что будет что-то сделано. Подобное поведение, автор, сократил до следующей фразы: «я свою работу выполнил, теперь твоя очередь». Далее возникает утверждение, что если передаем команду, а не событие, то придется делать синхронный вызов. На что приводятся мысли Сэма Ньюмана (написал книгу о микросервисах), что синхронная от асинхронной коммуникации отличается только блокировкой. После чего появляется еще один вид сообщений — документ (если курсы проходили, то это репликация). Ну и в конце рассказывается где использовать события, команды и документы.

#event_driven

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

Why scrum is stressing you out

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

В тексте найдете четыре причины почему скрам вызывает стресс:
- спринты не кончаются. Т.е. нет периодов нагрузки и отдыха, как в том же waterfall;
- отсутствие контроля у команд с какой скоростью надо деливерить и работать;
- игнорирование подготовительной работы (обдумывание, обучение, отдых, рефакторинг и так далее);
- создание scrumfall, гибрида scrum со спринтами и нагрузки из waterfall в «важный» дедлайн (релиза).

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

#ppl_managment

Запустился шестой поток курса по анализу систем и принятию технических решений, старт 20 мая

В течение месяца будем учиться анализировать системы — определять элементы, связи и свойства (как системы, так и элементов). А благодаря анализу научимся обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview — курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.

Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия;

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

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

Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики прокачали насмотренность (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).

Полная программа и половина первого урока — на странице курса. Начало 20 мая, а до 30 апреля действует промокод SA6PEPE на 10% скидки.

Eсли ждете коммуникации систем — курс будет где-то в конце 2026 года, можете записаться в вейтлист.

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

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

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

Keeping a Postgres queue healthy

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

Начинается текст с описания проблемы: берем пг, в него пихаем очередь, а что делать с нагрузкой в таком случае не понятно. Причем, паттерн поведения в очереди строится вокруг того, что данные пишутся, единоразово читаются. А после, старые данные, необходимо удалить, чтобы база не распухала. Вот тут и начинается проблема, так как появляются dead tuples, т.е. записи, которые для базы «удалены» (запросы игнорируют данные), но в реальности, данные удалятся только после VACUUM. Далее приводится пример очереди jobs, состоящей из 4 колонок (pk, json, status и run_at). И подробно объясняется проблема dead tuples, которую автор симулирует. После объясняется работа вакуума и приводится список решений, которые помогут в удалении «мертвых» данных.

#psql

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

The Math of Why You Can't Focus at Work

В пятничных ссылках редко встречаются тексты связанные с продуктивностью. Связанно это с тем, что 99% подобных статей либо «сео» статьи, либо банальщина вокруг очередной настройки obsidian или todoist. Текст выше крутится вокруг относительно «капитанской» идеи: «меньше прерывания, больше сфокусированной работы, больше удовлетворения работой». Но вы читаете эту подводку из-за того, что автор решил доказать это утверждение используя мат модель, что редкость для подобных статей.

Начинается статья с постановки проблемы, связанной с прерываниями. Для этого показывается «хороший» день, когда прерываний мало и в наличии 2 блока на 2+ часа для «глубокой» работы. А также показывается «плохой» день, где времени на «глубокую» работу — меньше двух часов в сумме. Из этого, автор выделяет три главных фактора «хорошего» дня: сколько раз в час прерывают, сколько времени требуется на восстановление концентрации, минимальная продолжительность блока осмысленной работы. И тут же появляется мат модель, которую автор визуализируют. А самое интересное начинается, когда берутся данные о количестве прерываний из исследований, а в визуализации нет времени на работу. Во второй части статьи автор делится советами, как улучшить ситуацию (с проверкой через модель).

#productivity

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

Какой минимум симптомов нужен врачу для постановки диагноза

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

Текст начинается с истории появления теории грубых множеств, основанной на теориях вероятности и нечеткой логике. А главная идея вертится вокруг согласованности, т.е. ситуации, когда нет объектов с одинаковыми признаками или симптомами, но разными «диагнозами». Причем, размер выборки не важен, даже 10 строк в таблице хватит. Кроме согласованности, придется еще разобраться с вектором значимости и суперредуктом и редуктом. Далее, на примере симптомов и болезни, описывается алгоритм поиска важных признаков. А в конце приводится пример кода на julia.

Если говорить о применимости теории в IT, то первое о чем подумал, когда читал текст — было бы интересно воспользоваться теорией для анализа постмортемов. Т.е. берем происшествия, выделяем признаки, после чего получаем вектор значимости для признаков. А на «важные» признаки тратим больше ресурса на проверку в релизах и ежедневной работе.

#data_analysis