Channel: 2pegramming
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Apple built iCloud to store billions of databases
Очередная статья на тему «как в компании X решают проблему Y». На этот раз это эпл с icloud и проблема работы с миллионами баз данных в multi-tenant архитектуре. Для чего используют FoundationDB и Cassandra.
Начинается все с описания того, как в компании используют 300к инстансов Cassandra с петабайтами данных и миллионами запросов в секунду. Для этого заморачиваются с размещением нод кассандры в каждом сервере, сегментированию и радиусу вызова, что обеспечивает data availability близкой к 100%. Но на одной кассандре не уехать, поэтому в компании также используют FoundationDB (транзакционная и распределенная key-value бд) для CloudKit. Причем записи хранятся как прото сообщения. Дальше описывается как все это работает и при чем тут Record Layer. В конце даются решения некоторых проблем, с которыми столкнулись в компании: полнотекстовый поиск, обработка большого количества апдейтов, работа с high latency queries и разрешение конфликтных транзакций.
#how_it_works #db
—————————————
Representing The Same Data Structure in SQL and NoSQL
Выбор бд делают на основе характеристик, популярности и ограничений компании, при этом, редко когда сравнивают как одинаковые данные можно положить в разные бд и что из этого будет выгоднее. Таким вопросом задался автор статьи – сравнить SQL и noSQL подходы к хранению структур в базе, чтобы улучшить способ сравнения видов баз, потому что на одних характеристиках далеко не уедешь. При этом, автор сразу описывает что ждет от бд: получение отдельных записей по идентификатору, никакого неоправданного дублирования, «достаточно хорошо» выполнять запросы к бд.
Структура данных, с которой экспериментирует автор – игрок с инвентарем в ммо играх. В случае SQL базы будет создано 4 таблицы для хранения игрока, инвентаря и items в игре. Дальше описывается как будут делаться запросы и обсуждаются вопросы дупликации данных. Второй подход – SQL с xml (похоже на jsonb подход постгреса), в результате которого появляются некоторые проблемы: уменьшение перфоманса, не стандарт в sql базах и реализации отличаются. Третий подход связан с документо ориентированными бд (монгой, в случае автора). А четвертый с key-value.
К сожалению, статья не до конца дописана и датируется 2016 годом. Было бы здорово подобное увидеть с большим количеством примеров и в современных реалиях.
#data_managment #db
—————————————
Как ломаются системы и как их траблшутить
Статья от преподавателя ШАД как вводная в тему SRE. Текст начинается с рассказа о том, что такое распределенная система. Потом автор рассказывает об обсервабилити и при чем тут availability из которых собираются метрики. После этого текст переходит в сторону мониторинга и обнаружения аномалий.
Вторая часть текста описывает непосредственно варианты недоступности систем. Важная мысль, которая указывается автором – аварии случаются в любых системах, не важно больших или маленьких или вне зависимости от домена. Дальше дается список из девяти причин поломок: апгрейды, сеть, баги, мисконфигурация, всплески трафика, зависимости между элементами системы, проблемы с дисками, ошибки железа и внешние факторы (стихийные бедствия, уборщица, которая шнур выдернула и так далее). В конце описываются способы исправления аварий. Способы сводятся к управлению рисками и заранее реализованным подходам (рейт лимиты, дублирование данных, консенсус и так длалее), которые помогут избежать риски (и добавить новых).
От статьи не стоит ждать хардкора, скорее это вводная статья для тех, кто ничего не слышал об SRE до этого.
#sre #distributed_systems
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Apple built iCloud to store billions of databases
Очередная статья на тему «как в компании X решают проблему Y». На этот раз это эпл с icloud и проблема работы с миллионами баз данных в multi-tenant архитектуре. Для чего используют FoundationDB и Cassandra.
Начинается все с описания того, как в компании используют 300к инстансов Cassandra с петабайтами данных и миллионами запросов в секунду. Для этого заморачиваются с размещением нод кассандры в каждом сервере, сегментированию и радиусу вызова, что обеспечивает data availability близкой к 100%. Но на одной кассандре не уехать, поэтому в компании также используют FoundationDB (транзакционная и распределенная key-value бд) для CloudKit. Причем записи хранятся как прото сообщения. Дальше описывается как все это работает и при чем тут Record Layer. В конце даются решения некоторых проблем, с которыми столкнулись в компании: полнотекстовый поиск, обработка большого количества апдейтов, работа с high latency queries и разрешение конфликтных транзакций.
#how_it_works #db
—————————————
Representing The Same Data Structure in SQL and NoSQL
Выбор бд делают на основе характеристик, популярности и ограничений компании, при этом, редко когда сравнивают как одинаковые данные можно положить в разные бд и что из этого будет выгоднее. Таким вопросом задался автор статьи – сравнить SQL и noSQL подходы к хранению структур в базе, чтобы улучшить способ сравнения видов баз, потому что на одних характеристиках далеко не уедешь. При этом, автор сразу описывает что ждет от бд: получение отдельных записей по идентификатору, никакого неоправданного дублирования, «достаточно хорошо» выполнять запросы к бд.
Структура данных, с которой экспериментирует автор – игрок с инвентарем в ммо играх. В случае SQL базы будет создано 4 таблицы для хранения игрока, инвентаря и items в игре. Дальше описывается как будут делаться запросы и обсуждаются вопросы дупликации данных. Второй подход – SQL с xml (похоже на jsonb подход постгреса), в результате которого появляются некоторые проблемы: уменьшение перфоманса, не стандарт в sql базах и реализации отличаются. Третий подход связан с документо ориентированными бд (монгой, в случае автора). А четвертый с key-value.
К сожалению, статья не до конца дописана и датируется 2016 годом. Было бы здорово подобное увидеть с большим количеством примеров и в современных реалиях.
#data_managment #db
—————————————
Как ломаются системы и как их траблшутить
Статья от преподавателя ШАД как вводная в тему SRE. Текст начинается с рассказа о том, что такое распределенная система. Потом автор рассказывает об обсервабилити и при чем тут availability из которых собираются метрики. После этого текст переходит в сторону мониторинга и обнаружения аномалий.
Вторая часть текста описывает непосредственно варианты недоступности систем. Важная мысль, которая указывается автором – аварии случаются в любых системах, не важно больших или маленьких или вне зависимости от домена. Дальше дается список из девяти причин поломок: апгрейды, сеть, баги, мисконфигурация, всплески трафика, зависимости между элементами системы, проблемы с дисками, ошибки железа и внешние факторы (стихийные бедствия, уборщица, которая шнур выдернула и так далее). В конце описываются способы исправления аварий. Способы сводятся к управлению рисками и заранее реализованным подходам (рейт лимиты, дублирование данных, консенсус и так длалее), которые помогут избежать риски (и добавить новых).
От статьи не стоит ждать хардкора, скорее это вводная статья для тех, кто ничего не слышал об SRE до этого.
#sre #distributed_systems
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
1.8 Trillion Events Per Day with Kafka: How Agoda Handles it
Статья из серии «как в компании X решают проблему Y». Сегодня это Agoda и работа с кафкой под нагрузкой (~1.8 триллионов сообщений в день). В компании используют кафку с 2015 года для: аналитики, заполнения даталейка, мониторинга/алертинга, асинхронных коммуникаций, репликаций данных и ML pipeline. Статья как раз описывает решения, которые пришлось сделать в компании, чтобы это стало возможным.
Первое что сделали – двухфазный продьюсинг. Сначала сообщения пишутся на диск (в файл), после уже forwarder отправляет данные в кафку. Сделано это было, чтобы отвязать разработчиков от кафки и что бы команда поддержки кафки могла делать что угодно с кластерами. Следующим шагом стало разделение кафки на кластера, где каждый отвечает за конкретную часть логики: телеметрия отдельно, высокоприоритетные сообщения находятся в другом кластере и так далее. Это решение помогло избежать single point of failure и точечно конфигурировать нужные места. Дальше рассказывается о том, как в компании работают над мониторингом и аудитом кафки и об аутентификации и ACL.
Во второй часте статьи уделяется внимание работе над передачей данных. Описывается как настраивали лоад балансер, через partitioner и assignor strategy. А в третьей части статьи рассказывается о том, как в компании избежали проблемы с чрезмерным выделением ресурсов и решали проблемы лагов.
#how_it_works #kafka
—————————————
Some of My Favorite Things – Postgres Queries
Короткая статья в которой автор делится любимыми SQL запросами для postgreSQL. Сразу напишу, описанные в статье запросы связаны с observability базы и больше о понимании, что с базой происходит.
Вот список того, что найдете в тексте. Первые три запроса связаны с
Далее идут запросы на фактический размер таблицы (включая все записи), запрос, который покажет когда ожидается работа vacuum/analyze. Также найдете запрос показывающий не используемые (или редко используемые индексы) и как искать таблицы, в которых отсутствуют индексы для fk. В конце автор дает ссылку на то, как анализировать lock trees.
#data_managment #psql
—————————————
DDD causes Complexity !
Бонус, который появляется при использовании стратегического ддд – определение границ элементов системы, что влияет на сложность за счет переноса связей в элемент. Автор статьи как раз пытается доказать это утверждение.
В начале описываются два вида границ: физические и логические, причем границы идейно отличаются и редко когда 1 к 1 мапятся между собой. Далее автор связывает модульность и сложность между собой. Для чего используется две концепции: integration strength и distance between components. В конце описывается, как используя две метрики (strength и distance) определять «сложность» системы.
#ddd #complexity
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
1.8 Trillion Events Per Day with Kafka: How Agoda Handles it
Статья из серии «как в компании X решают проблему Y». Сегодня это Agoda и работа с кафкой под нагрузкой (~1.8 триллионов сообщений в день). В компании используют кафку с 2015 года для: аналитики, заполнения даталейка, мониторинга/алертинга, асинхронных коммуникаций, репликаций данных и ML pipeline. Статья как раз описывает решения, которые пришлось сделать в компании, чтобы это стало возможным.
Первое что сделали – двухфазный продьюсинг. Сначала сообщения пишутся на диск (в файл), после уже forwarder отправляет данные в кафку. Сделано это было, чтобы отвязать разработчиков от кафки и что бы команда поддержки кафки могла делать что угодно с кластерами. Следующим шагом стало разделение кафки на кластера, где каждый отвечает за конкретную часть логики: телеметрия отдельно, высокоприоритетные сообщения находятся в другом кластере и так далее. Это решение помогло избежать single point of failure и точечно конфигурировать нужные места. Дальше рассказывается о том, как в компании работают над мониторингом и аудитом кафки и об аутентификации и ACL.
Во второй часте статьи уделяется внимание работе над передачей данных. Описывается как настраивали лоад балансер, через partitioner и assignor strategy. А в третьей части статьи рассказывается о том, как в компании избежали проблемы с чрезмерным выделением ресурсов и решали проблемы лагов.
#how_it_works #kafka
—————————————
Some of My Favorite Things – Postgres Queries
Короткая статья в которой автор делится любимыми SQL запросами для postgreSQL. Сразу напишу, описанные в статье запросы связаны с observability базы и больше о понимании, что с базой происходит.
Вот список того, что найдете в тексте. Первые три запроса связаны с
pg_stat_statements и помогает найти топ запросы по количеству, среднему времени выполнения или общему времени выполнения (дальше будет запрос с запросами отфильтрованными по cpu time).Далее идут запросы на фактический размер таблицы (включая все записи), запрос, который покажет когда ожидается работа vacuum/analyze. Также найдете запрос показывающий не используемые (или редко используемые индексы) и как искать таблицы, в которых отсутствуют индексы для fk. В конце автор дает ссылку на то, как анализировать lock trees.
#data_managment #psql
—————————————
DDD causes Complexity !
Бонус, который появляется при использовании стратегического ддд – определение границ элементов системы, что влияет на сложность за счет переноса связей в элемент. Автор статьи как раз пытается доказать это утверждение.
В начале описываются два вида границ: физические и логические, причем границы идейно отличаются и редко когда 1 к 1 мапятся между собой. Далее автор связывает модульность и сложность между собой. Для чего используется две концепции: integration strength и distance between components. В конце описывается, как используя две метрики (strength и distance) определять «сложность» системы.
#ddd #complexity
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Top 3 features in Postgres 17
Я не специалист в постгресе, базовые вещи сделать могу, но вот запустить дум в бд уже знаний не хватит. Поэтому каждый раз интересно посмотреть на вещи, о которых не знал и сегодняшняя статья как раз об этом.
Текст рассказывает о трех вещах из 17 версии постгреса, на которые советуют посмотреть. В список попали:
-
- Расширенные функции JSONB. Из примечательного –
- Работа над перформансом. Тут автор упоминает, что оптимизировали вакуум, b-tree, parallel query processing и так далее. В случае вакуума приводится пример, что из-за новой структуры данных сокращение памяти доходит до 20 раз;
В конце дополнительный список улучшений над которыми работали в компании. Сюда попали:
#psql
—————————————
Checklist for Kubernetes in Production: Best Practices for SREs
Как можно понять из названия, автор текста собрал набор практик, которые помогают в обслуживании k8s. В список мест, о которых подумать надо, попали:
- управление ресурсами
- workload placement
- вопросы вокруг availability
- пробы
- персистанс стораджи
- обсервабилити
- GitOps
- оптимизация расходов
- избегание частых ошибок
Не ждите лонгрида с подробным описанием тонкостей k8s. Для каждого пункта дается краткая справка что это и почему о пункте стоит помнить. Плюс найдете советы, что стоит сделать в каждом случае. Так, в случае обсервабилити автор описывает алерты, которые стоит добавить, что делать с log retention. А для GitOps перечисляет инструменты, которые помогут с reconciliation и как описывать конфиги кластера.
Сразу скажу, я не спец в кубере, поэтому не могу сказать на сколько чеклист адекватен. Но ценность подобного текста вижу в том, что данный чек лист может служить отправной точкой для создания подобного списка в компании.
#k8s #sre #infrastructure
—————————————
Realtime Editing of Ordered Sequences
Статья о том, как в фигме решали проблемы, связанные с одновременным редактированием порядков объектов несколькими людьми. Причем главная проблема связана с eventual consistency: если один клиент меняет в фигме порядок объектов, то изменения долетят с лагом до другого клиента, что приводит к рассинхрону и потенциальным гонкам вокруг порядка изменений.
В качестве решения, в компании решили попробовать использовать алгоритм для синхронизации текста от гугла который называется Operational Transformation. Дальше авторы кратко описывают реализацию алгоритма и дают ссылку на оригинальный пейпер (но если хотите разобраться с ОТ – советую отдельно поискать статьи). После описывают плюсы и минусы алгоритма: хороший перфоманс, параллельные вставки работают корректно, а из минусов сложность реализации и понимания, плюс вместо move используется две операции.
В итоге, ОТ оказался оверхедом, поэтому в фигме решили воспользоваться старым добрым трюком связанным со вставкой между значениями для сортировки (когда между 0.2 и 0.3 вставляется 0.25). Дальше подробно описывается как подход работает и перечисляются плюсы и минусы.
#how_it_works #eventual_consistency
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Top 3 features in Postgres 17
Я не специалист в постгресе, базовые вещи сделать могу, но вот запустить дум в бд уже знаний не хватит. Поэтому каждый раз интересно посмотреть на вещи, о которых не знал и сегодняшняя статья как раз об этом.
Текст рассказывает о трех вещах из 17 версии постгреса, на которые советуют посмотреть. В список попали:
-
MERGE command with RETURNING support. Данное улучшение позволяет избежать лишнего запроса на получение данных, после использования MERGE;- Расширенные функции JSONB. Из примечательного –
JSON_TABLE, который приводит json объект в таблицу, с которой можно работать как с любой другой таблицей;- Работа над перформансом. Тут автор упоминает, что оптимизировали вакуум, b-tree, parallel query processing и так далее. В случае вакуума приводится пример, что из-за новой структуры данных сокращение памяти доходит до 20 раз;
В конце дополнительный список улучшений над которыми работали в компании. Сюда попали:
EXPLAIN (SERIALIZE), direct SSL/TLS connections, улучшения в psql и другие изменения.#psql
—————————————
Checklist for Kubernetes in Production: Best Practices for SREs
Как можно понять из названия, автор текста собрал набор практик, которые помогают в обслуживании k8s. В список мест, о которых подумать надо, попали:
- управление ресурсами
- workload placement
- вопросы вокруг availability
- пробы
- персистанс стораджи
- обсервабилити
- GitOps
- оптимизация расходов
- избегание частых ошибок
Не ждите лонгрида с подробным описанием тонкостей k8s. Для каждого пункта дается краткая справка что это и почему о пункте стоит помнить. Плюс найдете советы, что стоит сделать в каждом случае. Так, в случае обсервабилити автор описывает алерты, которые стоит добавить, что делать с log retention. А для GitOps перечисляет инструменты, которые помогут с reconciliation и как описывать конфиги кластера.
Сразу скажу, я не спец в кубере, поэтому не могу сказать на сколько чеклист адекватен. Но ценность подобного текста вижу в том, что данный чек лист может служить отправной точкой для создания подобного списка в компании.
#k8s #sre #infrastructure
—————————————
Realtime Editing of Ordered Sequences
Статья о том, как в фигме решали проблемы, связанные с одновременным редактированием порядков объектов несколькими людьми. Причем главная проблема связана с eventual consistency: если один клиент меняет в фигме порядок объектов, то изменения долетят с лагом до другого клиента, что приводит к рассинхрону и потенциальным гонкам вокруг порядка изменений.
В качестве решения, в компании решили попробовать использовать алгоритм для синхронизации текста от гугла который называется Operational Transformation. Дальше авторы кратко описывают реализацию алгоритма и дают ссылку на оригинальный пейпер (но если хотите разобраться с ОТ – советую отдельно поискать статьи). После описывают плюсы и минусы алгоритма: хороший перфоманс, параллельные вставки работают корректно, а из минусов сложность реализации и понимания, плюс вместо move используется две операции.
В итоге, ОТ оказался оверхедом, поэтому в фигме решили воспользоваться старым добрым трюком связанным со вставкой между значениями для сортировки (когда между 0.2 и 0.3 вставляется 0.25). Дальше подробно описывается как подход работает и перечисляются плюсы и минусы.
#how_it_works #eventual_consistency
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How CRDTs make multiplayer text editing part of Zed's DNA
На прошлой неделе упоминался пост от фигмы, где в компании решалась проблема ордеринга элементов при совместном редактировании. В тексте упоминали использование Operational Transformation – подхода, который помогает одновременно редактировать текст нескольким акторам. Сегодня текст от инженеров zed (редактор такой), в котором рассказывается, как в редакторе решали проблему одновременного редактирования, но вместо OT выбрали CRDT.
В начале статьи, кроме исторической справки, автор подводит к тому, что асинхронное редактирование сложная проблема, особенно если редактировать текст по индексам строк. Поэтому на помощь, вместо OT, пришел CRDT. Далее описывается в чем смысл CRDT – сделать структуру данных, операции к которой будут inherently commutative, что бы их применение к реплике данных происходило без трансформаций. Дальше рассказывается о логических фрагментах текстов, основанных на «якорях» – идентификаторах вставки + смещении. После рассказывается как происходит удаление текста, одновременные вставки в одном и том же месте и отмена операций.
Если никтогда не встречались с CRDT – статья поможет главную идею подхода понять.
#text_editing #crdt
—————————————
Управление рисками. Практический подход
Из того, что видел в проектах – либо о рисках не думают совсем, либо работа с рисками превращается в бюрократию. Иногда встречаются попытки использования risk storming (о котором упоминалось в канале). Статья выше о «стандартизированном» подходе работы с рисками. Причем, автор сразу указывает, что текст является пересказом BABOK (10.38 - Risk Analysis and Management).
В статье указывается восемь шагов по работе с рисками (причем каждый шаг рассматривается с придуманным примером):
1. Собрать вводные удобным способом, например брейнштормингом;
2. Создать первичный лог рисков. В лог стоит добавить условие возникновения риска и последствия, если риск выстрелит;
3. Оценка вероятности возникновения риска и влияния риска на систему;
4. «Калибровка» шкалы риска. Т.е. сделать так, чтобы оценка из прошлого шага стала однозначной для каждого стейкхолдера;
5. Оценка рисков по выбранным критериям;
6. Определение одной из пяти стратегии работы с риском: уклониться, делегировать, снизить, принять и увеличить;
7. Определение плана действий для каждого риска;
8. Обновление лога рисков.
#risk_managment
—————————————
Standardizing Chaos: How a Dynamic Status Mapping System Solves Logistics Inefficiencies
Статья, в которой логистическая компания рассказывает как решала проблему связанную со статусами доставок. В начале текста описывается, как вообще shipment работает: create создает заказ на перевозку, а query позволяет понять что происходит с посылкой во время перевозки.
Дальше описывается, что мол компании развиваться надо было быстро и рынок захватывать. А что бы это сделать, пришлось решить проблему со статусами в разных интеграциях: статусы, у каждой партнерской компании, разные. Проблему решили адаптерами под компанию с явным маппингом статусов. Дальше возникла проблема, когда несколько партнеров доставляли груз и одним адаптером под компанию не обойтись. Все это привело к тому, что пришлось делать Dynamic Status Mapping – подход со стандартизацией всех статусов и перевод их в консистентный вид для компании и каждой интеграции. В тексте найдете как подход работает и как решали сопутствующие проблемы: выбор фреймворка, определение статуса при перекрывающихся условиях и вопросы вокруг audit-а.
#how_it_works #logistics
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How CRDTs make multiplayer text editing part of Zed's DNA
На прошлой неделе упоминался пост от фигмы, где в компании решалась проблема ордеринга элементов при совместном редактировании. В тексте упоминали использование Operational Transformation – подхода, который помогает одновременно редактировать текст нескольким акторам. Сегодня текст от инженеров zed (редактор такой), в котором рассказывается, как в редакторе решали проблему одновременного редактирования, но вместо OT выбрали CRDT.
В начале статьи, кроме исторической справки, автор подводит к тому, что асинхронное редактирование сложная проблема, особенно если редактировать текст по индексам строк. Поэтому на помощь, вместо OT, пришел CRDT. Далее описывается в чем смысл CRDT – сделать структуру данных, операции к которой будут inherently commutative, что бы их применение к реплике данных происходило без трансформаций. Дальше рассказывается о логических фрагментах текстов, основанных на «якорях» – идентификаторах вставки + смещении. После рассказывается как происходит удаление текста, одновременные вставки в одном и том же месте и отмена операций.
Если никтогда не встречались с CRDT – статья поможет главную идею подхода понять.
#text_editing #crdt
—————————————
Управление рисками. Практический подход
Из того, что видел в проектах – либо о рисках не думают совсем, либо работа с рисками превращается в бюрократию. Иногда встречаются попытки использования risk storming (о котором упоминалось в канале). Статья выше о «стандартизированном» подходе работы с рисками. Причем, автор сразу указывает, что текст является пересказом BABOK (10.38 - Risk Analysis and Management).
В статье указывается восемь шагов по работе с рисками (причем каждый шаг рассматривается с придуманным примером):
1. Собрать вводные удобным способом, например брейнштормингом;
2. Создать первичный лог рисков. В лог стоит добавить условие возникновения риска и последствия, если риск выстрелит;
3. Оценка вероятности возникновения риска и влияния риска на систему;
4. «Калибровка» шкалы риска. Т.е. сделать так, чтобы оценка из прошлого шага стала однозначной для каждого стейкхолдера;
5. Оценка рисков по выбранным критериям;
6. Определение одной из пяти стратегии работы с риском: уклониться, делегировать, снизить, принять и увеличить;
7. Определение плана действий для каждого риска;
8. Обновление лога рисков.
#risk_managment
—————————————
Standardizing Chaos: How a Dynamic Status Mapping System Solves Logistics Inefficiencies
Статья, в которой логистическая компания рассказывает как решала проблему связанную со статусами доставок. В начале текста описывается, как вообще shipment работает: create создает заказ на перевозку, а query позволяет понять что происходит с посылкой во время перевозки.
Дальше описывается, что мол компании развиваться надо было быстро и рынок захватывать. А что бы это сделать, пришлось решить проблему со статусами в разных интеграциях: статусы, у каждой партнерской компании, разные. Проблему решили адаптерами под компанию с явным маппингом статусов. Дальше возникла проблема, когда несколько партнеров доставляли груз и одним адаптером под компанию не обойтись. Все это привело к тому, что пришлось делать Dynamic Status Mapping – подход со стандартизацией всех статусов и перевод их в консистентный вид для компании и каждой интеграции. В тексте найдете как подход работает и как решали сопутствующие проблемы: выбор фреймворка, определение статуса при перекрывающихся условиях и вопросы вокруг audit-а.
#how_it_works #logistics
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Use of Time in Distributed Databases (part 1)
Первая из пяти статей, в которой автор рассказывает о том, как можно синхронизировать время между узлами распределенной системы. Время тут нужно для координации, а из-за независимости работы нод, приходится придумывать абстракции. Так, в тексте, сначала рассказывается о логических, а потом и о векторных часах. После, автор, переходит к асимметрии информации и проблеме генералов. Дальше описываются слабо синхронизированные и строго синхронизированные часы. В конце найдете объяснение алгоритма на основе Timestamp Ordering (TSO) для управлением паралелизмом в распределенных бд, который используют для создания DynamoDB. В остальных частях найдете информацию об использовании логических часов и синхронизации физических часов для создания баз данных.
#distributed_system
—————————————
How Tinder Recommends To 75 Million Users with Geosharding
Статья из серии «компания X, решает проблему Y». Сегодня это тиндер и реализация гео шардирования пользователей, для ускорения поиска людей для рекомендаций. В начале статьи рассказывается как изначально работал поиск. Взяли эластик с одним индексом для данных. Когда компания выросла появились проблемы: слишком большой индекс эластика, latency увеличилась за счет размера базы, а инфраструктурная стоимость начала бить по карману. В результате инженеры решили переехать на гео шардирование, где каждый шард – отдельный регион в мире.
Дальше рассказывается о том, как в компании делили мир на регионы. С этим помогла библиотека от гугла S2 и «container-based load balancing method». S2 как раз помогает с «делением» мира на регионы на quadtree – ячейки, каждая из которых делится еще на 4. Плюс, в библиотеке реализована кривая Гильберта, которая гарантирует что близкие точки на карте будут в ближайших ячейках. По поводу балансировки, в статье рассказывается о том, как распределить нагрузку между регионами из S2: достаточно маркировать регион по нагрузке, после чего объединить, пока лимит не закончится.
В конце статьи найдете описание архитектуры и рассуждения между выбором Multi-Index и Multi-Cluster. Из интересного, рассказывается о том, как решали проблему консистентности (люди путешествуют), для чего взяли кафку.
#how_it_works #geosharding
—————————————
GraphRAG Explained: Enhancing RAG with Knowledge Graphs
Если хотите сделать доменно-специфичный GenAI на основе LLM, то придется воспользоваться RAG. В базовом виде RAG объединяет векторную базу данных с контекстной информацией и llm, в который скармливается контекст. Но для сложных вопросов (требующих рассуждений или ответы на вопросы с соединением разрозненной информацией) вариант с векторной бд не сработает. В статье выше, автор рассказывает о GraphRAG – инструменте майкрософта, который кроме векторного поиска использует граф знаний.
В начале статьи автор рассказывает что такое граф знаний (структура, которая хранит и связывает данные на основе их отношений). После рассказывает из чего состоит GraphRAG: индексации и обработки запроса. В рамках индексации описываются четыре основных этапа (из интересного, для создания графа знаний используется llm). После описывается обработка запроса. Тут описывается как глобальный, так и локальный поиск. Дальше описывается сравнение обычного RAG и GraphRAG. В конце найдете большой блок с объяснением, как GraphRAG подключить в векторную базу Milvus.
Русский перевод
#rag #genAI #graph
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Use of Time in Distributed Databases (part 1)
Первая из пяти статей, в которой автор рассказывает о том, как можно синхронизировать время между узлами распределенной системы. Время тут нужно для координации, а из-за независимости работы нод, приходится придумывать абстракции. Так, в тексте, сначала рассказывается о логических, а потом и о векторных часах. После, автор, переходит к асимметрии информации и проблеме генералов. Дальше описываются слабо синхронизированные и строго синхронизированные часы. В конце найдете объяснение алгоритма на основе Timestamp Ordering (TSO) для управлением паралелизмом в распределенных бд, который используют для создания DynamoDB. В остальных частях найдете информацию об использовании логических часов и синхронизации физических часов для создания баз данных.
#distributed_system
—————————————
How Tinder Recommends To 75 Million Users with Geosharding
Статья из серии «компания X, решает проблему Y». Сегодня это тиндер и реализация гео шардирования пользователей, для ускорения поиска людей для рекомендаций. В начале статьи рассказывается как изначально работал поиск. Взяли эластик с одним индексом для данных. Когда компания выросла появились проблемы: слишком большой индекс эластика, latency увеличилась за счет размера базы, а инфраструктурная стоимость начала бить по карману. В результате инженеры решили переехать на гео шардирование, где каждый шард – отдельный регион в мире.
Дальше рассказывается о том, как в компании делили мир на регионы. С этим помогла библиотека от гугла S2 и «container-based load balancing method». S2 как раз помогает с «делением» мира на регионы на quadtree – ячейки, каждая из которых делится еще на 4. Плюс, в библиотеке реализована кривая Гильберта, которая гарантирует что близкие точки на карте будут в ближайших ячейках. По поводу балансировки, в статье рассказывается о том, как распределить нагрузку между регионами из S2: достаточно маркировать регион по нагрузке, после чего объединить, пока лимит не закончится.
В конце статьи найдете описание архитектуры и рассуждения между выбором Multi-Index и Multi-Cluster. Из интересного, рассказывается о том, как решали проблему консистентности (люди путешествуют), для чего взяли кафку.
#how_it_works #geosharding
—————————————
GraphRAG Explained: Enhancing RAG with Knowledge Graphs
Если хотите сделать доменно-специфичный GenAI на основе LLM, то придется воспользоваться RAG. В базовом виде RAG объединяет векторную базу данных с контекстной информацией и llm, в который скармливается контекст. Но для сложных вопросов (требующих рассуждений или ответы на вопросы с соединением разрозненной информацией) вариант с векторной бд не сработает. В статье выше, автор рассказывает о GraphRAG – инструменте майкрософта, который кроме векторного поиска использует граф знаний.
В начале статьи автор рассказывает что такое граф знаний (структура, которая хранит и связывает данные на основе их отношений). После рассказывает из чего состоит GraphRAG: индексации и обработки запроса. В рамках индексации описываются четыре основных этапа (из интересного, для создания графа знаний используется llm). После описывается обработка запроса. Тут описывается как глобальный, так и локальный поиск. Дальше описывается сравнение обычного RAG и GraphRAG. В конце найдете большой блок с объяснением, как GraphRAG подключить в векторную базу Milvus.
Русский перевод
#rag #genAI #graph
This media is not supported in your browser
VIEW IN TELEGRAM
Организационный пост
Решил рассказать о публичных активностях и о том, что ждать в ближайшие 3 месяца от канала.
1. Выступление. В субботу буду на конференции для аналитиков рассказывать о «предсказании» будущего. Расскажу об подходе, который использую для принятия тех решений. Попутно буду душить о системах и системной инженерии.
2. Новая версия АА курса. Все еще пишу. Получилось больше чем планировал. Как пример, записал видос с драфтовой версией третьего урока. По поводу продаж/старта — с шансами в 90%, в конце апреля откроются продажи. Как определится дата — сразу напишу отдельный пост.
3. Ответы на вопросы. Продолжу отвечать на вопросы как разберусь с курсом. Планирую до отпуска (в июле) успеть ответить на 1-2 вопроса.
4. Пятничные ссылки. Как были, так и остаются. В июле канал на месяц уйдет в отпуск, после ссылки продолжаться без изменений.
Решил рассказать о публичных активностях и о том, что ждать в ближайшие 3 месяца от канала.
1. Выступление. В субботу буду на конференции для аналитиков рассказывать о «предсказании» будущего. Расскажу об подходе, который использую для принятия тех решений. Попутно буду душить о системах и системной инженерии.
2. Новая версия АА курса. Все еще пишу. Получилось больше чем планировал. Как пример, записал видос с драфтовой версией третьего урока. По поводу продаж/старта — с шансами в 90%, в конце апреля откроются продажи. Как определится дата — сразу напишу отдельный пост.
3. Ответы на вопросы. Продолжу отвечать на вопросы как разберусь с курсом. Планирую до отпуска (в июле) успеть ответить на 1-2 вопроса.
4. Пятничные ссылки. Как были, так и остаются. В июле канал на месяц уйдет в отпуск, после ссылки продолжаться без изменений.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Herding elephants: lessons learned from sharding Postgres at Notion
Статья от инженеров ноушена, в которой рассказывается как шардировали постгрес. В самом начале описываются проблемы из-за которых возник вопрос шардирования: пики загрузки CPU базы данных, миграции перестают быть безопасными, проблемы с VACUUM. Дальше описывается, что в компании решили придумать partitioning scheme основанную на application-level sharding. Для этого пришлось искать оветы на вопросы о том, какие данные, как будут разбиваться данные и сколько шардов будет нужно (в тексте найдете как инженеры отвечали на три этих вопроса).
После описывается «базовый» подход к миграции данных: сначала данные пишутся в два источника, после начала записи переносятся старые данные в новую бд, после команда проверяет целостность данных и если все ок — происходит переключение на уровне кода. В конце статьи найдете три мысли, которые появились у инженеров после миграции. Связаны мысли со временем когда надо было мигрировать, отношение к zero-downtime миграциям и использование глобальных идентификаторов для данных.
#how_it_works #psql
—————————————
How Not To Sort By Average Rating
Представте, что делаете магазин или медиа проект. Прилетает задача отсортировать элементы (товары/посты) по рейтингу, который задается пользователям. Вопрос: как определить «score» по которому будет происходить сортировка.
С этой проблемой поможет статья от 2009 года, в которой рассматриваются три варианта выбора подходящего «score»:
1. Первый вариант:
2. Второй вариант:
3. Третий вариант:
В случае с первым вариантом возникает проблема связанная с количеством оценок. Так товар с двумя положительными оценками будет в выдаче выше, чем товар с 1000 оценками, где сумма результатов будет меньше двух (мнение разделится 50/50). Во втором варианте опять не учитывается количество оценок. Так нонейм с двумя «пятерками» от родственников продовца будет выше в рейтинге, чем товар с тысячами оценок и средним рейтингом в 4.9.Третий вариант предлагает мат модель из 1927 года, которая балансирует score по количеству оценок. В статье приводится рубишный код, а если нужна реализация на js или go — добавлю ссылку на другую статью.
#algorithms #sorting
—————————————
Impureim sandwich
Recawr Sandwich
Две статьи рассказывающие о паттерне из функционального программирования. Идея строиться вокруг утверждения, что чистые функции не могут вызывать нечистые действия (например получение данных, либо изменение стейта). Чтобы избежать этой проблемы impureim sandwich. Идея в последовательности действий: сначала нечистая функция, потом чистая, в конце опять нечистая. Причем sandwich тут — сугубо метафора автора (как я понял). Далее автор дает примеры на хаскеле, f# и c#. А в конце дается объяснение слова impureim — IMpure/PURE/ IMpure.
Следующий паттерн, recawr sandwich, является подчастью impureim sandwich. А recawr расшифровывается как REad CAlculate WRite. И если impureim говорит о подходе вокруг чистых/нечистых функций, то recawr о конкретном действии: получить данные, вызывать чистую функцию, записать данные (поменять стейт). Во второй части статьи найдете примеры на разных языках и дополнительные статьи раскрывающие подход.
#patterns #functional_programming
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Herding elephants: lessons learned from sharding Postgres at Notion
Статья от инженеров ноушена, в которой рассказывается как шардировали постгрес. В самом начале описываются проблемы из-за которых возник вопрос шардирования: пики загрузки CPU базы данных, миграции перестают быть безопасными, проблемы с VACUUM. Дальше описывается, что в компании решили придумать partitioning scheme основанную на application-level sharding. Для этого пришлось искать оветы на вопросы о том, какие данные, как будут разбиваться данные и сколько шардов будет нужно (в тексте найдете как инженеры отвечали на три этих вопроса).
После описывается «базовый» подход к миграции данных: сначала данные пишутся в два источника, после начала записи переносятся старые данные в новую бд, после команда проверяет целостность данных и если все ок — происходит переключение на уровне кода. В конце статьи найдете три мысли, которые появились у инженеров после миграции. Связаны мысли со временем когда надо было мигрировать, отношение к zero-downtime миграциям и использование глобальных идентификаторов для данных.
#how_it_works #psql
—————————————
How Not To Sort By Average Rating
Представте, что делаете магазин или медиа проект. Прилетает задача отсортировать элементы (товары/посты) по рейтингу, который задается пользователям. Вопрос: как определить «score» по которому будет происходить сортировка.
С этой проблемой поможет статья от 2009 года, в которой рассматриваются три варианта выбора подходящего «score»:
1. Первый вариант:
Score = (Positive ratings) − (Negative ratings);2. Второй вариант:
Score = Average rating = (Positive ratings) / (Total ratings);3. Третий вариант:
Score = Lower bound of Wilson score confidence interval for a Bernoulli parameter.В случае с первым вариантом возникает проблема связанная с количеством оценок. Так товар с двумя положительными оценками будет в выдаче выше, чем товар с 1000 оценками, где сумма результатов будет меньше двух (мнение разделится 50/50). Во втором варианте опять не учитывается количество оценок. Так нонейм с двумя «пятерками» от родственников продовца будет выше в рейтинге, чем товар с тысячами оценок и средним рейтингом в 4.9.Третий вариант предлагает мат модель из 1927 года, которая балансирует score по количеству оценок. В статье приводится рубишный код, а если нужна реализация на js или go — добавлю ссылку на другую статью.
#algorithms #sorting
—————————————
Impureim sandwich
Recawr Sandwich
Две статьи рассказывающие о паттерне из функционального программирования. Идея строиться вокруг утверждения, что чистые функции не могут вызывать нечистые действия (например получение данных, либо изменение стейта). Чтобы избежать этой проблемы impureim sandwich. Идея в последовательности действий: сначала нечистая функция, потом чистая, в конце опять нечистая. Причем sandwich тут — сугубо метафора автора (как я понял). Далее автор дает примеры на хаскеле, f# и c#. А в конце дается объяснение слова impureim — IMpure/PURE/ IMpure.
Следующий паттерн, recawr sandwich, является подчастью impureim sandwich. А recawr расшифровывается как REad CAlculate WRite. И если impureim говорит о подходе вокруг чистых/нечистых функций, то recawr о конкретном действии: получить данные, вызывать чистую функцию, записать данные (поменять стейт). Во второй части статьи найдете примеры на разных языках и дополнительные статьи раскрывающие подход.
#patterns #functional_programming
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Legacy Modernization meets GenAI
Хоть скептически отношусь к GenAI, но мимо статьи пройти не смог. Главная идея текста — показать как вместо написания кода с помощью GenAI, начать разбираться в легаси системах (проект на cobol как пример прилагается). Для этого создали проект CodeConcise, который должен помочь с «ускорением» модернизации систем.
В начале описывается видение авторов вокруг GenAI и LLM. А также текущие проблемы, которые усложняют модернизацию. В список попали вопросы связанные с пониманием системы, целях системы, минимизацией рисков, поиск поддоменов из кодовой базы, а не из бизнеса и так далее. Дальше описывается структура CodeConcise: переводим код в AST, прогоняем дерево через LLM для получения графа знаний. А после, с графом знаний, работает пользователь через LLM. Граф знаний по коду хранят в neo4j. Поле описывается, как из полученного графа собираются требования, которые описывают поведение системы. Тут же показывается как понимание поведения системы на cobol ускорилось. Кроме требований, подход помог с высокоуровневым объяснением системы, включая поиск неиспользуемого кода. Ну а в конце ожидания от системы и куда дальше планируют двигаться инженеры.
Конкретики в статье не встретите, но было бы интересно получить доступ к CodeConcise, чтобы посмотреть как проект работает в реальности.
#genAI #llm
—————————————
Australia/Lord_Howe is the weirdest timezone
Считается, что в программировании две проблемы: нейминг и инвалидация кеша. Я бы добавил третью — таймзоны. Статья выше о часовых поясах, которыми стоит пугать людей.
В начале текста автор рассказывает о григорианском календаре и о том, какое влияние календарь оказал на таймзоны. После описывается влияние замедления вращения земли на синхронизацию времени между компьютером и реальностью. Для чего придумали високосную секунду, которая нивелирует эту разницу. Ну а после автор описывает часовые пояса. В список попали:
-
-
-
-
Попутно найдете информацию о разнице между летним и зимним временем.
#timezone
—————————————
How Airbnb Built a Key-Value Store for Petabytes of Data
Очередная статья о том, как в компании решали проблемы. Сегодня это airbnb, в котором возникли проблемы с доступом к derived данным (это данные, которые нужны для включения перс функций для конкретного юзера).
Сначала описывается что требуется от derived data service: high reliability, availability и low latency. А что бы добиться этих характеристик придумали Mussel — kv storage. Так как существующие решения не подходили, в компании сначала сделали HFileService (в тексте найдете плюсы и минусы решения). После сделали Nebula — систему для устранения проблем между batch-processed data и увеличенной нагрузкой для real-time доступа к данным (в тексте также найдете плюсы и минусы решения). И вот после этого появился Mussel, который заменил прошлые решения. В тексте найдете как происходит управление партишенами через Apache Helix, происходит репликация через kafka, происходит унификация хранения данных и реализован Bulk Load. В конце приводятся цифры перфоманс метрик и выводы с доп материалами.
#how_it_works #db
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Legacy Modernization meets GenAI
Хоть скептически отношусь к GenAI, но мимо статьи пройти не смог. Главная идея текста — показать как вместо написания кода с помощью GenAI, начать разбираться в легаси системах (проект на cobol как пример прилагается). Для этого создали проект CodeConcise, который должен помочь с «ускорением» модернизации систем.
В начале описывается видение авторов вокруг GenAI и LLM. А также текущие проблемы, которые усложняют модернизацию. В список попали вопросы связанные с пониманием системы, целях системы, минимизацией рисков, поиск поддоменов из кодовой базы, а не из бизнеса и так далее. Дальше описывается структура CodeConcise: переводим код в AST, прогоняем дерево через LLM для получения графа знаний. А после, с графом знаний, работает пользователь через LLM. Граф знаний по коду хранят в neo4j. Поле описывается, как из полученного графа собираются требования, которые описывают поведение системы. Тут же показывается как понимание поведения системы на cobol ускорилось. Кроме требований, подход помог с высокоуровневым объяснением системы, включая поиск неиспользуемого кода. Ну а в конце ожидания от системы и куда дальше планируют двигаться инженеры.
Конкретики в статье не встретите, но было бы интересно получить доступ к CodeConcise, чтобы посмотреть как проект работает в реальности.
#genAI #llm
—————————————
Australia/Lord_Howe is the weirdest timezone
Считается, что в программировании две проблемы: нейминг и инвалидация кеша. Я бы добавил третью — таймзоны. Статья выше о часовых поясах, которыми стоит пугать людей.
В начале текста автор рассказывает о григорианском календаре и о том, какое влияние календарь оказал на таймзоны. После описывается влияние замедления вращения земли на синхронизацию времени между компьютером и реальностью. Для чего придумали високосную секунду, которая нивелирует эту разницу. Ну а после автор описывает часовые пояса. В список попали:
-
Asia/Kathmandu — со смещением 5:45;-
Africa/Casablanca и Asia/Gaza — которые основаны на лунном календаре;-
America/Nuuk — в котором летнее время происходит «вчера»;-
Australia/Lord_Howe — в котором летнее время от зимнего отличается на два часа, а не на час;Попутно найдете информацию о разнице между летним и зимним временем.
#timezone
—————————————
How Airbnb Built a Key-Value Store for Petabytes of Data
Очередная статья о том, как в компании решали проблемы. Сегодня это airbnb, в котором возникли проблемы с доступом к derived данным (это данные, которые нужны для включения перс функций для конкретного юзера).
Сначала описывается что требуется от derived data service: high reliability, availability и low latency. А что бы добиться этих характеристик придумали Mussel — kv storage. Так как существующие решения не подходили, в компании сначала сделали HFileService (в тексте найдете плюсы и минусы решения). После сделали Nebula — систему для устранения проблем между batch-processed data и увеличенной нагрузкой для real-time доступа к данным (в тексте также найдете плюсы и минусы решения). И вот после этого появился Mussel, который заменил прошлые решения. В тексте найдете как происходит управление партишенами через Apache Helix, происходит репликация через kafka, происходит унификация хранения данных и реализован Bulk Load. В конце приводятся цифры перфоманс метрик и выводы с доп материалами.
#how_it_works #db
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Секреты стройности монолита: подходы по снятию нагрузки с БД
Статья из блога яндекса о том, как в компании уменьшали нагрузку на MySQL в яндекс еде. Сначала рассказывается о том, из чего система состоит: старый монолит на php, кластерный mysql (400+ таблиц), ProxySQL для роутинга запросов на мастер/реплику и сервисы на питоне, го и крестах. Из проблем: повышенный cpu и расход памяти, слишком много таблиц для работы, при нагрузке на запись, кластер останавливает запись, для достижения консистентности между нодами.
После рассказывается о том, как проблемы решались. Первым делом раскидали таблицы по командам разработки и начали трекать «плохие» запросы по времени выполнения. Попутно, сделали скрипт, который проверял количество задействованных таблиц на каждый запрос. И что бы не выносить загруженные таблицы в отдельные сервисы, вынесли таблицы в отдельные базы, для чего написали собственный инструмент + визуализировали связи между таблицами для группировки. Дальше рассказывается, как выносили группы таблиц. В тексте найдете интересные идеи по анализу бд, которые можно использовать вне еды. По поводу выноса таблиц в отдельные бд — вопросы.
#db #scalability
—————————————
What's OAuth2 Anyway?
Название статьи соответствует тому, что получите — по ссылке лонгрид (не шучу) с подробным объяснением того, как работает OAuth2. Кроме объяснения работы, автор описывает причины, из-за которых были приняты те или иные решения в протоколе.
Текст начинается с исторической справки и объяснения того, почему oauth появился, а именно из-за проблемы обмена данными пользователя между приложениями. После этого описывается что такое oauth — фреймворк, который дает пользователям возможность решать, какие приложения имеют доступ к персональным данным. Далее описываются четыре основные роли и как они между собой взаимодействуют: Resource Server, Resource Owner, Authorization Server и Client Application. Потом описывается работа клиентов, серверов авторизации, токенов, скоупов авторизации. Дальше описывается флоу аутентификации и авторизации через oauth, причем описывается как явный, так и не явный флоу. Причем, автор дает decision tree по выбору оптимального флоу и 13 референсов.
Если хотите разобраться в работе протокола — однозначный мастрид.
Русский перевод
#authz #oauth
—————————————
Bluesky: The Decentralized Social Media App with 30 Million Users
Статья описывает внутрянку соцсети Bluesky, которая построена поверх Authenticated Transfer Protocol. Протокол федеративный, из-за чего соцсеть является децентрализованной, что помогает пользователям взаимодействовать между собой без контроля со стороны платформы. В начале автор описывает, почему Bluesky решили идти в сторону децентрализации: упрощение миграции пользователей, поиск контента через relays, получение гибкой фильтрации контента. Далее описывается три основных компонента из которого соц сеть состоит:
- сервера перс данных, где хранятся посты, лайки и прочее;
- relays, которые агрегируют контент для пользователей (relays можно будет сделать под себя);
- App Views — прокси между relays и тем, что видит пользователь;
При этом, в тексте найдете описание того, как компоненты работают между собой. Далее описывается аутентификация и перенос аккаунтов между серверами. В конце описывается как контент индексируется и модерируется. Если хотите сделать децентрализованное приложение — статью стоит изучить.
#how_it_works
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Секреты стройности монолита: подходы по снятию нагрузки с БД
Статья из блога яндекса о том, как в компании уменьшали нагрузку на MySQL в яндекс еде. Сначала рассказывается о том, из чего система состоит: старый монолит на php, кластерный mysql (400+ таблиц), ProxySQL для роутинга запросов на мастер/реплику и сервисы на питоне, го и крестах. Из проблем: повышенный cpu и расход памяти, слишком много таблиц для работы, при нагрузке на запись, кластер останавливает запись, для достижения консистентности между нодами.
После рассказывается о том, как проблемы решались. Первым делом раскидали таблицы по командам разработки и начали трекать «плохие» запросы по времени выполнения. Попутно, сделали скрипт, который проверял количество задействованных таблиц на каждый запрос. И что бы не выносить загруженные таблицы в отдельные сервисы, вынесли таблицы в отдельные базы, для чего написали собственный инструмент + визуализировали связи между таблицами для группировки. Дальше рассказывается, как выносили группы таблиц. В тексте найдете интересные идеи по анализу бд, которые можно использовать вне еды. По поводу выноса таблиц в отдельные бд — вопросы.
#db #scalability
—————————————
What's OAuth2 Anyway?
Название статьи соответствует тому, что получите — по ссылке лонгрид (не шучу) с подробным объяснением того, как работает OAuth2. Кроме объяснения работы, автор описывает причины, из-за которых были приняты те или иные решения в протоколе.
Текст начинается с исторической справки и объяснения того, почему oauth появился, а именно из-за проблемы обмена данными пользователя между приложениями. После этого описывается что такое oauth — фреймворк, который дает пользователям возможность решать, какие приложения имеют доступ к персональным данным. Далее описываются четыре основные роли и как они между собой взаимодействуют: Resource Server, Resource Owner, Authorization Server и Client Application. Потом описывается работа клиентов, серверов авторизации, токенов, скоупов авторизации. Дальше описывается флоу аутентификации и авторизации через oauth, причем описывается как явный, так и не явный флоу. Причем, автор дает decision tree по выбору оптимального флоу и 13 референсов.
Если хотите разобраться в работе протокола — однозначный мастрид.
Русский перевод
#authz #oauth
—————————————
Bluesky: The Decentralized Social Media App with 30 Million Users
Статья описывает внутрянку соцсети Bluesky, которая построена поверх Authenticated Transfer Protocol. Протокол федеративный, из-за чего соцсеть является децентрализованной, что помогает пользователям взаимодействовать между собой без контроля со стороны платформы. В начале автор описывает, почему Bluesky решили идти в сторону децентрализации: упрощение миграции пользователей, поиск контента через relays, получение гибкой фильтрации контента. Далее описывается три основных компонента из которого соц сеть состоит:
- сервера перс данных, где хранятся посты, лайки и прочее;
- relays, которые агрегируют контент для пользователей (relays можно будет сделать под себя);
- App Views — прокси между relays и тем, что видит пользователь;
При этом, в тексте найдете описание того, как компоненты работают между собой. Далее описывается аутентификация и перенос аккаунтов между серверами. В конце описывается как контент индексируется и модерируется. Если хотите сделать децентрализованное приложение — статью стоит изучить.
#how_it_works
Новый поток «Асинхронной архитектуры» «Коммуникации систем», старт 28 мая
Год назад понял, что «Асинхронная архитектура (АА)» уже состарилась. Материал не раскрывал темы так глубоко как хотелось, а видео формат исправлять и дополнять оказалось слишком сложно. В результате чего было решено полностью переписать курс, добавив новые темы, глубже раскрыв старые и подвязав «Анализ систем (АС)». Получилось четыре лонгрида, по размеру не меньше, а то и больше, чем в АС.
Так появились «Коммуникации систем (КС)». В отличии от АС, где рассказывается о поиске элементов системы, свойств этих элементов и выбора архитектурного стиля, в КС упор делается на коммуникации между элементами. Будем искать формальные и функциональные связи (привет EventStorming и концептуальная модель данных), разбираться в характеристиках каждого из видов коммуникации, определять размеры событий и в каких случаях подойдет синхронный вызов, а в каких — асинхронный. Отдельный лонгрид посвящен миграции с одного вида коммуникации на другой и исправлению ошибок. И в этот раз поговорим о том, как «продавать» решения бизнесу и коллегам, а также в каких доменах подойдут event-driven коммуникации.
Будет полезно тем, кто работает с монолитами, так и тем, кто работает с распределёнными системами и планирует свои монолиты разобрать.
• Если проходили АС — кроме разбора коммуникаций узнаете продолжение истории Ибрагима и раскрытие ряда тем из курса.
• Если проходили АА — глубже разберетесь с коммуникациями и узнаете о том, как описывать поведение и форму системы.
• Если проходили АА и АС — узнаете как связаны темы из двух курсов.
Домашка тоже изменилась, вместо написания системы с нуля, будем «чинить» уже существующую систему. К сожалению, в первом потоке домашка без написания кода, так как банально не успели написать 10 одинаковых систем на разных языках.
Учиться начинаем 28 мая, закончим в середине июля. Промокод на 10% скидку — PEPECOMMUNICATIONS. Действует до конца выходных.
Год назад понял, что «Асинхронная архитектура (АА)» уже состарилась. Материал не раскрывал темы так глубоко как хотелось, а видео формат исправлять и дополнять оказалось слишком сложно. В результате чего было решено полностью переписать курс, добавив новые темы, глубже раскрыв старые и подвязав «Анализ систем (АС)». Получилось четыре лонгрида, по размеру не меньше, а то и больше, чем в АС.
Так появились «Коммуникации систем (КС)». В отличии от АС, где рассказывается о поиске элементов системы, свойств этих элементов и выбора архитектурного стиля, в КС упор делается на коммуникации между элементами. Будем искать формальные и функциональные связи (привет EventStorming и концептуальная модель данных), разбираться в характеристиках каждого из видов коммуникации, определять размеры событий и в каких случаях подойдет синхронный вызов, а в каких — асинхронный. Отдельный лонгрид посвящен миграции с одного вида коммуникации на другой и исправлению ошибок. И в этот раз поговорим о том, как «продавать» решения бизнесу и коллегам, а также в каких доменах подойдут event-driven коммуникации.
Будет полезно тем, кто работает с монолитами, так и тем, кто работает с распределёнными системами и планирует свои монолиты разобрать.
• Если проходили АС — кроме разбора коммуникаций узнаете продолжение истории Ибрагима и раскрытие ряда тем из курса.
• Если проходили АА — глубже разберетесь с коммуникациями и узнаете о том, как описывать поведение и форму системы.
• Если проходили АА и АС — узнаете как связаны темы из двух курсов.
Домашка тоже изменилась, вместо написания системы с нуля, будем «чинить» уже существующую систему. К сожалению, в первом потоке домашка без написания кода, так как банально не успели написать 10 одинаковых систем на разных языках.
Учиться начинаем 28 мая, закончим в середине июля. Промокод на 10% скидку — PEPECOMMUNICATIONS. Действует до конца выходных.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
RFC vs. ADR: Why Developers Should Care About Both
Когда говорят о документации архитектуры сразу думают о ADR или о RFC. На деле, оба документа помогают в описании «почему» решение было принято. Но документы не спасают от споров, что лучше использовать: ADR или RFC. Автор статьи объясняет разницу между подходами и дает «фреймворк» по выбору между подходами.
В начале статья начинается с описания RFC (Request for Comment). Описывается зачем нужен документ (получить фидбек до принятия решения), описывается зачем использовать подход (поиск подводных камней, сохранение обсуждений и предотвращение недокументированных решений). После автор приводит пример документа в котором встает выбор между SwiftData и Core Data, попутно объясняя структуру.
После, автор переходит к объяснению ADR (Architecture Decision Records). Аналогично rfc, описывается зачем документ нужен (запись принятых решений), зачем использовать (борьба с амнезией, помощь новым разработчикам, создание accountability в архитектуре). Пример также приводится с описанием базовой структуры.
А в конце найдете decision tree по которому можно выбрать какой из двух подходов использовать.
#adr #rfc
—————————————
Redis as a Primary Database for Complex Applications
Название статьи говорит само за себя — в тексте найдете объяснение, почему стоит посмотреть на redis как на primary db в проекте. Делать подобный выбор оставлю на совести читателя, но статью, в качестве разнообразия, оставлю.
Начинается текст с краткой справки о том, что это за in-memory db, которую используют для кеша. Дальше рассматривается пример, в виде social-media приложения, где используется пять разных баз для разных типов данных. Из-за этого возникают проблемы: сложность в деплойменте, обслуживании, скейлинге, высокая цена в облаке и проблемы с latency. Дальше автор объясняет, как все эти проблемы решаются заменив пять баз на один редис. Для этого объясняет как работают модули для поиска и графов, кеширование и производительность. После, автор рассказывает о двух вариантах персистенса базы: снапшотах и AOF. И после персистенса поднимаются темы масштабирования и шардирования с геошардами и репликацией. В конце найдете объяснение работы редиса в k8s и решение конфликтов через CRDT.
#redis
—————————————
5 Common Antipatterns in Payment Systems Design
Может показаться, что в платежных системах стоит фокусироваться на перфомансе или качестве кода. На деле, главное сделать так, что бы система не глючила и расширялась без проблем. А на это влияет заложенная структура. Автор поста собрал пять антипаттернов, которые встречаются в платежных системах и способах избежать этих проблем.
Сам список анти паттернов включает:
- Верить, что PSP (Payment service providers) будет присылать синхронизацию в ответе. Тут о том, что хоть PSP и высокодоступные, но из-за этого возникают проблемы с nondeterminism. Что приводит к двум подтверждениям одной и той же операции, которые не говорят о двойном списании.
- Вера, что платеж — движение средств. Тут о том, что платеж — «обещание» перевести деньги, а непосредственно переводом будет — transfer.
- Дизан на основе работ карт. Тут о том, что важно разделять order, intent (что оплачивается) и method (как оплачивается).
- Stretching State Machines. Тут о том, что стейт машина не всегда подходящий выбор для обработки жизненного цикла платежа.
- Проблемы вокруг базы. Тут о том, что если хотите роста, возможно стоит заранее выбрать подходящую бд, вместо срочных переездов.
#payment
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
RFC vs. ADR: Why Developers Should Care About Both
Когда говорят о документации архитектуры сразу думают о ADR или о RFC. На деле, оба документа помогают в описании «почему» решение было принято. Но документы не спасают от споров, что лучше использовать: ADR или RFC. Автор статьи объясняет разницу между подходами и дает «фреймворк» по выбору между подходами.
В начале статья начинается с описания RFC (Request for Comment). Описывается зачем нужен документ (получить фидбек до принятия решения), описывается зачем использовать подход (поиск подводных камней, сохранение обсуждений и предотвращение недокументированных решений). После автор приводит пример документа в котором встает выбор между SwiftData и Core Data, попутно объясняя структуру.
После, автор переходит к объяснению ADR (Architecture Decision Records). Аналогично rfc, описывается зачем документ нужен (запись принятых решений), зачем использовать (борьба с амнезией, помощь новым разработчикам, создание accountability в архитектуре). Пример также приводится с описанием базовой структуры.
А в конце найдете decision tree по которому можно выбрать какой из двух подходов использовать.
#adr #rfc
—————————————
Redis as a Primary Database for Complex Applications
Название статьи говорит само за себя — в тексте найдете объяснение, почему стоит посмотреть на redis как на primary db в проекте. Делать подобный выбор оставлю на совести читателя, но статью, в качестве разнообразия, оставлю.
Начинается текст с краткой справки о том, что это за in-memory db, которую используют для кеша. Дальше рассматривается пример, в виде social-media приложения, где используется пять разных баз для разных типов данных. Из-за этого возникают проблемы: сложность в деплойменте, обслуживании, скейлинге, высокая цена в облаке и проблемы с latency. Дальше автор объясняет, как все эти проблемы решаются заменив пять баз на один редис. Для этого объясняет как работают модули для поиска и графов, кеширование и производительность. После, автор рассказывает о двух вариантах персистенса базы: снапшотах и AOF. И после персистенса поднимаются темы масштабирования и шардирования с геошардами и репликацией. В конце найдете объяснение работы редиса в k8s и решение конфликтов через CRDT.
#redis
—————————————
5 Common Antipatterns in Payment Systems Design
Может показаться, что в платежных системах стоит фокусироваться на перфомансе или качестве кода. На деле, главное сделать так, что бы система не глючила и расширялась без проблем. А на это влияет заложенная структура. Автор поста собрал пять антипаттернов, которые встречаются в платежных системах и способах избежать этих проблем.
Сам список анти паттернов включает:
- Верить, что PSP (Payment service providers) будет присылать синхронизацию в ответе. Тут о том, что хоть PSP и высокодоступные, но из-за этого возникают проблемы с nondeterminism. Что приводит к двум подтверждениям одной и той же операции, которые не говорят о двойном списании.
- Вера, что платеж — движение средств. Тут о том, что платеж — «обещание» перевести деньги, а непосредственно переводом будет — transfer.
- Дизан на основе работ карт. Тут о том, что важно разделять order, intent (что оплачивается) и method (как оплачивается).
- Stretching State Machines. Тут о том, что стейт машина не всегда подходящий выбор для обработки жизненного цикла платежа.
- Проблемы вокруг базы. Тут о том, что если хотите роста, возможно стоит заранее выбрать подходящую бд, вместо срочных переездов.
#payment
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Testing graph databases
Давайте сразу, текст очень большой. Если печатать статью, то получится 130+ страниц А4. Текст уже упоминался в ответе на вопрос о графовых бд, но хочется напомнить о лонгриде еще раз.
Идея текста такая: автор работает над проектом, где используется графовая база данных. Изначально выбрали neo4j, но в результате проект переехал на ArangoDB. Ну и в контексте этой ситуации, автор решил провести ресерч и сравнить 6 графовых бд между собой. Кроме neo4j и arangoDB, выбор пал на: cayley, terminusDB, JanusGraph и NebulaGraph. Кроме перформанса автор еще проверял наличие библиотек для go, python и haskell.
Дальше автор описывает сценарий, который проверялся в каждой из баз. Сначала говорится о датасете, который будет лежать в базах, для чего использовалась онтология из рабочего проекта, которая проверяет библиотеки по разным свойствам. Дальше рассказывается, как генерировались данные. И потом, как происходила выборка (код на питоне присутствует). Для чистоты эксперимента, автор еще сделал проверку для кода, без использования базы данных. Ну а дальше начинается сравнение каждой из базы данных, куда попали примеры кода, графики и результаты. В конце найдете выводы и «победителей». Если выбираете графовую бд в проект — статья мастхев.
#graph_db
—————————————
How GitHub uses CodeQL to secure GitHub
CodeQL — инструмент статического анализа, который разработали в гитхабе и который проверяет код на наличие секьюрити уязвимостей. Главная идея в том, что код можно представить как базу данных, к которой делаются запросы для анализа. У инструмента три способа использования: стандартный «запустил и поехал», расширенная настройка с кастомными запросами и Multi-repository variant analysis.
В тексте найдете опыт секьюрити команды гитхаба, в котором описано, как в компании используется CodeQL. Начинается текст с объяснения что это за инструмент, после показано как делать кастомный query pack и вставлять запросы в любой репозиторий. Дальше описываются примеры запросов, которые можно использовать в проектах: определение вызова рисковых API, использование не безопасных методов библиотек, проверка доступов в HTTP эндпоинтах, проверка токенов и так далее. В конце найдете упоминание Variant Analysis — процессе поиска вариантов уязвимостей.
Русский перевод
#fitness_functions #security
—————————————
Reference Architecture Models
Reference Architecture Models — темплейт проекта, который можно использовать для разработки как референс. Такие модели нужны для определения концепций и принципов, которые необходимо реализовать в коде, объяснения реализации паттернов на примере и показа «эталонного» примера реализации системы.
Статья выше как раз рассказывает о том, что за модель и кому нужна референсная модель. После рассказывается о шести видах моделей: инфраструктурная, application, privacy, security, data и capability (бизне слогика). Для каждой из моделей описывается что должно входить в модель, какие плюсы и примеры реализации. Дальше автор рассказывает хайлевел идеи по созданию моделей (делайте проактивно или итеративно) ну и кто такой моделью заниматься должен. В тексте не хватило ссылок на гитхаб с примерами моделей, но для общего понимания и самостоятельного изучения текст подойдет.
#architecture
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Testing graph databases
Давайте сразу, текст очень большой. Если печатать статью, то получится 130+ страниц А4. Текст уже упоминался в ответе на вопрос о графовых бд, но хочется напомнить о лонгриде еще раз.
Идея текста такая: автор работает над проектом, где используется графовая база данных. Изначально выбрали neo4j, но в результате проект переехал на ArangoDB. Ну и в контексте этой ситуации, автор решил провести ресерч и сравнить 6 графовых бд между собой. Кроме neo4j и arangoDB, выбор пал на: cayley, terminusDB, JanusGraph и NebulaGraph. Кроме перформанса автор еще проверял наличие библиотек для go, python и haskell.
Дальше автор описывает сценарий, который проверялся в каждой из баз. Сначала говорится о датасете, который будет лежать в базах, для чего использовалась онтология из рабочего проекта, которая проверяет библиотеки по разным свойствам. Дальше рассказывается, как генерировались данные. И потом, как происходила выборка (код на питоне присутствует). Для чистоты эксперимента, автор еще сделал проверку для кода, без использования базы данных. Ну а дальше начинается сравнение каждой из базы данных, куда попали примеры кода, графики и результаты. В конце найдете выводы и «победителей». Если выбираете графовую бд в проект — статья мастхев.
#graph_db
—————————————
How GitHub uses CodeQL to secure GitHub
CodeQL — инструмент статического анализа, который разработали в гитхабе и который проверяет код на наличие секьюрити уязвимостей. Главная идея в том, что код можно представить как базу данных, к которой делаются запросы для анализа. У инструмента три способа использования: стандартный «запустил и поехал», расширенная настройка с кастомными запросами и Multi-repository variant analysis.
В тексте найдете опыт секьюрити команды гитхаба, в котором описано, как в компании используется CodeQL. Начинается текст с объяснения что это за инструмент, после показано как делать кастомный query pack и вставлять запросы в любой репозиторий. Дальше описываются примеры запросов, которые можно использовать в проектах: определение вызова рисковых API, использование не безопасных методов библиотек, проверка доступов в HTTP эндпоинтах, проверка токенов и так далее. В конце найдете упоминание Variant Analysis — процессе поиска вариантов уязвимостей.
Русский перевод
#fitness_functions #security
—————————————
Reference Architecture Models
Reference Architecture Models — темплейт проекта, который можно использовать для разработки как референс. Такие модели нужны для определения концепций и принципов, которые необходимо реализовать в коде, объяснения реализации паттернов на примере и показа «эталонного» примера реализации системы.
Статья выше как раз рассказывает о том, что за модель и кому нужна референсная модель. После рассказывается о шести видах моделей: инфраструктурная, application, privacy, security, data и capability (бизне слогика). Для каждой из моделей описывается что должно входить в модель, какие плюсы и примеры реализации. Дальше автор рассказывает хайлевел идеи по созданию моделей (делайте проактивно или итеративно) ну и кто такой моделью заниматься должен. В тексте не хватило ссылок на гитхаб с примерами моделей, но для общего понимания и самостоятельного изучения текст подойдет.
#architecture
Forwarded from FEDOR BORSHEV
В четверг, в 16:00 MSK будем с Антоном Давыдовым отвечать на вопросы о «Коммуникации Систем». Расскажем чего ждать на курсе, как будет проходить обучение и что поменяли со времён «Асинхронной Архитектуры» (спойлер: всё).
Встречаемся прямо здесь 15 мая в 16:00 MSK, будет видео-стрим. Записи не будет.
———
А ещё сегодня вроде как значимо поднимаются цены, но на сайте до сих пор не поменяли, так что го покупать, если хотите сэкономить
Встречаемся прямо здесь 15 мая в 16:00 MSK, будет видео-стрим. Записи не будет.
———
А ещё сегодня вроде как значимо поднимаются цены, но на сайте до сих пор не поменяли, так что го покупать, если хотите сэкономить
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Cedar: A New Language for Authorization
В 2024 году, в aws подготовили пейпер о новом DSL для описания прав — cedar. Упор в DSL сделан на выразительности, перфомансе, безопасности и анализируемости. Поддерживает RBAC, ABAC и ReBAC.
Статья выше — пересказ пейпера и начинается с описания структуры policy, который состоит из effect (разрешено или нет), scope (юзер, действие и ресурс) и conditions (доп ограничения связанные с атрибутами). Далее описывается как происходит анализ полиси, через symbolic compilation, который сводит все к SMT формулам (формализация на Lean присутствует). Подобные действия помогают выявлять несоответствия и проверять инварианты, что поможет в рефакторинге. В последней части описывается реализация, которая сделана на расте и бенчмарк с другими языками авторизации
#authZ
—————————————
Every Backend Engineer needs to know how to deal with payments.
Основная проблема платежных систем не в реализации кода, а в обработке корнер кейсов и ошибок возникающих во время работы написанного кода. Поэтому сегодня статья от автора, который делится способами решения проблем в системах, занимающихся обработкой платежей.
Статья начинается с обсуждения семи возможных статусов платежа: инициирован, обрабатывается, успешен, зафейлен, ожидает повтор, refunded и отменен. Понравилось, что есть flowchart с переходом между статусами. Дальше дается совет по хранению статусов через append-only таблицу, что поможет с аудитом, целостностью и concurrency обработкой. Следующая проблема, которую рассматривает автор — повтор платежей. Дается список условий когда стоит и не стоит делать ретрай и опять же flow chart для визуализации «движения» оплат. Последняя проблема связана с двойным списанием и достижением exactly-once. Для решения автор предлагает использовать идемпотентность и Distributed Transaction Handling, но как не пишет.
Русский перевод
#payment_system
—————————————
The Golden Age of Modularity
Статья рассуждения от автора learning DDD, в которой объясняется, почему модульность стала ключевой в контексте AI и LLM. Сначала объясняется что такое модульность, через два критерия: понимание что затрагивает изменения системы и понимание что произойдет при изменениях. При этом, модульность раньше связывали с долгосрочным развитием, но пришли LLM. И теперь модульность нужна, чтобы генерация кода приносила меньше проблем. А для этого необходимо ограничивать контекст нейронки, с чем модульность и помогает. В конце найдете ссылки на две книги автора (learning DDD и Balanced Coupling), которые как раз помогут в определении границ элементов и модульности.
#modularity #llm
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Cedar: A New Language for Authorization
В 2024 году, в aws подготовили пейпер о новом DSL для описания прав — cedar. Упор в DSL сделан на выразительности, перфомансе, безопасности и анализируемости. Поддерживает RBAC, ABAC и ReBAC.
Статья выше — пересказ пейпера и начинается с описания структуры policy, который состоит из effect (разрешено или нет), scope (юзер, действие и ресурс) и conditions (доп ограничения связанные с атрибутами). Далее описывается как происходит анализ полиси, через symbolic compilation, который сводит все к SMT формулам (формализация на Lean присутствует). Подобные действия помогают выявлять несоответствия и проверять инварианты, что поможет в рефакторинге. В последней части описывается реализация, которая сделана на расте и бенчмарк с другими языками авторизации
#authZ
—————————————
Every Backend Engineer needs to know how to deal with payments.
Основная проблема платежных систем не в реализации кода, а в обработке корнер кейсов и ошибок возникающих во время работы написанного кода. Поэтому сегодня статья от автора, который делится способами решения проблем в системах, занимающихся обработкой платежей.
Статья начинается с обсуждения семи возможных статусов платежа: инициирован, обрабатывается, успешен, зафейлен, ожидает повтор, refunded и отменен. Понравилось, что есть flowchart с переходом между статусами. Дальше дается совет по хранению статусов через append-only таблицу, что поможет с аудитом, целостностью и concurrency обработкой. Следующая проблема, которую рассматривает автор — повтор платежей. Дается список условий когда стоит и не стоит делать ретрай и опять же flow chart для визуализации «движения» оплат. Последняя проблема связана с двойным списанием и достижением exactly-once. Для решения автор предлагает использовать идемпотентность и Distributed Transaction Handling, но как не пишет.
Русский перевод
#payment_system
—————————————
The Golden Age of Modularity
Статья рассуждения от автора learning DDD, в которой объясняется, почему модульность стала ключевой в контексте AI и LLM. Сначала объясняется что такое модульность, через два критерия: понимание что затрагивает изменения системы и понимание что произойдет при изменениях. При этом, модульность раньше связывали с долгосрочным развитием, но пришли LLM. И теперь модульность нужна, чтобы генерация кода приносила меньше проблем. А для этого необходимо ограничивать контекст нейронки, с чем модульность и помогает. В конце найдете ссылки на две книги автора (learning DDD и Balanced Coupling), которые как раз помогут в определении границ элементов и модульности.
#modularity #llm
Google Docs
Вопросы для pepegramming
Привет!
На связи автор телеграм канала https://hottg.com/pepegramming. Я хочу, чтобы канал был для тебя полезным и нескучным. Поэтому мне очень важен фидбек. Если тебе есть, что сказать или спросить, пожалуйста, заполни форму обратной связи – тем самым ты поможешь…
На связи автор телеграм канала https://hottg.com/pepegramming. Я хочу, чтобы канал был для тебя полезным и нескучным. Поэтому мне очень важен фидбек. Если тебе есть, что сказать или спросить, пожалуйста, заполни форму обратной связи – тем самым ты поможешь…
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Amdahl's Law - The Theoretical Relationship Between Speedup and Concurrency
Хоть статья — вторая часть из серии постов о масштабировании рельсы, не ведитесь. Главное в тексте, объяснение закона ограничивающего рост производительности с увеличением процессов. Сам закон назван в честь ученого Джина Амдала, который и придумал закон.
В начале текста объясняется в чем суть закона (с математической формулой). При этом, автор оставил ссылку на видео, где объясняется как и за счет чего взялась формула. Дальше рассказывается, как используя закон Амдала, определить оптимальное количество тредов. При этом, понравилось, что автор делает различие между теоретическими выкладками и реальным количеством тредов, которые стоит выбрать. Связано это с тем, что добавляются дополнительные ограничения в виде излишнего потребления памяти и дополнительной конуренции, что уменьшает производительность.
Если до этого не встречались с законом и считали количество процессов/тредов «пальцем в небо», то статью стоит посмотреть.
#concurrency #performance
—————————————
Why is Redis So Fast Despite Being Single-Threaded?
Когда говорят о redis, любят вспоминать скорость работы базы. Так, если верить автору поста, редис может обрабатывать 100к запросов в секунду. И это при том, что редис использует single-threaded model для обработки запросов. Автор статьи задался вопросом, почему так происходит, в результате чего появился текст выше.
Статья состоит из четырех частей:
- Почему так быстро работает редис;
- Плюсы подхода;
- Примеры дополнительных оптимизаций;
- Минусы подхода.
В первой части, где описывается, почему так быстро база работает, описывается четыре вещи: работа в памяти, использование оптимизированных типов данных (хеш таблицы), неблокирующий ввод/вывод и low-CPU задачи, которые выполняются в базе. В качестве плюсов найдете отсутствие блокировок, легкость отладки и разработки и отсутствие context switching. В части оптимизаций, автор описывает два подхода, которые добавляют асинхронности (вокруг освобождения памяти и анализа запросов). А в конце дается три проблемных места, о которых стоит помнить, если используйте редис.
Русский перевод
#redis #how_it_works
—————————————
Why Your Workflows Should Be Postgres Rows
Хоть сам плохо отношусь к workflow engines (что не помешало написать собственный энджин), это не мешает читать статьи по теме. Сегодня как раз такой случай, авторы workflow engine инструмента написали статью, в которой делятся опытом по работе с процессами. Основной совет — хранение состояния воркфлоу в двух таблицах постгреса (
Для иллюстрации совета, в начале текста, авторы придумали биллинг процесс из 4 шагов (расчет используемых ресурсов, генерация инвойса, выставление счета и отправка квитанции). Дальше показывается, как хранить состояние всего процесса и результат каждого шага в постгресе (либо другой базе по выбору). Что помогает в отладке и проверки процесса на детерминированность. После описывается, как хранить ошибки и как перезапускать воркфлоу, которые упали.
#workflow_engine
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Amdahl's Law - The Theoretical Relationship Between Speedup and Concurrency
Хоть статья — вторая часть из серии постов о масштабировании рельсы, не ведитесь. Главное в тексте, объяснение закона ограничивающего рост производительности с увеличением процессов. Сам закон назван в честь ученого Джина Амдала, который и придумал закон.
В начале текста объясняется в чем суть закона (с математической формулой). При этом, автор оставил ссылку на видео, где объясняется как и за счет чего взялась формула. Дальше рассказывается, как используя закон Амдала, определить оптимальное количество тредов. При этом, понравилось, что автор делает различие между теоретическими выкладками и реальным количеством тредов, которые стоит выбрать. Связано это с тем, что добавляются дополнительные ограничения в виде излишнего потребления памяти и дополнительной конуренции, что уменьшает производительность.
Если до этого не встречались с законом и считали количество процессов/тредов «пальцем в небо», то статью стоит посмотреть.
#concurrency #performance
—————————————
Why is Redis So Fast Despite Being Single-Threaded?
Когда говорят о redis, любят вспоминать скорость работы базы. Так, если верить автору поста, редис может обрабатывать 100к запросов в секунду. И это при том, что редис использует single-threaded model для обработки запросов. Автор статьи задался вопросом, почему так происходит, в результате чего появился текст выше.
Статья состоит из четырех частей:
- Почему так быстро работает редис;
- Плюсы подхода;
- Примеры дополнительных оптимизаций;
- Минусы подхода.
В первой части, где описывается, почему так быстро база работает, описывается четыре вещи: работа в памяти, использование оптимизированных типов данных (хеш таблицы), неблокирующий ввод/вывод и low-CPU задачи, которые выполняются в базе. В качестве плюсов найдете отсутствие блокировок, легкость отладки и разработки и отсутствие context switching. В части оптимизаций, автор описывает два подхода, которые добавляют асинхронности (вокруг освобождения памяти и анализа запросов). А в конце дается три проблемных места, о которых стоит помнить, если используйте редис.
Русский перевод
#redis #how_it_works
—————————————
Why Your Workflows Should Be Postgres Rows
Хоть сам плохо отношусь к workflow engines (что не помешало написать собственный энджин), это не мешает читать статьи по теме. Сегодня как раз такой случай, авторы workflow engine инструмента написали статью, в которой делятся опытом по работе с процессами. Основной совет — хранение состояния воркфлоу в двух таблицах постгреса (
status, operation_output) поможет упростить работу со сложными процессами.Для иллюстрации совета, в начале текста, авторы придумали биллинг процесс из 4 шагов (расчет используемых ресурсов, генерация инвойса, выставление счета и отправка квитанции). Дальше показывается, как хранить состояние всего процесса и результат каждого шага в постгресе (либо другой базе по выбору). Что помогает в отладке и проверки процесса на детерминированность. После описывается, как хранить ошибки и как перезапускать воркфлоу, которые упали.
#workflow_engine
Forwarded from FEDOR BORSHEV
Sold out на «Коммуникации систем»
Обычно мы закрываем запись в день начала обучения. Сейчас закрываем раньше — на выходных мы набрали столько, сколько хотели. Возьмём больше — придётся жертвовать качеством.
Обычно продажи закрывают без предупреждения, но мы так никогда раньше не делали. Поэтому закрывать одним днём будет нечестно. Если хотели запрыгнуть в последний вагон — до вечера ещё можно купить. Если вас будет слишком много — закроем раньше. Следующий поток будет в конце года, до этого можно будет купить самостоятельный тариф.
У меня нет цели обострить этим постом FOMO или ещё как-то нарастить продажи — нам хватит. В будущем о солдаутах будем предупреждать раньше и со счётчиком.
Спасибо вам за доверие! Надеюсь, оправдаем
Обычно мы закрываем запись в день начала обучения. Сейчас закрываем раньше — на выходных мы набрали столько, сколько хотели. Возьмём больше — придётся жертвовать качеством.
Обычно продажи закрывают без предупреждения, но мы так никогда раньше не делали. Поэтому закрывать одним днём будет нечестно. Если хотели запрыгнуть в последний вагон — до вечера ещё можно купить. Если вас будет слишком много — закроем раньше. Следующий поток будет в конце года, до этого можно будет купить самостоятельный тариф.
У меня нет цели обострить этим постом FOMO или ещё как-то нарастить продажи — нам хватит. В будущем о солдаутах будем предупреждать раньше и со счётчиком.
Спасибо вам за доверие! Надеюсь, оправдаем
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
SQL query optimization: a comprehensive developer's guide
Название статьи говорит само за себя. По ссылке найдете 18 советов по оптимизации как SELECT, так и INSERT и DELETE запросов в реляционных базах. Часть советов подойдет под postgreSQL и mySQL.
Советы делятся на три группы. Так советы вокруг вставки включают следующий список: напоминание о EXPLAIN, работа с индексами, куча советов по джоинам (как типизации, функциям и избеганию лишних джоинов). Кроме этого авторы описывают как использовать subquery, пагинацию, GROUP и window functions. И что делать, что бы возвращать меньше данных, либо использовать меньше данных для селекта.
В случае INSERT найдете три главных совета: посмотреть в сторону специализированных функций (например COPY), отказ от не нужных индексов и оптимизация возвращаемого результата. А для DELETE найдете советы связанные с TRUNCATE, партициями, разбивкой транзакций на чанки и использование фильтрации, вместо удаления данных.
Каждый совет делится на три части: как применить совет, какие риски или потенциальные проблемы в решении и «золотое правило» использования совета. Если плаваете в базах — освежить знания стоит.
#sql
—————————————
How to build MongoDB Event Store
Когда говорят о каноническом event sourcing (который о стейте, а не о event streaming), в качестве event store (место, где хранятся события) используют либо реляционные базы, либо специализированные решения. Хотя на деле, можно взять любую базу (хоть редис), что доказывает автор поста выше.
Начинается текст с объяснения что такое event sourcing и event store (радует, что есть ссылка, которая объясняет в чем разница между event sourcing и event streaming). Дальше описываются базовые требования к event store связанные с хранением и получением данных. Дальше описывается, как хранить события в документах, причем не одно событие в одном документе, а стрим (набор событий) в одном документе. После показывается пример реализации подобного храниения стримов в монге и как добиться optimistic concurrency. В конце найдете список трейдофов, в которые попали как размеры документов в монге (до 16 мегабайт), так и проблемы с созданием read model.
#event_sourcing #event_store
—————————————
How Amazon S3 Stores 350 Trillion Objects with 11 Nines of Durability
Очередная статья о том, как в компании решали проблемы. Сегодня это aws, где оптимизировали работу S3 для поддержки 99,999999999% SLA (11 девяток). При этом, не ждите конкретных советов, статья скорее описание того, как работает сервис в общем и как дизайн решения привели к нужным свойствам.
Статья начинается с объяснения того, что такое s3 (object storage service) и какие свойства у сервиса сейчас: куча девяток в durability, разные виды стораджей, автоматический скейл и так далее. Далее описываются вехи «эволюции» сервиса: от рождения в 2006 году, добавление регионов в 2010, улучшение перформанса в 2015, оптимизация для AI и аналитики в 2018 и так далее. При этом, каждый этап эволюции занесен в одну из двух фаз, в которой требовались уникальные свойства от сервиса. После описывается архитектура сервиса, где найдете информацию о том, как обрабатываются запросы, индексируются и хранятся данные и происходят оптимизации. После начинается блок с объяснением того, как данные из запроса попадают в s3 и как работает индекс.
#how_it_works #durability
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
SQL query optimization: a comprehensive developer's guide
Название статьи говорит само за себя. По ссылке найдете 18 советов по оптимизации как SELECT, так и INSERT и DELETE запросов в реляционных базах. Часть советов подойдет под postgreSQL и mySQL.
Советы делятся на три группы. Так советы вокруг вставки включают следующий список: напоминание о EXPLAIN, работа с индексами, куча советов по джоинам (как типизации, функциям и избеганию лишних джоинов). Кроме этого авторы описывают как использовать subquery, пагинацию, GROUP и window functions. И что делать, что бы возвращать меньше данных, либо использовать меньше данных для селекта.
В случае INSERT найдете три главных совета: посмотреть в сторону специализированных функций (например COPY), отказ от не нужных индексов и оптимизация возвращаемого результата. А для DELETE найдете советы связанные с TRUNCATE, партициями, разбивкой транзакций на чанки и использование фильтрации, вместо удаления данных.
Каждый совет делится на три части: как применить совет, какие риски или потенциальные проблемы в решении и «золотое правило» использования совета. Если плаваете в базах — освежить знания стоит.
#sql
—————————————
How to build MongoDB Event Store
Когда говорят о каноническом event sourcing (который о стейте, а не о event streaming), в качестве event store (место, где хранятся события) используют либо реляционные базы, либо специализированные решения. Хотя на деле, можно взять любую базу (хоть редис), что доказывает автор поста выше.
Начинается текст с объяснения что такое event sourcing и event store (радует, что есть ссылка, которая объясняет в чем разница между event sourcing и event streaming). Дальше описываются базовые требования к event store связанные с хранением и получением данных. Дальше описывается, как хранить события в документах, причем не одно событие в одном документе, а стрим (набор событий) в одном документе. После показывается пример реализации подобного храниения стримов в монге и как добиться optimistic concurrency. В конце найдете список трейдофов, в которые попали как размеры документов в монге (до 16 мегабайт), так и проблемы с созданием read model.
#event_sourcing #event_store
—————————————
How Amazon S3 Stores 350 Trillion Objects with 11 Nines of Durability
Очередная статья о том, как в компании решали проблемы. Сегодня это aws, где оптимизировали работу S3 для поддержки 99,999999999% SLA (11 девяток). При этом, не ждите конкретных советов, статья скорее описание того, как работает сервис в общем и как дизайн решения привели к нужным свойствам.
Статья начинается с объяснения того, что такое s3 (object storage service) и какие свойства у сервиса сейчас: куча девяток в durability, разные виды стораджей, автоматический скейл и так далее. Далее описываются вехи «эволюции» сервиса: от рождения в 2006 году, добавление регионов в 2010, улучшение перформанса в 2015, оптимизация для AI и аналитики в 2018 и так далее. При этом, каждый этап эволюции занесен в одну из двух фаз, в которой требовались уникальные свойства от сервиса. После описывается архитектура сервиса, где найдете информацию о том, как обрабатываются запросы, индексируются и хранятся данные и происходят оптимизации. После начинается блок с объяснением того, как данные из запроса попадают в s3 и как работает индекс.
#how_it_works #durability
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Optimistic Concurrency Control: Alice and Bob Couldn't Sit Together
Проблема распределенных вычислений — гонки связанные с изменением данных. Для чего используют локи. Если говорим о гонках на уровне базы, то кажется, что можно не запариваться, так как в 80% случаев код скорее всего будет работать. Но в цельности, знать о локах и уметь использовать подход придется. А с пониманием работы поможет статья, где автор рассказывает об оптимистичной блокировке в контексте постгреса.
Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.
#sql #optimistic_lock
—————————————
Simple tips for managing any project.
Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:
- понимание пользователей и их нужд;
- определение capabilities, которые закрывают нужды пользователей;
- понимание развития компонентов, которые связаны с capabilities;
- менеджмент компонентов.
Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.
В конце дописаны ответы на некоторые вопросы. Важно отметить, что примеры в тексте показаны только через карты, но заменив карты на поддомены и контексты из DDD, смысл не поменяется.
#management #product
—————————————
How Stripe Processed $1 Trillion in Payments with Zero Downtime
Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.
Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью
#how_it_works #sharding
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Optimistic Concurrency Control: Alice and Bob Couldn't Sit Together
Проблема распределенных вычислений — гонки связанные с изменением данных. Для чего используют локи. Если говорим о гонках на уровне базы, то кажется, что можно не запариваться, так как в 80% случаев код скорее всего будет работать. Но в цельности, знать о локах и уметь использовать подход придется. А с пониманием работы поможет статья, где автор рассказывает об оптимистичной блокировке в контексте постгреса.
Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.
#sql #optimistic_lock
—————————————
Simple tips for managing any project.
Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:
- понимание пользователей и их нужд;
- определение capabilities, которые закрывают нужды пользователей;
- понимание развития компонентов, которые связаны с capabilities;
- менеджмент компонентов.
Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.
В конце дописаны ответы на некоторые вопросы. Важно отметить, что примеры в тексте показаны только через карты, но заменив карты на поддомены и контексты из DDD, смысл не поменяется.
#management #product
—————————————
How Stripe Processed $1 Trillion in Payments with Zero Downtime
Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.
Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью
#how_it_works #sharding
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Second-System Syndrome in Software
Second-system эффект впервые описал Fred Brooks в книге «mythical man-month». Определение звучит как тенденция, при которой небольшую, элегантную и успешную систему, заменяют на раздутую систему с овер инженерингом, которая дороже первой и хуже работает. Автор статьи решил собрать 11 примеров, которые подтверждают second-system эффект. В тексте найдете описание следующих «провалов»:
- Netscape 6
- Windows Vista
- Apple Copland
- Multics (1960s)
- Perl 6 (Raku)
- PHP 6
- Python 3
- Angular 2
- Evernote 10
- Skype “New Skype” 2017
- Snapchat Redesign 2018
Каждый пример состоит из того, как система изначально выглядела и почему была успешной, что изменилось во второй версии, разбор провала и последствия изменений.
В конце текста найдете главные выводы, которые сделал автор. Сюда попали следующие советы:
- помнить, что сделало первую версию успешной;
- избегайте амбиций;
- помните о совместимости;
- дизайн должен идти от пользователей, а не хотелок разработчиков;
- изменяйте систему по частям, а не сразу всю.
#sustem_design #modernization
—————————————
Event versioning strategies for event-driven architectures
Главная проблема асинхронных коммуникаций — сложности в исправлении ошибок и эволюции схемы событий. Если с ошибками еще можно справиться, то с эволюцией поможет только версионирование событий. Автор текста решил разобраться, какой способ управления версиями лучше и для этого рассматривает шесть вариантов:
- добавление версии в название событий;
- добавление версии в payload/metadata события;
- использование отдельных очередей/топиков для каждой версии;
- использование schema registry и schema id в событии;
- отказаться от breaking changes;
- автоматически переводить версию события со старой на новую.
В каждом из вариантов описываются плюсы и минусы, а также ситуации, в которой подход будет работать лучше других.
#events #evolution
—————————————
How DynamoDB Scales: Architecture and Design Lessons
Статья из серии «как в компании X решали проблему Y». На этот раз это DynamoDB и проблема скейлинга базы данных в aws. Чтобы понимать проблему, в 2021 году, в пике, dynamoDB выдерживала 82.9 миллионов rps в пике. При этом, сохраняя однозначную задержку за чтение и запись.
Текст начинается с объяснения того, как работает key-value база: как работают таблицы, которые хранят items, где каждый item — набор из ключей и значений. Логическое партицирование тоже присутствует. При этом pk может быть двух видов — partition key и опциональный sort key. Дальше автор показывает структуру базы и объясняет как запросы от пользователя, через request routing, попадают в ноды бд. Элементы структуры тоже описываются (зачем нужны и что делают). Дальше описываются плюсы базы и за счет чего эти плюсы достигаются (можно менять traffic patterns, контролировать rate-limiting и изоляции и так далее). В конце найдете информацию о том, как работает глобальный контроль допуска для получения и записи данных.
Если до этого не работали с dynamoDB — статья расскажет что ждать от базы и объяснит как технология работает.
#how_it_works #scaling
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Second-System Syndrome in Software
Second-system эффект впервые описал Fred Brooks в книге «mythical man-month». Определение звучит как тенденция, при которой небольшую, элегантную и успешную систему, заменяют на раздутую систему с овер инженерингом, которая дороже первой и хуже работает. Автор статьи решил собрать 11 примеров, которые подтверждают second-system эффект. В тексте найдете описание следующих «провалов»:
- Netscape 6
- Windows Vista
- Apple Copland
- Multics (1960s)
- Perl 6 (Raku)
- PHP 6
- Python 3
- Angular 2
- Evernote 10
- Skype “New Skype” 2017
- Snapchat Redesign 2018
Каждый пример состоит из того, как система изначально выглядела и почему была успешной, что изменилось во второй версии, разбор провала и последствия изменений.
В конце текста найдете главные выводы, которые сделал автор. Сюда попали следующие советы:
- помнить, что сделало первую версию успешной;
- избегайте амбиций;
- помните о совместимости;
- дизайн должен идти от пользователей, а не хотелок разработчиков;
- изменяйте систему по частям, а не сразу всю.
#sustem_design #modernization
—————————————
Event versioning strategies for event-driven architectures
Главная проблема асинхронных коммуникаций — сложности в исправлении ошибок и эволюции схемы событий. Если с ошибками еще можно справиться, то с эволюцией поможет только версионирование событий. Автор текста решил разобраться, какой способ управления версиями лучше и для этого рассматривает шесть вариантов:
- добавление версии в название событий;
- добавление версии в payload/metadata события;
- использование отдельных очередей/топиков для каждой версии;
- использование schema registry и schema id в событии;
- отказаться от breaking changes;
- автоматически переводить версию события со старой на новую.
В каждом из вариантов описываются плюсы и минусы, а также ситуации, в которой подход будет работать лучше других.
#events #evolution
—————————————
How DynamoDB Scales: Architecture and Design Lessons
Статья из серии «как в компании X решали проблему Y». На этот раз это DynamoDB и проблема скейлинга базы данных в aws. Чтобы понимать проблему, в 2021 году, в пике, dynamoDB выдерживала 82.9 миллионов rps в пике. При этом, сохраняя однозначную задержку за чтение и запись.
Текст начинается с объяснения того, как работает key-value база: как работают таблицы, которые хранят items, где каждый item — набор из ключей и значений. Логическое партицирование тоже присутствует. При этом pk может быть двух видов — partition key и опциональный sort key. Дальше автор показывает структуру базы и объясняет как запросы от пользователя, через request routing, попадают в ноды бд. Элементы структуры тоже описываются (зачем нужны и что делают). Дальше описываются плюсы базы и за счет чего эти плюсы достигаются (можно менять traffic patterns, контролировать rate-limiting и изоляции и так далее). В конце найдете информацию о том, как работает глобальный контроль допуска для получения и записи данных.
Если до этого не работали с dynamoDB — статья расскажет что ждать от базы и объяснит как технология работает.
#how_it_works #scaling
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Lyft Uses ML to Make 100 Million Predictions A Day
Очередная статья из серии «как в компании X решали проблему Y?». На этот раз это Lyft, который занимается такси и прокатом транспорта, в котором необходимо делать кучу прогнозов. Под прогнозами подразумевается — расчет цены, антифрод, время ожидания, определение водителя на поездку. Из-за требований по перфомансу, в компании столкнулись с двумя проблемами: Data Plane pressure (нетворк, cpu и так далее) и Control Plane complexity (деплой, ролбеки, версионирование, совместимость и так далее). При этом, расчеты проводились в одном монолите, из-за чего решением стала распределенная система.
В начале статьи рассказывается о структуре системы, которая получилась и что каждый компонент делает. Кроме этого затрагивается работа синхронных запросов и работы кастомного ml кода. После описываются подходы к ownership и изоляции сервисов. Дальше рассказывается о генераторе конфигов, который собирает необходимую информацию под сервис и как происходит самотестирование. В конце найдете описание жизненного цикла запроса связанного с прогнозами.
#how_it_works #ml
—————————————
GraphQL Federation Isn’t Just an API Problem — It’s an Organisational One
GraphQL federation — подход, при котором несколько GraphQL схем ститчатся в одну схему и клиенты работают с одним гейтвеем, вместо вызова разных эндпоинтов. На бумаге выглядит красиво, на деле — детали убивают идею в ноль. Статья выше от автора, который разочаровался в GraphQL federation, хотя сначала думал, что подход поможет скрыть от клиентов сложность, перенеся ее на сторону бекенда. Но в реальности, началась путаница с сущностями и отношениями между ними, что увеличило когнитивную нагрузку. Дальше автор приходит к мысли, что объединяя схемы, за которые отвечают разные команды, в одну общую — понимание что происходит теряется окончательно. В конце найдете три совета: воспринимать GraphQL как язык запросов, а не как к API, принимать сложность модели данных, а не скрывать ее и стоит помнить, что GraphQL federation объединяет не только технические сервисы, но и людей между собой.
#graphQL
—————————————
Kafka без дисков: плюсы и минусы KIP‑1150 \(Diskless Topics\)
Изначально статья описывает новую фичу кафки — KIP‑1150, в которой брокер может писать сообщения сразу в облачные хранилища (например в s3), а не на диск брокера. Благодаря чему экономятся деньги и помогает с масштабированием в облаке. Из минусов — увеличивается latency и добавляет точку отказа.
Дальше автор описывает в деталях, как должна новая фича работать и какие плюсы будут (кроме цены и скейлинга упоминается гео-репликация и гибкость решения). Минусы тоже описываются подробнее — решение не поможет с global ordering для всех партиций.
Отдельно рекомендую посмотреть комментарии, где появляется разработчик кафки и отвечает на вопросы: фичу стоит ждать в течении трех лет, когда подойдет решение, а когда нет (если задержка в секунду ок — стоит подумать), порядок задержек и что с горизонтальным масштабированием. И попутно, посмотрите обсуждение о том, возможно ли отказаться от партишенов и лидеров и полностью переехать на s3.
#kafka
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Lyft Uses ML to Make 100 Million Predictions A Day
Очередная статья из серии «как в компании X решали проблему Y?». На этот раз это Lyft, который занимается такси и прокатом транспорта, в котором необходимо делать кучу прогнозов. Под прогнозами подразумевается — расчет цены, антифрод, время ожидания, определение водителя на поездку. Из-за требований по перфомансу, в компании столкнулись с двумя проблемами: Data Plane pressure (нетворк, cpu и так далее) и Control Plane complexity (деплой, ролбеки, версионирование, совместимость и так далее). При этом, расчеты проводились в одном монолите, из-за чего решением стала распределенная система.
В начале статьи рассказывается о структуре системы, которая получилась и что каждый компонент делает. Кроме этого затрагивается работа синхронных запросов и работы кастомного ml кода. После описываются подходы к ownership и изоляции сервисов. Дальше рассказывается о генераторе конфигов, который собирает необходимую информацию под сервис и как происходит самотестирование. В конце найдете описание жизненного цикла запроса связанного с прогнозами.
#how_it_works #ml
—————————————
GraphQL Federation Isn’t Just an API Problem — It’s an Organisational One
GraphQL federation — подход, при котором несколько GraphQL схем ститчатся в одну схему и клиенты работают с одним гейтвеем, вместо вызова разных эндпоинтов. На бумаге выглядит красиво, на деле — детали убивают идею в ноль. Статья выше от автора, который разочаровался в GraphQL federation, хотя сначала думал, что подход поможет скрыть от клиентов сложность, перенеся ее на сторону бекенда. Но в реальности, началась путаница с сущностями и отношениями между ними, что увеличило когнитивную нагрузку. Дальше автор приходит к мысли, что объединяя схемы, за которые отвечают разные команды, в одну общую — понимание что происходит теряется окончательно. В конце найдете три совета: воспринимать GraphQL как язык запросов, а не как к API, принимать сложность модели данных, а не скрывать ее и стоит помнить, что GraphQL federation объединяет не только технические сервисы, но и людей между собой.
#graphQL
—————————————
Kafka без дисков: плюсы и минусы KIP‑1150 \(Diskless Topics\)
Изначально статья описывает новую фичу кафки — KIP‑1150, в которой брокер может писать сообщения сразу в облачные хранилища (например в s3), а не на диск брокера. Благодаря чему экономятся деньги и помогает с масштабированием в облаке. Из минусов — увеличивается latency и добавляет точку отказа.
Дальше автор описывает в деталях, как должна новая фича работать и какие плюсы будут (кроме цены и скейлинга упоминается гео-репликация и гибкость решения). Минусы тоже описываются подробнее — решение не поможет с global ordering для всех партиций.
Отдельно рекомендую посмотреть комментарии, где появляется разработчик кафки и отвечает на вопросы: фичу стоит ждать в течении трех лет, когда подойдет решение, а когда нет (если задержка в секунду ок — стоит подумать), порядок задержек и что с горизонтальным масштабированием. И попутно, посмотрите обсуждение о том, возможно ли отказаться от партишенов и лидеров и полностью переехать на s3.
#kafka
HTML Embed Code: