2pegramming

Канал возвращается из отпуска

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

1. Пятничные ссылки без изменений, первые в 2025 году будут уже в это пятницу;
2. В четверг стартует новый поток Анализа Систем. Будем рисовать квадраты и обосновывать решения основываясь на бизнес;
3. В этом году ответы на вопросы будут раз в месяц, также по понедельникам (на чаще нет вопросов и ресурсов). Ответы из 2024 года можно посмотреть на сайте, а задать вопрос связанный с системами/архитектурой/техническими шуткам можно анонимно или пишите в личку;
4. Новая версия курса по асинхронным коммуникациям (АА) пишется. Больше конкретики будет в марте (во всяком случае такие планы);

Если возникли вопросы или предложения, пишите в комментарии к посту.

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

Канал уходит в ежегодный зимний отпуск, встретимся после 13 января. Спасибо каждому кто читает канал, комментирует и задает вопросы ❤️

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

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

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

Книги

Architecture Modernization

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

При этом, в книге упоминаются «популярные» концепции и подходы: team topology, wardley mapping, strategy DDD с core domain chart и EventStorming, способы выноса сервисов, DevEx и так далее. Так как собственные ожидания оказались выше, чем то, что получил по прочтению, то в личном рейтинге поставил оценку ниже среднего. Из минусов также отмечу сложную формулировку и слабую сквозную идею (допускаю, что личная проблема).

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

Finding software boundaries for fast flow

Если автор прошлой книги пытался замахнуться на обширную тему в 500 страниц, то эта короткая брошюра с пятью статьями (50 страниц) покрывает идею того, как бизнес и разработка связаны. В книге найдете следующие статьи:

- Как связывается wardley mapping и концепции strategy DDD (советую хотя бы эту часть, так как покажет, что идеи из strategy DDD на самом деле не уникальны и подход можно заменить на другой, без потери смысла);
- Alberto Brandolini (автор EventStorming) описывает как связан team topology и context map (привязка к EventStorming тоже присутствует). При этом, следующий текст описывает аналогичную связь, но другим языком и другим автором;
- В четвертой статье описывается как используя стратегический ддд и тим топологию проводить анализ и развитие сервисов;
- Пятая описывает как находить границы бизнеса (тут уже описанные выше концепции используются);

Единственное, учтите, что это лид магнит team topology, поэтому к тексту стоит относиться со скепсисом.

Developing High Quality Data Models

Если времени (или сил) только на одну книгу, при этом хотите развиваться как разработчик или аналитик – однозначный мастхэв. Сразу скажу, книга старая (2011 год), но поможет в понимании модели данных (как концептуальных, так и логических). Благодаря чему, улучшите понимание проекта и следовательно качество кода (который опирается, в том числе, на модель данных). Из книги узнаете о разных моделях данных, основы entity relationship, как модели данных связаны с энтерпрайз архитектурой и основные принципы моделирования.

Советую ознакомиться с первой половиной, так как последняя глава затрагивает «High-Quality Data Model framework», который до знакомства с книгой нигде не встречал.

Продолжение

Пейперы

A Practical Model for Measuring Maintainability

Maintainability (как и modifiability) характеристика, о которой часто упоминают в контексте разработки, но редко когда понимают как оценить maintainability как свойство. Иногда предлагается оценивать через «user story-like» подход, когда, через описание сценариев предполагается требуемое значение или нет (пример: «при возникновении ошибки в оформлении заказов, исправленная версия кода окажется в продакшене через 2 часа»).

Авторы пейпера как раз пытаются определить, как считать характеристику, для чего придумали мат модель, которую планируют развивать в будущем. А если сделаете инструмент для популярных языков на основе описанной модели, может получиться DevEx стартап (либо же fitness function инструмент как opensource проект).

CRISP: Critical Path Analysis of Large-Scale Microservice Architectures

Пейпер от убера в котором описывается подход CRISP (Critical Path Analysis of Large-Scale Microservice Architectures) для трассировки RPC в распределенных системах. Изначальная проблема в том, что текущие трейсинг инструменты собирают много данных, но не помогают в определении критических мест в системах, размером с убер. Описанный в пейпере инструмент как раз помогает либо понять что происходит с конкретным эндпоинтом и где проблема, либо найти части системы, которые больше всего влияют на перфоманс, либо поиск аномалий в коммуникациях. А как работает CRISP – читайте в пейпере.

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

Остальное

Ответы на 8 вопросов

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

Distributed Systems 1.1: Introduction

Автор кабанчика 4 года назад выложил курс о распределенных системах, 23 видео в сумме. Темы связаны с низкоуровневой работой распределенных систем: RPC, consistency models, fault tolerance, clock synchronization, replications, quorums (включая raft) и так далее.

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

Factorio: Space Age

Если пропустили, вышло дополнение к факторио, основанное на space exploration моде. Если не играли в факторио и не знаете чем игра поможет в разработке, советую цикл из двух статей об анализе архитектурных стилей на основе фабрик из факторио.

ДРАКОН

Если учить теории желания нет, Team Topology не интересен, а строить галактические фабрики в факторио скучно, но хочется прикоснуться к космосу – можно посмотреть на ДРАКОН. Это визуальный язык программирования, на котором писали автоматику для бурана. На сайте найдете учебник, а также найти интерпретатор (DRAKON Editor работает под мак).

gonec: 1С фреймворк для микросервисов

Если учить теории желания нет, Team Topology не интересен, строить галактические фабрики в факторио скучно, а изучать визуальный язык программирования желания нет – стоит попробовать написать микросервисы на 1С. В этом поможет фреймворк gonec. Ссылка скорее шуточная, но может кого заинтересует.

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

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

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

How LinkedIn Customizes Its 7 Trillion Message Kafka Ecosystem

Статья рассказывает как используют кафку в компании, где технологию и придумали. Изначально может показаться, что статья о том, как разработчики используют кафку, на деле, текст о том, как компания поддерживает и развивает собственный форк кафки. При этом, в линкедине кафка используется для: трекинга активности юзеров, передачи сообщений в системе и сбора метрик. Для этого развернули 100 kafka кластеров с 4к+ брокеров, 100к+ топиками и 7кк+ партиций. А в день процессится 7ккк+ сообщений.

В начале текста описывается как экосистема работает в компании. В этом помогает: schema registry, клиенты (включая REST proxy для не java клиентов), инструмент для зеркалирования данных между кластерами (называется brooklin), инструмент для cluster maintenance и self-healing (cruise control) и пайплайн для аудита и метрик.

После, описывается как компания поддерживает собственный форк кафки. Присутствует описание работы с релизными ветками. Плюсом описывается как происходит добавление новых фичей в линкедин версию кафки. При этом, добавили flow chart того, как определяется в какую из веток попадет коммит. А в конце приводятся примеры изменений над основной версией кафки, которые сделали в компании (улучшили скалабилити, добавили maintenance mode и так далее).

#how_it_works #kafka

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

How Nginx Handles Thousands of Concurrent Requests

Сразу отмечу, статья короткая и без хардкора. Подойдет тем, кто не знает как работает nginx и не хочет разбираться в кишках. Для большего погружения, лучше чем The Architecture of Open Source Applications (Volume 2): nginx еще не придумали.

В тексте рассматривается два подхода к обработке запросов: one request per process и event-driven. Первый подход подразумевает, что под каждый запрос будет создан тредом, который его обработает (если правильно помню, так работал апач когда-то). В случае с event-driven идея заключается в том, что есть заранее созданный «пул» воркеров, которые реагируют на новые запросы и обрабатывают запросы по мере поступления. За счет такого event-driven подхода память и cpu не увеличивается по мере увеличения нагрузки.

#nginx

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

Why Payments Engineers Should Avoid State Machines

Если открыть ютуб или гугл, найдете туториалы по созданию платежных систем на основе стейт машины. На деле все не так просто, в частности, когда дело касается продакшн кода, а не system design interview. Поэтому сегодня статья, в которой автор объясняет почему стейт машины приносят проблемы в платежных системах.

Спойлер к тексту: стейт машины не могут прокручивать состояние в обратную сторону (в прошлое), т.е. стейт машины не позволят добиться replayability (как минимум поможет для обработки споров клиентов). Еще одна причина, почему скейт машина может помешать – проблемы с scalability, из-за скейлинга стейт машин под каждого клиента. Вместо этого автор предлагает рассмотреть pull-based подход основанный на событиях.

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

#state_machine #payment_systems

Новый ответ: как хранить и работать с графами в бд, если нельзя выбрать neo4j

Среди проектов с которыми работал, графы и графовые базы в частности, требовались в ~10% случаев. При этом, когда появлялась необходимость в работе с графами, возникали проблемы: либо поставить инстанс neo4j не было возможностей, либо разработчики не знали как переложить графовую структуру в базу и городили велосипеды. Поэтому сегодня отвечу на вопрос, что делать, если нужны графы, но без neo4j и при этом, закрывать задачи в джире.

Как хранить и работать с графами в бд, если нельзя выбрать neo4j

Сразу скажу, если до этого работали с графовыми базами данных и (или) проходили курс дискретной математики – ответ Америку вам не откроет. Но надеюсь, что текст поможет в ad-hoc ситуациях, либо подтолкнет к изучению теории графов.

---------

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

Отдельно спасибо всем, кто в этом году читал ответы и задавал вопросы как по ответам, так и вне ответов! Это мотивирует и ценно.

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

Привет!

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

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

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

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

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

Полная программа и половина первого урока - на странице курса. Начало 16 января, а до 13 декабря действует промокод SA4PEPE на 10% скидки.

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

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

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

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

Notes on Distributed Systems for Young Bloods

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

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

В качестве проблем, описываемых автором выделю четыре:
- низкая отказоустойчивость;
- повышение стоимости создания распределенных систем;
- проблемы связанные с координацией;
- «It’s slow», как сложнейшая проблема в подобных системах;

Советов больше:
- заранее задуматься о backpressure (когда часть системы сигнализирует об отказах) и использование partially available подходов;
- сразу добавить метрики, причем желательно в персентелях;
- использование фича флагов для деплоймента;
- репликация данных поможет с partially available и reliability;

#distributed_systems

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

Оптимизация хранения данных в PostgreSQL

Лонгрид о том, как оптимизировать хранение в постгресе (а еще скорость вставки и чтения). В качестве примера, автор, сделает таблицу customers с 23 столбцами (почти все number, есть и varchar) и миллионом записей. И в самом начале покажет как определить размер такой таблицы.

В тексте рассматривается четыре совета о том, как оптимизировать таблицу:

1. Определить какие данные будут использоваться и изменить таблицу под эти данные (boolean вместо number, integer вместо bigint, и так далее);
2. Самый магический совет. Связан с положением столбцов в таблице. Идея в том, чтобы в конец таблицы засунуть столбцы переменной длины, а столбцы, которые по большей части будут хранить null или значение по дефолту поставить в начало. Если таких столбцов будет много, получим ускорение чтения из таблицы (но размер станет больше на пару процентов);
3. Сгруппировать столбцы по типам. Т.е. сначала integer, потом столбцы с boolean. При этом, скорость вставки увеличивается, а размер таблицы уменьшается;
4. Использование smallint типа для небольших данных, что продолжает первый совет;

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

#psql

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

MMOG: World States and Reducing Traffic

Лонгрид о синхронизации состояния в MMO играх, а не веб приложениях. Начинается текст с двух состояний: на стороне клиента и сервера. Может показаться, что стейт лучше хранить на сервере, но подобный подход может разбиться о пропускную способность серверов. Автор сразу советует гонять между клиентом и сервером как можно меньше данных (упрощать модели персонажей, локаций, перевода игры из 3D в 2D и так далее)

После, автор добавляет еще один стейт – Publishable State, который связывает клиентский и серверный стейт и должен быть максимально сжатым. Кроме рассказа о стейте, автор также рассказывает и дает советы о том, как уменьшить Publishable State через сжатие, работу с типами и структурами. Причем, описывается четыре варианта сжатия, которые можно комбинировать.

Хоть статья выше не связана с веб приложениями, а связана с онлайн играми, но идеи и подходы можно попытаться адаптировать под другие цели (особенно идею с Publishable State и методы компрессии).

#games #state_managment

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

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

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

How SQLite made Notion 30% Faster

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

Автор статьи рассказывает как решалась проблема в компании, но в начале описывает три причины почему возникла подобная ситуация: внешние интеграции, большое количество API вызовов на клиенте и малое количество cpu у клиентов.

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

- Web worker может быть только один для одного таба, при этом лочится открытый файл базы для записи в других табах. Решили через агалог коннекшен пулла (если правильно понял) – SharedWorker;
- Первоначальная загрузка страницы стала хуже из-за загрузки и запуска базы. Исправили заменив порядок загрузки: сначала грузим страницу, потом базу;

#performance #sqlite #web_assembly

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

Why, How We Built a Primary-Replica Architecture

История компании, которая переехала с AWS Redshift на ClickHouse и получила новых проблем, решение которых описано в статье. Изначально выбрали redshift для аналитических запросов, но с ростом данных появились проблемы с ценой и перфомансом. Из-за чего и переехали на кликхаус. После чего возникли новые проблемы: скейлинг стораджа под рост данных и проблемы с дисками.

Для исправления проблем, в компании решили внедрить JuiceFS, распределенную файловую систему с высокой производительностью. Файловая система была выбрана из-за функции моментальных снимков для реализации архитектуры первичной реплики для ClickHouse. А как работает JuiceFS и создаются реплики для кликхауса можно прочитать в статье, но учтите, что статья больше об инфраструктуре, чем о работе с кликхаусом.

#clickhouse #file_systems

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

Improving Application Availability: The Basics

Availability – характеристика которая часто всплывает в system design interview и в рабочих буднях. Поэтому сегодня серия статей (на текущий момент пока 3 статьи) об availability в системах.

Автор начинает с объяснения характеристики, говорит зачем и что показывает. Плюс объясняет концепцию девяток. После, связывается цена и сложность системы со значением доступности. Затем затрагивается важная тема приоритетов доступности. Так как нельзя сказать, что система целиком важна, придется выбирать какие части системы приоритетнее в плане availability. Тут рассказывается о четырех уровнях и как каждый уровень влияет на доступность.

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

Статья больше обзорная. Поэтому, если плохо ориентируетесь в характеристике – статью стоит посмотреть. Если ждете хардкора, то можно пропустить.

#availability


——— одной строкой ———

- Учитывайте каждую интеграцию в системе, особенно когда нагрузка растет. Иначе будете как яндекс

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

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

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

A Model for Debug Complexity

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

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

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

#debugging #math_models #fintess_functions

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

Evolving from Rule-based Classifier: Machine Learning Powered Auto Remediation in Netflix Data…

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

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

Русский перевод гугл транслейтом

#ml #errors

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

How we run migrations across 2,800 microservices

Одна из проблем распределенных систем – как поддерживать актуальные версии библиотек в каждом из сервисов. Своим опытом делится компания, в которой крутится 2800+ сервисов. В компании, вместо того, чтобы перекладывать ответственность за обновления на каждую команду, в компании решили выделить одну команду, которая занималась бы миграцией на новые версии библиотек. В тексте показано, как происходил переход с OpenTracing на OpenTelemetry (учтите, что описывается мало деталей).

Процесс миграции описывается в 7 шагов:

1. Планирование и обсуждение необходимости миграции;
2. Создание абстракции-обертки для старой библиотеки;
3. Анализ функций, которые нужны для работы библиотеки;
4. Добавление новой библиотеки в обертку;
5. Деплой сервисов с новой версией библиотеки;
6. Включение «фича флага» для запуска новой библиотеки;
7. Удаление старой библиотеки;

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

#distributed_systems

Новый ответ: как «предсказать» какой система будет в будущем

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

Как «предсказать» какой система будет в будущем

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

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

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

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

How Shopify Manages its Petabyte Scale MySQL Database

Очередная статья из серии «как в компании X решили проблему Y». На этот раз shopify и скейлинг петабайтных MySQL баз. Секрет строится вокруг трех направлений: балансировка шардов без даунтаймов, поддержка read консистентности через репликацию и бекапы. Статья как раз рассказывает о каждом из направлений.

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

В случае с консистентностью, рассказывается о проблеме потери актуального состояния данных во время реплицирования. В качестве решения, в компании пробовали tight и causal consistency, но в итоге остановились на monotonic read consistency (когда нельзя посмотреть старые данные). А последней части рассказывается как происходит бекап и восстановление.

#how_it_works #sql

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

Testing exceptions

Кажется, что в TDD можно описать success path сценарии и жить счастливо. На деле, без failure path сценариев нельзя понять на сколько корректно обрабатываются ошибки. Автор статьи делится личным опытом тестирования failure path сценариев. Поднимается три темы:

- Как использовать мок объекты для тестирования исключений;
- Является ли эксепшен контрактом объекта;
- Как реализовать интеграционный тест для failure path;

Важно: учтите, что примеры в статье сфокусированы на xUnit и дотнете.

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

#testing #tdd

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

Don't Break the Bank: Smart Spending on Software Architecture

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

После, автор классифицирует бюджет под разные виды компаний. В собственном бизнесе без финансирования расходы будут сокращаться любыми возможными способами, в стартапах бюджет зависит от финансирования, в small-medium business (smb) бюджеты выше чем в стартапах, но отчитываться о тратах придется. А в крупных организациях бюджеты самые высокие. В конце найдете рассуждения о том, откуда могут появляться затраты (явная стоимость и не явная стоимость решения). При этом, автор советует оценивать затраты решения не абсолютным числом (напримре 100$), а процентом от текущих расходов (при расходах в 100$ еще 100$ расходов много, а при расходах в 100 000$ - капля в море)

#cost #desicion_making

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

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

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

Github: Using SQL's Turing Completeness to Build Tetris

Не статья в привычном понимании, но пройти стороной не могу. ТЛДР: берем постгрес и на SQL пишем полноценный тетрис. В результате получился репозиторий с кодом и объяснением как код работает, плюс скрипт на питоне для запуска запроса и отлова команд. Код разбит на три части: гейм луп через рекурсию, инпут реализованный через таблицу и аутпут. Поле сделано через одномерный массив, текущая фигура хранится в массиве состоящем из позиции, поворота и id фигуры. Также рассказывается о реализации рандома, рендеринга и приводятся расчеты по resource usage. Отдельно отмечу, что в сиквел коде подробные комментарии с тем, как работает каждая функция.

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

#sql

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

Exactly-Once Payments At Airbnb

Одна из проблем с онлайн платежам связана с необходимостью exactly-once доставки, что становится не выполнимым в распределенных системах. В качестве решения на помощь приходит идемпотентность. В статье выше рассказывается о том, как airbnb использует идемпотентность для реализации платежной системы с использованием rpc.

Инженеры делят каждый запрос, в контексте бекенда, на 3 фазы: pre-RPC, RPC and post-RPC. В pre-RPC фазе проверяется ключ и лочится ресурс по ключу, после чего вызывается RPC, а на фазе post-RPC происходит сохранение ответа. При этом, каждый зафейленый результат маркируется как retryable и non-retryable и эта информация отправляется клиенту для дальнейшей обработки. После рассказывается о клиентской части, причем автор отсылается к опыту страйпа. Описываются три свойства для обработки failed requests к идемпотентным серверам: consistency, safety и responsibility.

#how_it_works #payment #idempotency

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

Postgres webhooks with pgstream

Когда упоминается стриминг данных из части системы в другую (читай CDC), в голову приходят брокеры и события. Кроме этого, можно вспомнить о синхронной коммуникации по средствам http/rpc. Но о вебхуках, в контексте CDC говорят редко, поэтому сегодня статья о pgstream, благодаря которому можно стримить изменения в данных и через вебсокеты.

Для работы библиотеки придется поднять постгрес с wal2json, который сериализует изменения в json. После чего запустить pgstream. Важно: это не экстеншен для постгреса, а отдельный сервис на го, который кроме вебхуков еще умеет отправлять данные в эластик/OpenSearch и кафку. В посте найдете как работает сервис для вебхуков и какие данные передаются.

Подобная библиотека может использоваться как замена debezium, когда консьюмеры CDC не могут работать через кафку. Из плюсов – модульность продьюсеров (можно разные продьюсеры одновременно использовать), а из минусов – завязка на плагин для json сериализации и кафку, плюс мало звезд на гитхабе.

#data_streaming #cdc

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

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

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

Counting Billions of Content Usage at Canva

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

После описания проблемы рассказывается изначальный вариант системы, который состоял из трех основных частей: получения данных и хранения сырой информации, удаление дубликатов использования и отчищения данных и куска с инкрементацией каунтеров использования контента. Дальше возникла проблема с базой, которая стала ботлнеком. В качестве решения проблемы компания мигрировала dynamoDB для сбора сырых данных и объединила «чистку данных» и расчет количества использования контента в один ETL подобный сервис с OLAP. После чего рассказывается какие плюсы появились при использовании OLAP. В конце даются выводы и плюсы решения. Понравилось, что указаны новые проблемы, которые появились из-за решения.

#how_it_works

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

Architectural Retrospectives: the Key to Getting Better at Architecting

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

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

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

#decision_making #retro #ppl_managment

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

Testing Automation, What are Pyramids and Diamonds?

Возможно вы слышали о пирамиде тестирования: это когда в проекте много unit тестов, чуть меньше integration тестов и еще меньше e2e тестов. Вроде как, концепцию предложил Фаулер (возможно ошибаюсь), но, в спустя время, поняв, что не всегда тесты стоит писать по пирамиде, добавилось еще два подхода: test diamond и перевернутая пирамида.

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

#testing #testing_pyramid

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

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

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

How Netflix Content Engineering makes a federated graph searchable

Очередная статья из серии «как в компании X решили проблему Y». На этот раз продолжение истории с graphQL в нетфликсе, только вместо скейлинга – поиск по графу.

Напомню, что в нетфликсе сделали аналог энтити сервисов с graphql интерфейсом, где каждая сущность – отдельный сервис со своей командой разработки. В какой-то момент возникла проблема поиска на основе атрибутов других объектов (например, получить список текущих фильмов, где снимается Райан Рейнольдс). Т.е. как искать по графу (который структура, а не graphQL) в рамках распределенной системы. Ну и не трудно догадаться, что для этого сделали еще один сервис, который назвали studio search.

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

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

#how_it_works #graphql #searching

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

Здоровье кодовой базы

Лет 50-20 назад, люди придумывали метрики, которые помогали автоматически оценить «качество» кодовой базы. Одна из таких метрик – distance from the main sequence, которая говорит на сколько модуль полезен или проблематичен, основываясь на instability и abstractness метриках. Например, в джаве есть JDepend, который из коробки посчитает значение метрики.

В статье выше подробно объясняется, в чем смысл distance from the main sequence. Текст начинается с afferent и efferent coupling (набор инструментов для пхп опускаю), после чего рассказывается об instability, показывающей степень подверженности изменениям рассматриваемого класса при изменении зависимостей. После рассказывается о том, как добавив abstractness, получить плоскость, в которой можно определить «качество» модуля.

Может показаться, что подобные метрики архаика и нужны только в джаве/дотнете .Но так как метрика связана больше с каплингом, а не с кодовой реализацией, то нет никаких проблем перенести distance from the main sequence и похожие метрики на уровень выше и считать таким образом «качество» сервисов в распределенных системах.

#oop #code_metrics

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

Databases 101: ACID, MVCC vs Locks, Transaction Isolation Levels, and Concurrency

Данную ссылку сложно назвать полноценной статьей, скорее это набор определений вокруг баз данных. В данном случае автор затрагивает следующие темы:
- Виды баз данных (аналитические, OLTP, archive DB и real-time reporting) ;
- ACID. Расшифровывается каждая буква термина с примерами;
- Lock-based Concurrency Control, где рассказывается о четырех видах транзакций: read uncommitted/committed, repeatable reads и serializable;
- Multi-Versioned Concurrency Control (MVCC);
- Сравнении между lock-based и multi-versioned;

Если искали энтри поинт в работу баз данных, статья однозначно подойдет. Единственный минус – это не полноценный учебник, поэтому глубины DDIA или database internals книг не ждите. Ну и напомню, что автор специализируется на MMO играх, поэтому специфика информации и примеры отличаются от веба.

#db #acid

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

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

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

A crash course on building a distributed message broker like Kafka from scratch - Part 1

Считаю, что если хочешь понять технологию лучше – реализуй технологию самостоятельно. Так, сделав интерпретатор scheme, я лучше разобрался с lisp. Сегодня первая статья из серии (других нет пока), в которой автор, взяв go, реализует аналог kafka.

В начале объясняется главная идея кафки в виде «distributed commit log» и рассказывается, когда append-only log data structure могут быть полезны (кроме брокеров: аудит, эвент сорсинг, управление спорами). Понравилось, что упоминаются базы данных, в которых реализуется аналогичный append-only log, для фиксации транзакций. После, рассказывается о cluster node – отдельный инстанс кластера в распределенной системе. В случае кафки, нода хранит commit log. После показывается как написать ноду и лог и в конце запускается «простой» инстанс, который хранит и пишет данные в лог.

#how_it_works #kafka

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

How to deal with Technical Debt in legacy projects

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

В начале дается определение тех долга. Отдельно отмечу, что указывается, что тех долг – бизнесовая проблема и описываются пять бизнесовых причин, на которые влияет тех долг. После, автор дает определение легаси и после связывает легаси с тех долгом описывая, что такое «плохой» код. Дальше описываются подходы для «наблюдения/измерения» тех долга (DORA, DevX и другие метрики, плюс упоминается CodeScene). Плюс советы по уменьшению тех долга: тесты, документация, код ревью, стандарты и постоянный рефакторинг.

В конце самое интересное: на примере CodeScene показывается как анализировать кодовую базу проекта. Описывается как найти high interest rates, определить hotspots, работать с complexity trends. В качестве примера разбирается open source проект на dotnet

#tech_debt

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

API Versioning at Monite

Если продукт – API first (это не только HTTP API, но еще и библиотеки и прочее), то для развития системы придется задуматься, как развивать публичные интерфейсы. Вариантов два: либо никогда не менять или сделать сразу «идеальный» интерфейс, либо же версионировать. Сегодняшняя статья, как раз опыт решения проблемы изменения интерфейсов, через версионирование.

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

А как решение проблемы, автор сделал библиотеку для питона, которая реализует подход страйпа. Дальше описывается как происходит изменение между версиями, как работает чейн версий для эндпоинтов, работа с ошибками и поиск «опасных» мест в API. Каких-то откровений от текста не ждите, но если никогда до этого не работали с версионированием или хотите сделать аналогичную библиотеку для другого языка – статью стоит прочитать (и коментарии на хабре).

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

#api #versioning #sync_communication

Новый ответ: как перевести EventStorming модель в код

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

Поэтому сегодня расскажу, как сам бы мапил каждый стикер в код, если бы мне дали требования и готовый EventStorming.

Как перевести EventStorming модель в код

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

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

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

Марьяна попросила рассказать о том, что курс по анализу систем номинировали на образовательную премию. Если проходили курс, буду очень признательным, если поможете и проголосуете. А для тех, кто проголосовал проведем факультатив на тему систем и архитектуры (тему пока не придумали).

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

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

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

Historical Data in Databases. Audit Tables. Event Sourcing

Открытие 2024 года – блог автора, который писал об онлайн гейм девелопменте с фокусом на базы и структуры данных (статей из блога будет еще много в ссылках). Сегодня статья связанная с историческими данными – информацией о том, кто, что и когда сделал. Важно это, так как аналитика строится на исторической информации.

Статья рассказывает четыре темы, связанные с аудит данными:
- Что стоит и не стоит писать в аудит таблицы (как минимум, данные вокруг денег);
- Использовать одну общую таблицу или кучу разных. Тут описываются трейдоффы каждого из решений и упоминается event sourcing, как один из вариантов решений;
- audit_id поле, необходимое для определения записей. Какой id выбирать, зачем нужен и как использовать;
- Обрезка или перенос аудит записей. Что делать со старыми данными, как уменьшить размер БД;

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

#event_sourcing #audit

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

The Trillion Message Kafka Setup at Walmart

Статья из серии «как в компании Х сделали Y». Сегодня это волмарт (крупная торговая сеть) и проблема работы с большим количеством данных в консьюмерах кафки. Из-за размеров компании и спайков трафика (распродажи и другие случайные события), компании приходится тратить ресурсы на поддержку асинхронной коммуникации через кафку, причем по требованиям необходим SLA в 99.99%.

В начале текста описываются три основные проблемы (детально), которые возникли у инженеров при использовании кафки: проблема с ребалансировкой консьюмеров, появление сообщений которые ломают консьюмеры и высокая цена скейлинга связанная с каплингом между топиками. Основываясь на проблемах и требованиях, в компании решили сделать Messaging Proxy Service (MPS) – сервис прослойка между брокером и консьюмерами, через который можно синхронно взаимодействовать с кафкой из консьюмера и в случае проблем отправлять события в DLQ. Далее рассказывается как работает Messaging Proxy Service, из чего состоит и при чем тут kafka connect.

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

#how_it_works #kafka #events

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

Good programmers worry about data structures and their relationships

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

Автор начинает рассуждение с цитаты Линуса, о том, что «хорошие» программисты беспокоятся о структуре данных. Далее автор рассказывает историю из жизни, когда функция на 500 строк уменьшилась в 10 раз, потому что поменяли структуру данных. Ну а дальше приводятся цитаты из The Art of Unix Programming и сообщества unix, чтобы раскрыть мысль. Ну и в конце, автор, приводит идею, что подобный подход к проектированию от данных полезен и в карьерном продвижении в FAANG.

#conceptual_data_model #data_model

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

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

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

Trillions of Indexes: How Uber’s LedgerStore Supports Such Massive Scale

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

Сам LedgerStore – внутренняя разработка убера, которая хранит в себе фин операции и которая должна быть иммутабельной и хранить индексы для поиска нужной информации. Причем индексы делятся на три группы: strongly consistent, eventually consistent и time-range. В статье найдете объяснение каждого вида индекса, включая то, как индекс работает и где используется. А также информацию о управлении жизненным циклом индексов (через стейт машину), валидацию. В конце описывается процесс миграции убера со старого решения поверх DynamoDB на LedgerStore.

#how_it_works #finances #scalability

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

Kafka and Event Streaming — simple explanation

Изначально ожидал, что статья покажет на примере, как объяснить бизнесу необходимость использования event-driven коммуникаций. На деле текст оказался больше техническим (в моей голове), но при этом, статья не перестает быть полезной.

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

#event_driven #communications

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

Six Degrees of Kevin Bacon - Postgres Style

Лучше графов (по мнению канала) могут быть только графовые базы данных. При этом, каждый раз радуюсь, когда нахожу статьи связанные с применением графов в контексте постгреса или чего-то более распространенного чем neo4j и аналогов. Поэтому сегодня статья, в которой приводится пример решения задачи Six Degrees of Kevin Bacon с помощью постгреса и sql.

В начале статьи рассказывается о подготовке, а точнее о выгрузке базы IMDB (с примерами схем). Далее рассказывается о pgRouting, расширении для поиска маршрута, который будет использоваться автором поста как graph solver. Для этого делается таблица actor_graph в которой связывается актер, кино и другие актеры. А дальше, используя алгоритм дейкстры, считать количество edges между выбранным актером и Бейконом (перфоманс оставляем за скобками). В конце рассказывается о том, как recursive CTE использовать с pgRouting.

#graph #graphDB #psql

Новый ответ: как убедиться, что техническое решение нужно

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

Как убедиться, что техническое решение нужно?

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

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

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

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

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

Questions about Team Topologies

Team Topologies (ТТ) – подход к проектированию систем, основанный на социальном аспекте (читай командах). При этом, из подобных подходов, чаще упоминается в постах/книгах последних пяти лет. Сегодняшний текст от автора другого подхода, основанного на architecture layering model, в котором выложена дискуссия с автором ТТ.

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

Если хотите глубже разобраться в ТТ или управления командами – стоит ознакомиться.

#team_topologies #team_managment

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

How Stripe Scaled to 5 Million Database Queries Per Second

В 2023 году страйп обрабатывал 5 миллионов ДБ запросов при SLA в 99.999. Такие показатели стали возможны благодаря горизонтальному скейлингу, которое стало возможно благодаря личному DBaaS, которое назвали DocDB. Статья выше как раз описывает работу DocDB.

Начинается текст с причин, почему так пришлось с DBaaS заморачиваться. Страйп хотел получить availability, durability и performance от бд, оптимизированные запросы в бд, горизонтальную масштабируемость, multi-tenancy с квотами и надежную защиту. Для этого и сделали DocDB, что привело к возможности работать с тысячами шаров и поддержкой 10к различных запросов. Дальше рассказывается как docDB работает: как приложения получают данные, как данные хранятся между шардами и как данные мигрируются между шардами. Причем, о миграции данных в шести шагах оставшаяся треть статьи.

#how_it_works #scalability #db

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

A Web API Design Methodology

Наблюдаю, что тема проектирования API популярная в кругу аналитиков и разработчиков. Напомню, что в 2021 году упоминал книгу по дизайну API (спустя три года считаю, что это лучшая книга по проектированию API). Сегодняшняя ссылка еще один подход к тому, как проектировать API (в данном случае http), которая представляет семь шагов проектирования API, описанные в RESTful Web APIs книге.

Сами шаги выглядят следующим образом:

- Обозначение данных, необходимых в API;
- Изображение state diagram, чтобы понять какие данные и как будут использоваться;
- Согласование «магических» названий полей (когда read list становится «collection from IANA Link Relation Values»);
- Определение способа передачи данных (http, json, xml, etc);
- Создание семантического профиля;
- Реализация API;
- Паблишинг API документации;

#http_api

——— одной строкой ———

- Автор C4 model обновил сайт. Теперь доступна нормальная документация и «динамический» выбор инструментов, на основе чекбоксов;

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

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

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

How Netflix Manages 238 Million Memberships?

Очередная статья о том, как в компании X сделали Y. Сегодня это membership платформа нетфликса, которая обслуживает 238 миллионов пользователей. А «цикл» работы сводится к пяти шагам: регистрация, изменение планов подписки, оплата ( с решением проблем) и отмена/остановка подписки.

Автор начинает статью с развития membership платформы: от двух сервисов (один с подписками, второй с ценами) к системе из 10 сервисов, кафки, кассандры, apache spark и CockroachDB. После описывается процесс регистрации, трекинга действий пользователя. В конце описывается тех стек и как реализован observability.

#how_it_works #kafka

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

How a Single Line of Code Brought Down a Billion Dollar Rocket

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

- Ariane 5 (ракета европейская). Обошлось без погибших, но потеряли два геостационарных спутника связи. Причиной послужил баг в системе наведения, который отвечал за курс ракеты;
- SQLException который остановил 11000 полетов;
- Катострофа Boeing 737 MAX. Ошибки в программном обеспечении, которое должно было помочь пилотам с управлением самолета;

В конце каждой истории можете посмотреть референсы, которые использовал автор. Также понравилось, что автор дает рекомендации по каждому случаю. Хотя важно напомнить, что рекомендации для ракет/самолетов и стартапов в фазе поиска прибыльной гипотезы будут отличаться (так как требования к системам отличаются).

#failures #systems

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

Failure testing Kafka

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

Сначала описывается контекст, в котором компания использовала кафку, но возникла цель увеличить durability и resilience системы. Для этого подняли кластер из трех брокеров, настроили репликацию и acks=all и реплику для топиков. Это помогло в ситуации, когда 1 из 3 брокеров выходили из строя, но когда падали сразу два брокера – возникали ошибки. Чтобы избежать таких ситуаций, автор решил описать failure scenarios. Для чего, в тексте описываются ключевые места, в которых могут возникнуть проблемы. После, в тексте, описываются возможные сценарии отказов и ожидаемое поведение кафки. После чего описываются способы тестирования сценариев. В конце рассказывается к чему пришли инженеры и описываются выводы.

Важно: статья больше о кишках кафки, т.е. статья будет интересна SRE и инфраструктурным командам, чем разработчикам (исключение, если интересуетесь chaos engineering). Но если интересен deep dive – почему бы и нет.

#kafka #testing #chaos_engineering

Новый ответ: как пользуюсь обсидианом

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

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

Как и почему использую Obsidian

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

В ответе не найдете последовательных шагов о том, как взяв обсидиан стать мастером продуктивности. Или рассказов о том, как используя zettelkasten стать вторым Луманом и писать по 10 книг в час. Вместо этого затронул темы целеполагания и стиля ведения заметок. Рассказал о том, зачем и как пользуюсь обсидианом для создания контента.

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

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

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

It’s Time to Rethink Event Sourcing

Event sourcing (es) упоминался раз пять в канале, даже сохранились старые записи стримов о паттерне. Сегодня статья рассуждение о том, куда es может развиваться. Сразу скажу, статья довольно дискуссионная и стоит самому решать как к ней относиться. Главная идея статьи (как сам понял) – вместо использования чистого es, который каждый раз пишется с нуля, взять Change Data Capture паттерн, которого, со слов автора, хватит в 95% случаев.

В начале автор перечисляет ситуации, где es может оказаться полезным. После приводит два идейных примера: bank ledger и version control system (в конце объясню почему пример так себе). После этого перечисляются проблемы: сложность с парадигмой, eventual consistency, сложности с реализацией и так далее. После подвязывает Change Data Capture паттерн и рассказывает как использовать, чтобы получить плюсы хранения изменений, не усложняя систему.

Единственное, не считайте git event sourcing системой. Идейно похожей – да, но это не «каноничная реализация» так как коммит не хранит дельту изменений, а tree + blob (следующая статья об этом).

#event_sourcing #cdc

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

Creating a Git commit: The Hard Way

В канале уже упоминал статьи с хардкорными примерами использования гита. Сегодня статья о том, как сделать коммит в гите не используя git commit команду.

В начале автор рассказывает о состояниях файлов в гите и о разделах гит проектов. После объясняет разницу между blob, tree и commit объектами в гите (хотите одробнее – советую документацию). После начинается магия, в которой создается блоб через hash-object, tree объект через update-index и write-tree, а коммит через commit-tree.

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

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

#git #how_it_works

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

Just use Postgres

Давайте договоримся на берегу: я люблю постгрес (с mysql/oracle не сложилось) и, по дефолту, выберу pg для нового проекта без особых требований к данным. Но если понадобиться и будут на это причины – с радостью выберу любую другую базу под требования и ограничения, проектируемой системы. Поэтому со статьей согласен только на половину.

Статья состоит из объяснения, почему определенный вид бд не подходит как primary bd для хранения данных. Рассматриваются следующие технологии (хоть и навалено все в кучу):
- sqlite
- DynamoDB, Cassandra, MongoDB
- Valkey (замена редиса)
- Datomic (тут посмеялся)
- XTDB (о такой бд не слышал, будет что почитать)
- Kafka (пожалуйста, почитайте если планируете в кафке данные держать)
- ElasticSearch
- MSSQL или Oracle DB
- MySQL
- векторные бд
- Google Sheets (хоть автор добавил для смеха, но лучше таблиц ничего не придумали)

Статью стоит рассматривать в контексте «начинаю проект новый и не знаю какую бд выбрать». Если проект большой и одной бд не добиться нужных свойств (либо изначально понятно, что pg не закроет характеристики) – можно не читать.

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

#data_bases #psql

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

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

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

An example of example-driven development

На статью наткнулся, пока разбирался с Glamorous Toolkit. Идея в том, что автор решил отойти от тестов в сторону примеров для валидации того, что система работает как надо (тут хочется сослаться на классику в виде Readme Driven Development). Одной из причин, почему отдается предпочтение примерам – примеры могут быть составлены из других примеров (это когда сложный пример разбивается на набор примеров из которых сложный пример состоит). Дальше автор на примерах (простите), показывает как подход с example-driven development помогает в написании и понимании кода. Плюс показывает как gtoolkit помогает динамически «играть» с примерами и генерировать документацию.

Выглядит как еще одна попытка заменить валидацию системы на что-то «удобнее». Для кругозора статья отличная, но возникают вопросы, чем edd лучше, чем написание документации с примерами. Использовать данный подход в проектах – решать только вам, но, пожалуйста, сверяйтесь с требованиями перед тем, как выкатывать код в продакшен (tdd, bdd, readme dd, и так далее).

#testing #system_validation

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

How to discover all the data sources, low-fuss way

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

Чтобы решить эту проблему и помочь в изучении системы, автор предлагает «фреймворк» состоящий из пяти вопросов:
- Q1. Where is it stored?
- Q2. Is it a copy of another dataset?
- Q3. Why did we decide to create it?
- Q4. How is it designed?
- Q5. Where is it documented?

В статье раскрывается каждый вопрос, даются советы и объясняется зачем вопрос нужен. Если встречались с проблемой, связанной с пониманием данных в системе и не знали что делать – однозначный мастхев.

#system_analysis #data_managment

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

10 Kubernetes Cost Optimization Techniques

«Пора уменьшать косты» – фраза, которая возникает в компании, как только она перестает быть стартапом, либо когда инвестиции начинают заканчиваться, а проекта все еще нет. При этом, общей стратегии не видел, каждая компания делает как знает/чувствует. Либо компания не только знает о FinOps, и использует подход в работе, но тогда статью можно пропустить. Поэтому мн нвятся подобные посты, из которых можно сделать полноценную стратегию для уменьшения костов. Сегодня о кубере и 10 советов, куда смотреть, чтобы платить меньше.

Автор делит стратегии на 3 группы:
- Pre-Deployment Strategies;
- Post-Deployment Strategies;
- Ongoing Improvements;

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

#finops #cost_managment #k8s

Новый ответ: уменьшаем размер событий в асинхронной коммуникации

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

Уменьшаем размер событий

В ответе затронул следующие темы:
- Event granularity и state (fact) vs delta (action) events. Рассказал что есть что. Плюс связал концепции, что бы оптимальнее выбирать размер события в системе;
- Описать некоторые паттерны, которые могут потенциально помочь: event notification, message chunking и другие;
- Сделал decision flow chart в конце, со всеми описанными темами;

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

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

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

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

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

Cloudflare’s Trillion-Message Kafka Infrastructure: A Deep Dive

Текст о взаимоотношениях между Cloudflare и кафкой, которые начались в 2014 году. А не так давно, компания обработала 1 триллион сообщений (это 10^12). На текущий момент Cloudflare управляет 14 кафка кластерами состоящим из 330 нод по всему миру.

Изначально компания сделала монолит на пхп и столкнулась с проблемами: высокий каплинг и проблемы с реализацией ретраев. Для решения решили взять кафку со стандартизацией: добавили схему реджистри, message bus client library (которая мапила протобаф схему на топик, что добавляет проблем). После этого, компания начала выделять паттерны, используемые с кафкой. Интересная идея, что после инженеры смогли сделать генерацию сервиса реализующий нужный паттерн. Дальше рассказываются проблемы, которые возникли у компании: visibility, проблемы с алертами и проблемы с email.

#how_it_works #kafka

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

How Netflix Scales its API with GraphQL Federation (Part 1)
How Netflix Scales its API with GraphQL Federation (Part 2)

Две статьи от нетфликса и того, как используется GraphQL federation в компании.

В первой статье речь идет о Studio Edge – части системы, которая помогает в создании контента от компании. В качестве интерфейса команда взяла graphQL, что привело к проблемам. Но инженеры решили, что раз с микросервисами получилось, то с graphQL тоже так выйдет, с чем помог GraphQL Federation. Дальше рассказывается, как добавлялся гейтвей, к которому подключались сервисы в виде отдельных доменных графов и сервис со схемами. После рассказывается о специфике: композиции схемы, query planning, entity resolver и так далее. В конце статьи найдете картинку с эволюцией системы.

Вторая статья рассказывает, что происходило после. Доведя решение с graphQL до ума, компания начала вкладываться в operational штуки. В тексте рассказывается как добавлялся инструментарий для котлина, проводилось обучение. Понравилось, что описывается процесс верификации graphql схемы. Также рассказывается об observability и распределенную трассировку. Последние две темы касаются секьюрити и architecting for failure.

#how_it_works #graphQL

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

Building and scaling Notion’s data lake

С ковида, количество пользователей ноушена только растет, из-за чего компании пришлось думать, как хранить данные для аналитики. Изначально, данные хранилось в одном инстансе постгреса, который переделали на 420 логических шарда. Статья как раз рассказывает о том, как компания решала проблему с использованием данных для аналитики, обучения AI, поиска и так далее).

Сначала решили сделать ETL, который использовал Fivetran для репликации Postgres WAL в Snowflake. У такого подхода возникли проблемы: масштабирование, куча коннектов которые надо обслуживать, скорость данных, проблемы с обработкой данных в ETL. Все это привело к тому, что команда решила сделать собственный даталейк. Реализовали через CDC и кафку (debezium) и клали данные в s3. В s3 данные обогащаются нужным образом и после попадают в нужную часть системы (аналитика, обучение AI). При этом, в статье объясняются причины выбора каждой технологии и решения. В конце дается итог решения с плюсами (минусов, к сожалению, не написали).

Перевод на русский

#how_it_works #etl #datalake

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

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

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

Inside Shopify’s Modular Monolith

Еще одна статья о том, как компания решает технические проблемы (подобных статей накопилось много, поэтому на следующей неделе будет спецвыпуск). Сегодня речь пойдет о том, как в шопифае сделали модульный монолит. Напомню, что компания сделала один из самых больших ruby on rails монолитов в мире.

Ничего технического от текста не ждите, так как статья – текстовое интервью одного из principal engineer. Интервью можно разбить на четыре части:
- Интро, в котором рассказывается о госте и что принципалы в компании делают;
- Описание тех стека шопифая и упоминание, что кор разрабы руби, рельсы, mySQL работают в компании. Плюс упоминается «pods architecture», благодаря которой магазины шардируются как по данным, так и по нагрузке;
- Рассказ о модульном монолите, но тут лучше прочитать оригинальный пост в tech блоге компании;
- как происходит «operational»: тестирование (понравилось, что описали пайплайн), деплоймент (собственный инструмент), обработка ошибок;

#how_it_works

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

How to Share Data Between Microservices on High Scale

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

Автор рассматривает три варианта:

- синхронный запрос;
- асинхронное событие;
- аналог event notification, когда сначала информация передается асинхронно, а потом делается синхронный запрос для получения консистентной информации;

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

#communications

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

The Problem with OpenTelemetry

Способов реализации распределенной трассировки много, но на слуху – OpenTelementry, у которого есть как плюсы, так и минусы. Как раз о минусах сегодняшняя статья от основателя Sentry, который рассказывает в чем проблема стандарта (спойлер: стандарт перестал решать одну конкретную проблему) и как автор хотел бы видеть мир трассировок. Сразу предупреждаю, статья не практическая, а скорее «мысли в слух».

В начале рассказывается предыстория, о том, как появился OpenTracing, который в последующем стал OpenTelementry. При этом, как начиная со стандартизации трассировки, инженеры начали придумывать стандарты для логов и метрик, что привело к главному минусу – отсутствие vision и leadership. Из-за чего стандарт перестал быть “завершенным” и не пониманию автора, какие проблемы решает стандарт.

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

#observability #open_telementry

Новый ответ: планируем долгие и большие проекты

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

Как слежу за большими проектами

В ответе затронул следующие темы:
- Почему project management инструменты меня запутывают и заставляют грустить;
- Почему список задач не сработает для проектов на 6+ месяцев и как, используя графы, сделать «концептуальный» план работ. Благодаря которому можно посчитать ресурсы чуть лучше, чем «пальцем в небо»;
- Как следить за тем, что происходит в проекте на этапе имплементации
- Как находить проблемы в планировании: либо до начала работ, либо ретроспективно разбираться, что и где пошло не так;

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

Собираю темы для новой версии АА курса

Привет!

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

Какие у вас возникли проблемы, после окончания курса?

Это могут быть как проблемы технические (не знаете как что-то сделать), так и проблемы, которые возникли (взяли схему реджистри, а что дальше - не понятно), так и социальные (предложили решение, а команда завернула и не понятно как объяснить)

Буду рад комментариям, ибо это сильно поможет в работе над новой версией курса.

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

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

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

How PayPal Scaled Kafka to 1.3 Trillion Daily Messages

Статья из серии: «Как Х реализован в Y?», в этот раз информация о том, как PayPal скейлит кафку, чтобы обрабатывать 19 миллионов mps (message per second). Изначально рассказывается почему и когда выбрали кафку, а именно с 15 года, для стриминга данных и интеграций. На текущий момент в компании 1500 брокеров и 20к топиков с SLA в 99.99%. Ну и перечисляется некоторые примеры использования (особенно заинтересовал risk detection).

Дальше рассказывается как инфраструктурно крутится кафка, заинтересовало разделение на distributed data centers и security zones. Первое – физический объект с инфрой, а security zone – логический кусок в рамках дата центра для изоляции доступов (например зона для обработки конфиденциальных платежных данных). Для синхронизации данных используется MirrorMaker. Дальше рассказывается о «PayPal’s Kafka Landscape», наборе элементов используемых для разворачивания и operational инфраструктуры. Сюда входит сервер конфигурации, штуки для обсервабилити, библиотеки для клиентов, ACLs и так далее. В конце упоминается как происходит автоматизация вокруг брокера: добавление топика, настройка репликации и так далее.

#how_it_works #kafka

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

Good Product Team / Bad Product Team

Неформатная для канала ссылка, но может быть кого-то заинтересует, особенно если любите team topology или user story mapping. Сама статья сводится к набору утверждений, сделанных автором после опыта работы с «many of the very best technology product teams» и другими командами, благодаря чему появились эти утверждения. Т.е. каждый пункт эмпирический (на всякий случай предупреждаю). В тексте 17 пунктов, но без того, как сделать хорошую продуктовую команду.

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

#product_managment #ppl_managment

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

CAP Theorem for Developers: What It Is and How It Affects Distributed Systems

О CAP теореме уже упоминались статьи в канале (включая статьи, почему пора идти дальше). Сегодняшняя ссылка зацепила объемом материала вокруг теоремы.

В начале автор рассказывает о теореме (берем consistency, availability и partition tolerance, а после оставляем два варианта из трех). Причем подробно рассказывая о каждом из трех вариантов и трейдофах выбора, понравился список пунктов, о которых стоит подумать при выборе подхода. После приводятся примеры реальных инструментов, которые реализуют AP, CP, CA варианты выбора (в список попали: динамо, Google’s Spanner, кассандра и блокчейн). В конце описывается чеклист по проектированию систем на основе CAP теоремы и приводятся альтернативные модели (без подробностей): PACELC, BASE, CAP Twelve Years Later.

Если хотите за одну статью разобраться с теоремой – мастрид этого года.

#CAP

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

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

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

The Many Facets of Coupling

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

Сначала автор дает определение связанности (через изменения элементов). После чего рассуждает о том, что значение coupling не может быть бинарно, а задача не просто избавиться от связей, а понять какие связи присутствуют и как связи будут влиять на систему. А после вводит понятие «многомерности»: пространство разных видов связей, которые встречаются в системах. Далее рассматриваются 8 видов coupling: technology, location, topology, data format, semantic, conversation, order и temporal. Каждая связь подробно рассматривается в тексте, плюс присутствуют картинки для лучшего понимания.

#coupling

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

How we improved push processing on GitHub

Статья из серии: «Как Х реализован в Y?». В этот раз, гитхаб и его система push-а в репозиторий. Вроде кажется, что сделав push, изменится репозиторий. Но на деле возникает примерно 60 побочных действий, например: публикация github pages, изменение флоу в actions (или запуск CI/CD), вызываются вебхуки и так далее.

Изначально, код работал на бекграунд процессинге в рельсе, где на каждый пуш создавалась джоба «оркестратор» RepositoryPushJob, которая последовательно запускала шаги обработки. При этом, джоба стала большой, из-за чего упал maintainability/modifiability, появился лишний каплинг, появились проблемы с ретраями и ухудшился latency. Как решение – взяли кафку и разбили джобу на набор консьюмеров (подробнее в тексте). По итогу получили улучшение reliability, наблюдаемости и решили проблемы с maintainability/modifiability.

#how_it_works #github #push_processing

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

Experience CozoDB: The Hybrid Relational-Graph-Vector Database

Если давно следите за каналом, знаете, что я люблю концепцию графовых и векторных бд. Сегодняшняя статья собрала бинго: документация к релизу релиционно-графово-векторной БД (если что, там 0.6 релиз).

Преимущества базы:
- реализацию векторного поиска написали сами на расте (нужно для поддержки MVCC и disk-based индексов). При этом присутствует транзакционность;
- работает быстрее pg-vector (по словам авторов);
- Если правильно идею понял, то можно юзать векторы не как отдельный поиск, а в купе с реляционным поиском;

Если хотите больше о базе почитать (включая синтаксис), то лучше ознакомиться с tutorial (для выполнения запросов можно воспользоваться wasm демо). Релиз, по ссылке выше, описывает две темы:
- как реализован векторный поиск в бд (объясняется через графы)
- пара примеров использования функционала (холиварные, о чем автор упоминает): knowledge management, использование бд как «памяти» для llm моделей, улучшение RLHF процедуры;

#db #vector_db #graphs

Канал возвращается из отпуска с новой рубрикой

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

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

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

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

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

В качестве ответа найдете информацию о data model и трех перспективах работы с данными: концептуальную, логическую и физическую. Рассказал о том, как сделать концептуальную схему и о трех способах визуализации уже существующей схемы БД.

Уверен, что что-то пропустил. Если используете другие способы визуализации – пишите в комментарии, дополню ответ.

Хвастаюсь! Это первые отзывы после недели обучения на третьем потоке «Анализа Систем».

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