Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Code sharing - Decision Node
В распределенных системах (например микросервисах) возникает вопрос, как шарить одинаковый код, или одинаковый алгоритм между сервисами. Существует как минимум 2 варианта как сделать это: копировать код или сделать абстракцию, которая будет шарится (библиотека, сервис, сайдкар, etc). При этом, у каждого из подходов есть свои плюсы и минусы.
Статья выше как раз рассматривает способы шаринга кода/алгоритмов в распределенной системе. Для каждого варианта присутствует пояснение, картинка, плюсы-минусы (не явно) и доп информация с возможными рисками (rolling out updates для копипасты кода, выбор между количеством зависимостями и размерами библиотеки, у сервисов трейдоффы описываются, а у сайдкара риски и как реализовывать).
#distributed_systems #code_sharing
—————————————
Designing Resilient Systems: Microservices Architecture Patterns Explained
Статья – сборная солянка на тему «паттернов» в распределенных системах. Паттерны которые затрагиваются в тексте:
- Load balancer, service registry и как это между собой работает;
- Circuit Breaker и принцип работы паттерна (почему-то с api gateway);
- EDA, что это, зачем и как работает;
- Database per Service подход, какие у него плюсы и минусы;
- Централизованная конфигурация сервисов;
- BFF, CQRS, SAGA паттерн, Bulkhead паттерн;
Для каждой из описанных тем присутствует описание, плюсы минусы, где-то трейдофы, где-то примеры библиотек. Важно понимать, что статья обзорная и тут нет хардовой конкретики по каждому паттерну. Скорее это статья которая поможет найти собственные белые пятна (или «i know what i don't know») по терминам, инструментам и паттернами, которые в будущем можно самостоятельно изучить.
#distributed_systems
—————————————
How Slack Built a Distributed Cron Execution System for Scale
Статья из серии «как сделали X в <companyname>». В этот раз история о том, как слак реализовала скедулер в виде cron-a. Нужен крон для отправки `/remind` пользователям, отправки email нотификаций и клинапов базы для улучшения перфоманса. При этом, при не распределенном варианте крона возникли проблемы с maintainability тасок, со скейлингом и единой точкой отказа джоб.
Из-за этого слак решил сделать распределенный крон, который состоит из 3 частей:
- Scheduled Job Conductor – «оркестратор» задач, который по API притворяется дефолтным кроном;
- The Job Queue – штука, поверх кафки, которая выполняет задачи от кондуктора, предварительно помещая их в редис;
- Vitess Database Table for Job Tracking – персистанс для борьбы с дубликатами и отслеживанием статусов джоб. Сделан в угоду reliability системы;
В статье найдете подробное описание реализации и проблем. Единственное, чего не понятно (может я слепой) – почему не взяли готовое решение.
#how\it_works
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Code sharing - Decision Node
В распределенных системах (например микросервисах) возникает вопрос, как шарить одинаковый код, или одинаковый алгоритм между сервисами. Существует как минимум 2 варианта как сделать это: копировать код или сделать абстракцию, которая будет шарится (библиотека, сервис, сайдкар, etc). При этом, у каждого из подходов есть свои плюсы и минусы.
Статья выше как раз рассматривает способы шаринга кода/алгоритмов в распределенной системе. Для каждого варианта присутствует пояснение, картинка, плюсы-минусы (не явно) и доп информация с возможными рисками (rolling out updates для копипасты кода, выбор между количеством зависимостями и размерами библиотеки, у сервисов трейдоффы описываются, а у сайдкара риски и как реализовывать).
#distributed_systems #code_sharing
—————————————
Designing Resilient Systems: Microservices Architecture Patterns Explained
Статья – сборная солянка на тему «паттернов» в распределенных системах. Паттерны которые затрагиваются в тексте:
- Load balancer, service registry и как это между собой работает;
- Circuit Breaker и принцип работы паттерна (почему-то с api gateway);
- EDA, что это, зачем и как работает;
- Database per Service подход, какие у него плюсы и минусы;
- Централизованная конфигурация сервисов;
- BFF, CQRS, SAGA паттерн, Bulkhead паттерн;
Для каждой из описанных тем присутствует описание, плюсы минусы, где-то трейдофы, где-то примеры библиотек. Важно понимать, что статья обзорная и тут нет хардовой конкретики по каждому паттерну. Скорее это статья которая поможет найти собственные белые пятна (или «i know what i don't know») по терминам, инструментам и паттернами, которые в будущем можно самостоятельно изучить.
#distributed_systems
—————————————
How Slack Built a Distributed Cron Execution System for Scale
Статья из серии «как сделали X в <companyname>». В этот раз история о том, как слак реализовала скедулер в виде cron-a. Нужен крон для отправки `/remind` пользователям, отправки email нотификаций и клинапов базы для улучшения перфоманса. При этом, при не распределенном варианте крона возникли проблемы с maintainability тасок, со скейлингом и единой точкой отказа джоб.
Из-за этого слак решил сделать распределенный крон, который состоит из 3 частей:
- Scheduled Job Conductor – «оркестратор» задач, который по API притворяется дефолтным кроном;
- The Job Queue – штука, поверх кафки, которая выполняет задачи от кондуктора, предварительно помещая их в редис;
- Vitess Database Table for Job Tracking – персистанс для борьбы с дубликатами и отслеживанием статусов джоб. Сделан в угоду reliability системы;
В статье найдете подробное описание реализации и проблем. Единственное, чего не понятно (может я слепой) – почему не взяли готовое решение.
#how\it_works
Запустился третий поток курса по анализу систем и принятию технических решений
Привет!
В течении месяца будем учиться анализировать системы -- выбирать элементы системы, определять связи и свойства. Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview - курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия;
Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать информацию вокруг темы в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов. При этом, каждый раз оказывается, что ситуация меняется, из-за чего приходится переосмыслить подходы и инструменты. В итоге, пройдя все сложности, получим оптимальную для реализации системы, удовлетворяющую всем требованиям бизнеса и других заинтересованных лиц.
Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
Полная программа и половина первого урока - на странице курса. Начало 13 июня, до 1 июня действует промокод 2PENALYSIS на 10% скидки.
Марьяна отдельно попросила указать: следующий поток не раньше, чем через полгода. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).
Привет!
В течении месяца будем учиться анализировать системы -- выбирать элементы системы, определять связи и свойства. Благодаря чему можно обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview - курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия;
Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать информацию вокруг темы в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. По сути, это выжимка моего опыта и структурирование кучи тем вокруг одной проблемы связанной с анализом систем и принятием технических решений.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов. При этом, каждый раз оказывается, что ситуация меняется, из-за чего приходится переосмыслить подходы и инструменты. В итоге, пройдя все сложности, получим оптимальную для реализации системы, удовлетворяющую всем требованиям бизнеса и других заинтересованных лиц.
Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики посмотрели на чужие решения и чужой опыт (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
Полная программа и половина первого урока - на странице курса. Начало 13 июня, до 1 июня действует промокод 2PENALYSIS на 10% скидки.
Марьяна отдельно попросила указать: следующий поток не раньше, чем через полгода. Платить картой любой страны, от юрлица и долями. Все еще действует образовательная лицензия школы (для налогового вычета).
Привет!
Федя предложил пообщаться на тему архитектуры и систем, надобности архитекторов и как принимать технические решения. А также ответить на вопросы, включая вопросы по курсам. И хочется верить, что холивар, связанный с system design interview, пройдет мимо стрима 🥲
Стрим будет в тг канале Феди (@pmdaily) в четверг, 30го мая (завтра), в 16 по мск.
Федя предложил пообщаться на тему архитектуры и систем, надобности архитекторов и как принимать технические решения. А также ответить на вопросы, включая вопросы по курсам. И хочется верить, что холивар, связанный с system design interview, пройдет мимо стрима 🥲
Стрим будет в тг канале Феди (@pmdaily) в четверг, 30го мая (завтра), в 16 по мск.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Preventing and Fixing Bad Data in Event Streams — Part 2
Как неоднократно упоминал, главная проблема асинхронных коммуникаций – фикс фиговых данных. Что бы этого не допустить, приходится усложнять решения, но даже такой подход не помогает со 100% вероятностью. Из-за чего, стоит помнить о способах решения проблем, если с данными что-то пошло не так и с этим поможет сегодняшняя статья.
Автор начинает статью с объяснения принципов дизайна событий. Для этого рассказывается о двух видах событий: state и action (если от меня слышали о стриминг и бизнес событиях – это одно и тоже). Первые передают состояние на момент времени, вторые говорят о произошедшем действии. Дальше автор рассказывает больше о стейт событиях, как они могут быть сжаты и как из них может быть получено состояние в бд. Дальше говорится о том, как compacting может помочь избавится от разовых, некорректных данных (и конечно говорится о kafka connector).
После чего, рассказывается о том, как фиксить данные в action событиях. Для этого предлагается использовать компенсаторную логику (undo), либо ретраи для событий.
#async_communications #events #error_handling
—————————————
You probably don’t need microservices
Автор статьи описывает опыт работы с микросервисами с другой стороны. А именно с позиции проблем. Плюсом текста, является то, что автор сразу говорит, что технология ок. А после, рассказывает историю, как не зная ничего о микросеривсах, была сделана распределенная система, где главным драйвером распределенности были отличия в скейлинге разных частей проекта (о похожем подходе выноса сервисов как раз рассказываю в курсе, но только не ограничиваясь скейлингом).
Начинается текст с 4 примеров, которые показывают, что архитектурный стиль используют скорее как серебряную пулю, чем осознанно: слишком много сервисов, связанность высокая, сложность системы неоправданно увеличивается, ну и использование сервисов в стартапах просто потому что модно. После чего автор приводит примеры светил индустрии (Scott Hannen и DHH), которые подтверждают примеры из начала статьи. В конце найдете вывод, что микрсоервисы имеют цену и важно помнить, что не всегда профит от стиля будет выше, чем цена, которую придется заплатить. Ну и принимайте прагматичные решения.
#distributed_systems #microservices
—————————————
What does idempotent mean in software systems?
Тут важно сразу обозначить: статья не об идемпотентности, а скорее о транзакционности в контексте работы бд и отправки событий в брокер.
Автор начинает рассказ с идемпотентности и объясняет, что это когда отправка одной и той же команды приводит к выполнению действия один раз. Дальше автор говорит про важность идемпотентности и, в качестве примера, приводит ситуацию, когда надо сохранить пользователя в бд и после отправить событие, что появился новый пользователь.
В этот момент текст от идемпотентности переходит к транзакционности. Связанно это с ситуациями, которые возникают когда событие не отправилось, а запись создавалась, либо когда событие отправилось, но записи в бд нет. Как решение проблемы транзакционности отправки событий автор предлагает рассмотреть outbox pattern – подход, при котором события пишутся в основную базу (обычно это
#outbox_pattern #consistency
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Preventing and Fixing Bad Data in Event Streams — Part 2
Как неоднократно упоминал, главная проблема асинхронных коммуникаций – фикс фиговых данных. Что бы этого не допустить, приходится усложнять решения, но даже такой подход не помогает со 100% вероятностью. Из-за чего, стоит помнить о способах решения проблем, если с данными что-то пошло не так и с этим поможет сегодняшняя статья.
Автор начинает статью с объяснения принципов дизайна событий. Для этого рассказывается о двух видах событий: state и action (если от меня слышали о стриминг и бизнес событиях – это одно и тоже). Первые передают состояние на момент времени, вторые говорят о произошедшем действии. Дальше автор рассказывает больше о стейт событиях, как они могут быть сжаты и как из них может быть получено состояние в бд. Дальше говорится о том, как compacting может помочь избавится от разовых, некорректных данных (и конечно говорится о kafka connector).
После чего, рассказывается о том, как фиксить данные в action событиях. Для этого предлагается использовать компенсаторную логику (undo), либо ретраи для событий.
#async_communications #events #error_handling
—————————————
You probably don’t need microservices
Автор статьи описывает опыт работы с микросервисами с другой стороны. А именно с позиции проблем. Плюсом текста, является то, что автор сразу говорит, что технология ок. А после, рассказывает историю, как не зная ничего о микросеривсах, была сделана распределенная система, где главным драйвером распределенности были отличия в скейлинге разных частей проекта (о похожем подходе выноса сервисов как раз рассказываю в курсе, но только не ограничиваясь скейлингом).
Начинается текст с 4 примеров, которые показывают, что архитектурный стиль используют скорее как серебряную пулю, чем осознанно: слишком много сервисов, связанность высокая, сложность системы неоправданно увеличивается, ну и использование сервисов в стартапах просто потому что модно. После чего автор приводит примеры светил индустрии (Scott Hannen и DHH), которые подтверждают примеры из начала статьи. В конце найдете вывод, что микрсоервисы имеют цену и важно помнить, что не всегда профит от стиля будет выше, чем цена, которую придется заплатить. Ну и принимайте прагматичные решения.
#distributed_systems #microservices
—————————————
What does idempotent mean in software systems?
Тут важно сразу обозначить: статья не об идемпотентности, а скорее о транзакционности в контексте работы бд и отправки событий в брокер.
Автор начинает рассказ с идемпотентности и объясняет, что это когда отправка одной и той же команды приводит к выполнению действия один раз. Дальше автор говорит про важность идемпотентности и, в качестве примера, приводит ситуацию, когда надо сохранить пользователя в бд и после отправить событие, что появился новый пользователь.
В этот момент текст от идемпотентности переходит к транзакционности. Связанно это с ситуациями, которые возникают когда событие не отправилось, а запись создавалась, либо когда событие отправилось, но записи в бд нет. Как решение проблемы транзакционности отправки событий автор предлагает рассмотреть outbox pattern – подход, при котором события пишутся в основную базу (обычно это
events таблица), а после, в отдельном процессе, отправляются в брокер. После чего автор описывает пример реализации outbox pattern на чем-то похожем на дотнет.#outbox_pattern #consistency
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Introducing the RIG Model - The Puzzle of Designing Guaranteed Data-Consistent Microservice Systems
При переходе на сервисы возникает проблема консистентности данных. мало того, что strong consistency заменяется на eventual consistency, так еще и eventual consistency не гарантируется, особенно когда появляется saga pattern. Связанно это с тем, что так или иначе придется столкнуться с dirty read, lost update и так далее.
Для решения проблем консистентности, авторы статьи, придумали RGI модель, которая расшифровывается как «Reversible, Irreversible, Guaranteed» и по сути, реализует SAGA паттерн с некоторыми условиями. Было интересно увидеть, что RIG вдохновлен event storming. А основная идея подхода – разделить поведение сервисов на три категории, в которых появляются сервисы, в которых бизнес транзакции (не путать с техническими транзакциями):
- всегда будут успешны;
- могут быть отменены в случае проблем;
- сервисы, в которых бизнес транзакции нельзя отменить при возникновении проблем;
После, авторы рассказывают об инструменте для создания подобных воркфлоу, правилах, требуемых для модели и RIG system design flow model
#eventual_consistency #saga_pattern #distributed_systems
—————————————
Understanding idempotent data transformations
Не статья, а пост на форме dbt, в которой рассказывается о том, что на самом деле значит идемпотентная трансформация данных в контексте ETL и аналогичных инструментов.
При идемпотентной трансформации данных должны соблюдаться следующие условия:
- при остановке обновления сорса данных, полученный результат, после трансформации, всегда будет один и тот же;
- если данные удаляются, данные можно восстановить с нуля;
- если запущена трансформация в ручную, то она приведет к такому же эффекту, как если бы не была запущена (не понял эту идею, если честно);
- если трансформация прервалась, следующий запуск приведет к такому же результату, как если бы прерывания не было;
После объяснения идемпотентности и связи с трансформацией данных, показывается пример плохой трансформации, которая зависит от времени между запуском флоу. Пример связан с расчетом revenue за 24 часа, где данные собираются не за конкретный день, а за последние 24 часа. Если между запросами пройдет 12 часов - результат будет отличаться и идемпотентности не будет.
После, рассказывается о ситуациях, когда идемпотентность для преобразования данных полезна: фейлы в etl, изменение бизнес логики, обновление схемы данных, удаление данных и так далее.
#idempotency #data_managment
—————————————
Race Conditions Don’t Exist
Короткая статья из 2010 года с кликбейтным заголовком. Автор не говорит об полном отсутствии гонок, а объясняет, почему не стоит сразу делать сложное техническое решение для проблем, которых можно избежать изучив требования. Т.е. вместо того, чтобы идти и героически решать проблему, например с race condition, можно найти иную реализацию бизнес процесса и упростить жизнь технически.
Для объяснения автор использует пример с оформлением и отменой заказа, которая вызывает гонку. Если разобраться в требованиях, окажется, что алгоритм изменяется так, что заказ отправляется в сборку не сразу, а через определенное время (в статье говорится о часе, но это не важно). Благодаря чему, ситуация с гонкой когда оформление и отмена заказа происходит одновременно исключается.
Подобные ситуации встречаются в каждом проекте, в котором работал и если бы не этот лайфхак, то часть систем было бы слишком дорого делать. Поэтому однозначный мастрид.
#requirements #race_conditions #system_analisys
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Introducing the RIG Model - The Puzzle of Designing Guaranteed Data-Consistent Microservice Systems
При переходе на сервисы возникает проблема консистентности данных. мало того, что strong consistency заменяется на eventual consistency, так еще и eventual consistency не гарантируется, особенно когда появляется saga pattern. Связанно это с тем, что так или иначе придется столкнуться с dirty read, lost update и так далее.
Для решения проблем консистентности, авторы статьи, придумали RGI модель, которая расшифровывается как «Reversible, Irreversible, Guaranteed» и по сути, реализует SAGA паттерн с некоторыми условиями. Было интересно увидеть, что RIG вдохновлен event storming. А основная идея подхода – разделить поведение сервисов на три категории, в которых появляются сервисы, в которых бизнес транзакции (не путать с техническими транзакциями):
- всегда будут успешны;
- могут быть отменены в случае проблем;
- сервисы, в которых бизнес транзакции нельзя отменить при возникновении проблем;
После, авторы рассказывают об инструменте для создания подобных воркфлоу, правилах, требуемых для модели и RIG system design flow model
#eventual_consistency #saga_pattern #distributed_systems
—————————————
Understanding idempotent data transformations
Не статья, а пост на форме dbt, в которой рассказывается о том, что на самом деле значит идемпотентная трансформация данных в контексте ETL и аналогичных инструментов.
При идемпотентной трансформации данных должны соблюдаться следующие условия:
- при остановке обновления сорса данных, полученный результат, после трансформации, всегда будет один и тот же;
- если данные удаляются, данные можно восстановить с нуля;
- если запущена трансформация в ручную, то она приведет к такому же эффекту, как если бы не была запущена (не понял эту идею, если честно);
- если трансформация прервалась, следующий запуск приведет к такому же результату, как если бы прерывания не было;
После объяснения идемпотентности и связи с трансформацией данных, показывается пример плохой трансформации, которая зависит от времени между запуском флоу. Пример связан с расчетом revenue за 24 часа, где данные собираются не за конкретный день, а за последние 24 часа. Если между запросами пройдет 12 часов - результат будет отличаться и идемпотентности не будет.
После, рассказывается о ситуациях, когда идемпотентность для преобразования данных полезна: фейлы в etl, изменение бизнес логики, обновление схемы данных, удаление данных и так далее.
#idempotency #data_managment
—————————————
Race Conditions Don’t Exist
Короткая статья из 2010 года с кликбейтным заголовком. Автор не говорит об полном отсутствии гонок, а объясняет, почему не стоит сразу делать сложное техническое решение для проблем, которых можно избежать изучив требования. Т.е. вместо того, чтобы идти и героически решать проблему, например с race condition, можно найти иную реализацию бизнес процесса и упростить жизнь технически.
Для объяснения автор использует пример с оформлением и отменой заказа, которая вызывает гонку. Если разобраться в требованиях, окажется, что алгоритм изменяется так, что заказ отправляется в сборку не сразу, а через определенное время (в статье говорится о часе, но это не важно). Благодаря чему, ситуация с гонкой когда оформление и отмена заказа происходит одновременно исключается.
Подобные ситуации встречаются в каждом проекте, в котором работал и если бы не этот лайфхак, то часть систем было бы слишком дорого делать. Поэтому однозначный мастрид.
#requirements #race_conditions #system_analisys
Привет!
Незапланированный пост с разными анонсами:
1. Канал уйдет в ежегодный летний отпуск на весь июль, т.е. с 29 июня по 2 августа постов не будет. Буду отдыхать и пытаться сделать новую рубрику хотя бы в этом году;
2. В субботу выступал в Питере, где попросили про EventStorming рассказать. Попытался подойти к теме с позиции «зачем вообще надо моделировать процессы и как ES тут помогает», вместо заходов про DDD и прочие модные штуки. Если уже знаете что такое ES и как его использовать - скорее всего будет не особо интересно;
3. Сегодня вечером, в 18 по Москве, буду на стриме у ребят из пхп комьюнити обсуждать рост разработчиков и как прокачать себя, если непонятно что делать после становления синьором-помидором. А если сами ищете спикера в подкаст – давайте поговорим;
4. В четверг начнется курс по системам. Попросили напомнить;
Незапланированный пост с разными анонсами:
1. Канал уйдет в ежегодный летний отпуск на весь июль, т.е. с 29 июня по 2 августа постов не будет. Буду отдыхать и пытаться сделать новую рубрику хотя бы в этом году;
2. В субботу выступал в Питере, где попросили про EventStorming рассказать. Попытался подойти к теме с позиции «зачем вообще надо моделировать процессы и как ES тут помогает», вместо заходов про DDD и прочие модные штуки. Если уже знаете что такое ES и как его использовать - скорее всего будет не особо интересно;
3. Сегодня вечером, в 18 по Москве, буду на стриме у ребят из пхп комьюнити обсуждать рост разработчиков и как прокачать себя, если непонятно что делать после становления синьором-помидором. А если сами ищете спикера в подкаст – давайте поговорим;
4. В четверг начнется курс по системам. Попросили напомнить;
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Why, after 6 years, I’m over GraphQL
Why, after 8 years, I still like GraphQL sometimes in the right context
Споры вокруг надобности graphQL не утихают уже лет 8, поэтому сегодня две диаметральные статьи на тему graphQL, где говорится о диаметральных ситуациях и каждый автор описывает собственный опыт. Кто прав, а кто нет – решать вам.
В первой рассказывается о проблемах, которые могут возникнуть при использовании graphQL для публичного API. Начиная с авторизации и получения доступов к данным. Сложности возникают, когда разные поля одного объекта могут быть как доступны, так и не доступны для пользователей, в зависимости от контекста. Следующая проблема – сложность в ограничении запроса на объем возвращаемых данных или циклических вызовов. Далее рассказывается о возможном OOM (out of memory) во время парсинга невалидных строк запроса, что также приводит к проблемам перфоманса (привет N+1 и проблемы авторизации с N+1). После, автор говорит о проблеме утекания бизнес логики в транспортный слой и проблемами связанными с HTTP кодами, жирными батчами данных и сложностью эволюции схем. В конце приводятся примеры технологий, которые могут заменить graphQL.
Вторая статья – комментарий к первой, где автор рассказывает об опыте использования graphQL для приватного API. В самом начале, автор рассказывает о важности persisted queries, после чего пытается объяснить, что большая часть проблем с авторизацией либо связана с публичным API, либо также вызывает боль вне graphQL, что также относится и к ограничениям в запросах. В случае перфоманса, упоминается, что без dataloader жизни нет. Ну и в конце обсуждается как не допустить протекание логики в транспортный слой и как производить эволюцию API.
Русский перевод первой статьи
#sync_communications #graphql
—————————————
Decentralized Identifiers as an Identifier Metasystem
Одна из «mind-blowing» тем с курса по event-driven коммуникациям – meta id для ресурсов во всей системе, отличных от pk в каждом сервисе (это всякие
Текст начинается с объяснения терминов identifier metasystem и DID, после чего объясняется разница между DID и general identifiers (это условный pk из базы), при этом плюсы описываются с точки зрения улучшения характеристик системы (flexibility, interoperability и так далее). Дальше приводятся примеры использования. А в конце описываются потенциальные риски и возможные проблемы.
#identifier
—————————————
AWS Lambda Under the Hood
Очередная статья из серии «как работает Х». На этот раз лямбды aws. В начале описывается что это такое и некоторая статистика по лямбдам (10+ триллионов запросов в месяц, сколько кастомеров и так далее). После чего рассказывается о двух способах вызова функций: синхронно и асинхронно. После рассказывается об управлении стейтом в функциях. А после, рассказывается о Assignment Service, который помогает с управлением вызова: показывается структура и функции которые выполняет. Потом говорится о микро vm – Firecracker, которая запускает функции изолированно, нужна для секьюрити и быстрого запуска. В конце поднимаются тема хранения информации (кода, данных).
#how_it_works #aws #faas
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Why, after 6 years, I’m over GraphQL
Why, after 8 years, I still like GraphQL sometimes in the right context
Споры вокруг надобности graphQL не утихают уже лет 8, поэтому сегодня две диаметральные статьи на тему graphQL, где говорится о диаметральных ситуациях и каждый автор описывает собственный опыт. Кто прав, а кто нет – решать вам.
В первой рассказывается о проблемах, которые могут возникнуть при использовании graphQL для публичного API. Начиная с авторизации и получения доступов к данным. Сложности возникают, когда разные поля одного объекта могут быть как доступны, так и не доступны для пользователей, в зависимости от контекста. Следующая проблема – сложность в ограничении запроса на объем возвращаемых данных или циклических вызовов. Далее рассказывается о возможном OOM (out of memory) во время парсинга невалидных строк запроса, что также приводит к проблемам перфоманса (привет N+1 и проблемы авторизации с N+1). После, автор говорит о проблеме утекания бизнес логики в транспортный слой и проблемами связанными с HTTP кодами, жирными батчами данных и сложностью эволюции схем. В конце приводятся примеры технологий, которые могут заменить graphQL.
Вторая статья – комментарий к первой, где автор рассказывает об опыте использования graphQL для приватного API. В самом начале, автор рассказывает о важности persisted queries, после чего пытается объяснить, что большая часть проблем с авторизацией либо связана с публичным API, либо также вызывает боль вне graphQL, что также относится и к ограничениям в запросах. В случае перфоманса, упоминается, что без dataloader жизни нет. Ну и в конце обсуждается как не допустить протекание логики в транспортный слой и как производить эволюцию API.
Русский перевод первой статьи
#sync_communications #graphql
—————————————
Decentralized Identifiers as an Identifier Metasystem
Одна из «mind-blowing» тем с курса по event-driven коммуникациям – meta id для ресурсов во всей системе, отличных от pk в каждом сервисе (это всякие
public_id или global_id). В нормальном мире, за такой идентификатор отвечает identifier metasystem, например DNS, national ID, ISBNs у книг и так далее. В статье, автор рассуждает о том, можно ли использовать DIDs как identifier metasystem для системы.Текст начинается с объяснения терминов identifier metasystem и DID, после чего объясняется разница между DID и general identifiers (это условный pk из базы), при этом плюсы описываются с точки зрения улучшения характеристик системы (flexibility, interoperability и так далее). Дальше приводятся примеры использования. А в конце описываются потенциальные риски и возможные проблемы.
#identifier
—————————————
AWS Lambda Under the Hood
Очередная статья из серии «как работает Х». На этот раз лямбды aws. В начале описывается что это такое и некоторая статистика по лямбдам (10+ триллионов запросов в месяц, сколько кастомеров и так далее). После чего рассказывается о двух способах вызова функций: синхронно и асинхронно. После рассказывается об управлении стейтом в функциях. А после, рассказывается о Assignment Service, который помогает с управлением вызова: показывается структура и функции которые выполняет. Потом говорится о микро vm – Firecracker, которая запускает функции изолированно, нужна для секьюрити и быстрого запуска. В конце поднимаются тема хранения информации (кода, данных).
#how_it_works #aws #faas
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Solving the Dual-Write Problem: Effective Strategies for Atomic Updates Across Systems
Одна из проблем асинхронных коммуникаций - проблема либо потери, либо переизбытка событий, что может привести к проблемам двойной записи. Проблема встречается не только в распределенных системах, но может возникнуть и в монолите. Решением такой проблемы может быть либо идемпотентность событий, либо распределенный лок, либо создание флоу, когда дублирование событий не приведет к проблемам, либо думать над ретраями и прочим.
Об этом сегодняшняя статья от инженеров конфлюента, которая полезна как хайлевел описание проблемы и списка решений, из которых можно выбирать. В начале, на примере банковских транзакций объясняется проблема двойной записи, когда данные в бд попадают, а в сообщение в кафке теряется. Дальше описываются антипаттерны, которые вроде как могут помочь, но на деле не помогают:
- поменять порядок действий: когда сначала отправляется событие, потом идет запись в бд, что в итоге приводит к проблеме, когда данные перестают быть консистентны, когда запись в бд не срабатывает;
- обернуть запись в бд и продьюсинг события в бд транзакцию, что без отсутствия ролбека продьюсинга может привести не к консистентности;
- ретраи, которые не помогают в случае краша приложения;
После чего рассказывается о четырех потенциальных вариантах решения:
- outbox pattern;
- event sourcing с outbox pattern, когда в брокер отправляются события из эвент лога и не делается отдельной outbox таблицы;
- консьюминг самого себя для записи в базу;
- вскользь упоминается двухфазный коммит и extended architecture transactions;
#async_communications #event_driven
—————————————
The Scaling Journey of LinkedIn
Статья из серии «как в компании X решали проблему Y», а именно о том, как линкедин развивался в контексте скейлинга системы. Начинается история с монолита, который пришлось скейлить. В первой итерации возникла проблема с member-to-member связями и поиском. И для m2m связи сделали отдельный сервис с графами (включая бд), а для поиска еще один сервис.
Дальше задумались как скейлить оставшийся монолит. Помогло выделить отдельные инстансы, работа с тюнингом бд и репликами. После монолит решили разделить на набор сервисов, для этого сделали трехслойное решение с фронтом, апихой для доступа к данным и data сервисами, которые в бд ходят. Далее описывается как работали с кешированием и рассказывается, как начали использовать кафку для data pipelines, которую в линкедине как раз и придумали.
В последней трети статьи рассказывается об организационно скейлинге в компании и инструментах которые в этом помогли. В список попали: java rpc, что-то в духе bff для бекенд сервисов, мульти дата центр. А в конце рассказываются адвансед вещи вокруг скейлинга: аналитика и авторизация через ACL.
#how_it_works
—————————————
Injecting Chaos: Easy Techniques for Simulating Network Issues in Redis Clusters
Продолжая тему хаос инжиниринга – короткая статья с советами о том, как контролируемо сломать redis. В тексте рассматриваются симуляции трех проблем:
- Медленный ответ редис сервера;
- Проблемы с коннекшенами к серверу;
- Проблемы сети (тут придется написать кастомные interceptors/listeners);
Каждый сценарий содержит шаги настройки или команд для воспроизведения, плюс описывается в каких видах теста будет полезна симуляция проблемы. Если занимаетесь хаос инжинирингом и не знаете что делать с редисом – однозначный must have..
#chaos_engineering #redis
——— одной строкой ———
- Текст о заимствовании идеи вокруг «кор библиотеки» на все случаи жизни в скале, хаскеле и ноде;
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Solving the Dual-Write Problem: Effective Strategies for Atomic Updates Across Systems
Одна из проблем асинхронных коммуникаций - проблема либо потери, либо переизбытка событий, что может привести к проблемам двойной записи. Проблема встречается не только в распределенных системах, но может возникнуть и в монолите. Решением такой проблемы может быть либо идемпотентность событий, либо распределенный лок, либо создание флоу, когда дублирование событий не приведет к проблемам, либо думать над ретраями и прочим.
Об этом сегодняшняя статья от инженеров конфлюента, которая полезна как хайлевел описание проблемы и списка решений, из которых можно выбирать. В начале, на примере банковских транзакций объясняется проблема двойной записи, когда данные в бд попадают, а в сообщение в кафке теряется. Дальше описываются антипаттерны, которые вроде как могут помочь, но на деле не помогают:
- поменять порядок действий: когда сначала отправляется событие, потом идет запись в бд, что в итоге приводит к проблеме, когда данные перестают быть консистентны, когда запись в бд не срабатывает;
- обернуть запись в бд и продьюсинг события в бд транзакцию, что без отсутствия ролбека продьюсинга может привести не к консистентности;
- ретраи, которые не помогают в случае краша приложения;
После чего рассказывается о четырех потенциальных вариантах решения:
- outbox pattern;
- event sourcing с outbox pattern, когда в брокер отправляются события из эвент лога и не делается отдельной outbox таблицы;
- консьюминг самого себя для записи в базу;
- вскользь упоминается двухфазный коммит и extended architecture transactions;
#async_communications #event_driven
—————————————
The Scaling Journey of LinkedIn
Статья из серии «как в компании X решали проблему Y», а именно о том, как линкедин развивался в контексте скейлинга системы. Начинается история с монолита, который пришлось скейлить. В первой итерации возникла проблема с member-to-member связями и поиском. И для m2m связи сделали отдельный сервис с графами (включая бд), а для поиска еще один сервис.
Дальше задумались как скейлить оставшийся монолит. Помогло выделить отдельные инстансы, работа с тюнингом бд и репликами. После монолит решили разделить на набор сервисов, для этого сделали трехслойное решение с фронтом, апихой для доступа к данным и data сервисами, которые в бд ходят. Далее описывается как работали с кешированием и рассказывается, как начали использовать кафку для data pipelines, которую в линкедине как раз и придумали.
В последней трети статьи рассказывается об организационно скейлинге в компании и инструментах которые в этом помогли. В список попали: java rpc, что-то в духе bff для бекенд сервисов, мульти дата центр. А в конце рассказываются адвансед вещи вокруг скейлинга: аналитика и авторизация через ACL.
#how_it_works
—————————————
Injecting Chaos: Easy Techniques for Simulating Network Issues in Redis Clusters
Продолжая тему хаос инжиниринга – короткая статья с советами о том, как контролируемо сломать redis. В тексте рассматриваются симуляции трех проблем:
- Медленный ответ редис сервера;
- Проблемы с коннекшенами к серверу;
- Проблемы сети (тут придется написать кастомные interceptors/listeners);
Каждый сценарий содержит шаги настройки или команд для воспроизведения, плюс описывается в каких видах теста будет полезна симуляция проблемы. Если занимаетесь хаос инжинирингом и не знаете что делать с редисом – однозначный must have..
#chaos_engineering #redis
——— одной строкой ———
- Текст о заимствовании идеи вокруг «кор библиотеки» на все случаи жизни в скале, хаскеле и ноде;
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How Uber Built Real-Time Chat to Handle 3 Million Tickets Per Week?
Еще одна статья из серии «как в компании X сделали Y». Сегодня это чат убера, который используется саппортом для решения проблем. В какой-то момент, компания поняла, что хочет улучшить удовлетворенность пользователей во время решения проблем с саппортом. Сделать это возможно только через лайв чат, на который приходился 1% коммуникаций с 2019 по 2024. И этот чат не соответствовал требованиям бизнеса, из-за чего чат решили переделать.
Сначала, в тексте, рассказывается как легаси чат работал – взяли Web Application Messaging Protocol (WAMP) поверх вебсокетов. У решения возникли проблемы с reliability, scalability, observability и стейтфул подходом. Что не соответствовало целям бизнеса. По итогу, были придуманы новые требования. А для их реализации инженеры выбрали подход с push pipeline и graphQL subscription сервисом (в тексте найдете картинки и объяснение каждого элемента системы). В конце статьи найдете список плюсов, которые получила компания в процессе эволюции на новое решение.
Из текста не хватило больше подробностей и внутрянки (скорее проблема источников), но если хотите скейлить чат в компании и не знаете как это сделать – может быть полезно.
#how_it_works
—————————————
From Architecture to Tech Radar
В канале уже упоминалась статья о тех радаре - подходе, помогающем в стандартизации технологий/паттернов/подходов. Статья выше рассказывает о том, как использовался тех радар для разработки банковского приложения и как в радар встроены архитектурные решения.
В начале рассказывается о том, как используется радар в компании, как двигаются технологии по нему, при чем тут проблемы, драйверы и RFC/ADR. Понравилось, что есть схематическое представление как стандартного флоу жизни технологии, так и короткая версия, когда сразу понятно, что trial не понадобиться. После чего рассказывается о категориях, используемых в радаре: языки/фреймворки, девопс, девтулзы и техники/паттерны. После рассказывается о том, как компания описывает решения по принятию технологии/подходу сначала через RFC, который валидируется на архревю, а после превращается в ADR, который становится причиной изменения радара. В конце приводится пример того, как создается радар (используя сервис каталог) и даются общие советы по такому флоу работы.
#tech_radar #architecture_documentation
—————————————
Component Cohesion in Software Design
Работа со связями между элементов - ключевой элемент в создании и анализе систем. Благодаря этому можно работать со сложностью и выбирать элементы эффективнее. Сегодняшняя статья – своеобразный пересказ clean code, точнее части о cohesion (внутренней связанности) и четырех принципах, благодаря которым можно контролировать связанность.
В начале автор рассказывает, зачем за связями следить: проще скейлиться, менять систему, стабильность будет выше и так далее. После чего перечисляются принципы:
- Acyclic Dependencies Principle (ADP), который говорит о том, почему циклические связи – плохо;
- Top-Down Design, который говорит о том, как из высокоуровневых абстракций получить структуру системы;
- Stable Dependencies Principle (SDP), который приводит к характеристики стабильности системы;
- Stable Abstractions Principle (SAP), который связывает стабильность и абстрактность, благодаря чему можно прийти к distance from the main sequence;
#cohesion #coupling
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How Uber Built Real-Time Chat to Handle 3 Million Tickets Per Week?
Еще одна статья из серии «как в компании X сделали Y». Сегодня это чат убера, который используется саппортом для решения проблем. В какой-то момент, компания поняла, что хочет улучшить удовлетворенность пользователей во время решения проблем с саппортом. Сделать это возможно только через лайв чат, на который приходился 1% коммуникаций с 2019 по 2024. И этот чат не соответствовал требованиям бизнеса, из-за чего чат решили переделать.
Сначала, в тексте, рассказывается как легаси чат работал – взяли Web Application Messaging Protocol (WAMP) поверх вебсокетов. У решения возникли проблемы с reliability, scalability, observability и стейтфул подходом. Что не соответствовало целям бизнеса. По итогу, были придуманы новые требования. А для их реализации инженеры выбрали подход с push pipeline и graphQL subscription сервисом (в тексте найдете картинки и объяснение каждого элемента системы). В конце статьи найдете список плюсов, которые получила компания в процессе эволюции на новое решение.
Из текста не хватило больше подробностей и внутрянки (скорее проблема источников), но если хотите скейлить чат в компании и не знаете как это сделать – может быть полезно.
#how_it_works
—————————————
From Architecture to Tech Radar
В канале уже упоминалась статья о тех радаре - подходе, помогающем в стандартизации технологий/паттернов/подходов. Статья выше рассказывает о том, как использовался тех радар для разработки банковского приложения и как в радар встроены архитектурные решения.
В начале рассказывается о том, как используется радар в компании, как двигаются технологии по нему, при чем тут проблемы, драйверы и RFC/ADR. Понравилось, что есть схематическое представление как стандартного флоу жизни технологии, так и короткая версия, когда сразу понятно, что trial не понадобиться. После чего рассказывается о категориях, используемых в радаре: языки/фреймворки, девопс, девтулзы и техники/паттерны. После рассказывается о том, как компания описывает решения по принятию технологии/подходу сначала через RFC, который валидируется на архревю, а после превращается в ADR, который становится причиной изменения радара. В конце приводится пример того, как создается радар (используя сервис каталог) и даются общие советы по такому флоу работы.
#tech_radar #architecture_documentation
—————————————
Component Cohesion in Software Design
Работа со связями между элементов - ключевой элемент в создании и анализе систем. Благодаря этому можно работать со сложностью и выбирать элементы эффективнее. Сегодняшняя статья – своеобразный пересказ clean code, точнее части о cohesion (внутренней связанности) и четырех принципах, благодаря которым можно контролировать связанность.
В начале автор рассказывает, зачем за связями следить: проще скейлиться, менять систему, стабильность будет выше и так далее. После чего перечисляются принципы:
- Acyclic Dependencies Principle (ADP), который говорит о том, почему циклические связи – плохо;
- Top-Down Design, который говорит о том, как из высокоуровневых абстракций получить структуру системы;
- Stable Dependencies Principle (SDP), который приводит к характеристики стабильности системы;
- Stable Abstractions Principle (SAP), который связывает стабильность и абстрактность, благодаря чему можно прийти к distance from the main sequence;
#cohesion #coupling
Также, напомню, что канал уходит в ежегодный летний отпуск. Увидимся 9 августа, возможно чуть раньше. Если будет скучно, можно посмотреть старые посты, либо почитать книгу о скейлинге систем.
Постараюсь вернуться с новой рубрикой, а пока можно посмотреть, как Федя хвастается отзывами на курс, который сейчас идет.
Постараюсь вернуться с новой рубрикой, а пока можно посмотреть, как Федя хвастается отзывами на курс, который сейчас идет.
Forwarded from FEDOR BORSHEV
Хвастаюсь! Это первые отзывы после недели обучения на третьем потоке «Анализа Систем».
Как обычно, каждый новый поток приносит кучу новых задач в беклог — и по контенту, и по LMS. Но приятные отзывы помогают их делать :-)
Как обычно, каждый новый поток приносит кучу новых задач в беклог — и по контенту, и по LMS. Но приятные отзывы помогают их делать :-)
Канал возвращается из отпуска с новой рубрикой
Привет, канал вернулся из отпуска, ссылки появятся уже в эту пятницу. Но кроме ссылок созрел до выборочного ответа на вопросы из анонимной формы.
Стараюсь отвечать максимально подробно. При этом, важно сразу сказать – ответы не претендуют на истину, это только личный опыт и знания. Если хотите обсудить - пишите в комментарии в тг. Опечатки можно поправить в гитхабе.
До конца года хочу проверить насколько полезной окажется рубрика. В идеале, ответы будут раз в две недели, по понедельникам, но регулярности обещать не могу.
—————————————
Сегодня вопрос о том, как визуализировать схему базы данных.
В качестве ответа найдете информацию о data model и трех перспективах работы с данными: концептуальную, логическую и физическую. Рассказал о том, как сделать концептуальную схему и о трех способах визуализации уже существующей схемы БД.
Уверен, что что-то пропустил. Если используете другие способы визуализации – пишите в комментарии, дополню ответ.
Привет, канал вернулся из отпуска, ссылки появятся уже в эту пятницу. Но кроме ссылок созрел до выборочного ответа на вопросы из анонимной формы.
Стараюсь отвечать максимально подробно. При этом, важно сразу сказать – ответы не претендуют на истину, это только личный опыт и знания. Если хотите обсудить - пишите в комментарии в тг. Опечатки можно поправить в гитхабе.
До конца года хочу проверить насколько полезной окажется рубрика. В идеале, ответы будут раз в две недели, по понедельникам, но регулярности обещать не могу.
—————————————
Сегодня вопрос о том, как визуализировать схему базы данных.
В качестве ответа найдете информацию о data model и трех перспективах работы с данными: концептуальную, логическую и физическую. Рассказал о том, как сделать концептуальную схему и о трех способах визуализации уже существующей схемы БД.
Уверен, что что-то пропустил. Если используете другие способы визуализации – пишите в комментарии, дополню ответ.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно.
—————————————
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
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно.
—————————————
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