2pegramming

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

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

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

A Model for Debug Complexity

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

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

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

#debugging #math_models #fintess_functions

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

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

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

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

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

#ml #errors

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

How we run migrations across 2,800 microservices

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

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

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

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

#distributed_systems

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

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

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

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

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

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

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

How Shopify Manages its Petabyte Scale MySQL Database

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

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

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

#how_it_works #sql

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

Testing exceptions

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

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

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

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

#testing #tdd

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

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

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

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

#cost #desicion_making

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

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

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

Github: Using SQL's Turing Completeness to Build Tetris

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

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

#sql

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

Exactly-Once Payments At Airbnb

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

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

#how_it_works #payment #idempotency

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

Postgres webhooks with pgstream

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

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

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

#data_streaming #cdc

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

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

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

Counting Billions of Content Usage at Canva

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

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

#how_it_works

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

Architectural Retrospectives: the Key to Getting Better at Architecting

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

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

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

#decision_making #retro #ppl_managment

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

Testing Automation, What are Pyramids and Diamonds?

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

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

#testing #testing_pyramid

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

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

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

How Netflix Content Engineering makes a federated graph searchable

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

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

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

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

#how_it_works #graphql #searching

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

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

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

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

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

#oop #code_metrics

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

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

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

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

#db #acid

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

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

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

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

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

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

#how_it_works #kafka

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

How to deal with Technical Debt in legacy projects

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

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

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

#tech_debt

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

API Versioning at Monite

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

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

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

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

#api #versioning #sync_communication

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

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

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

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

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

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

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

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

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

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

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

Historical Data in Databases. Audit Tables. Event Sourcing

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

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

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

#event_sourcing #audit

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

The Trillion Message Kafka Setup at Walmart

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

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

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

#how_it_works #kafka #events

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

Good programmers worry about data structures and their relationships

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

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

#conceptual_data_model #data_model

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

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

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

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

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

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

#how_it_works #finances #scalability

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

Kafka and Event Streaming — simple explanation

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

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

#event_driven #communications

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

Six Degrees of Kevin Bacon - Postgres Style

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

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

#graph #graphDB #psql

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

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

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

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

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

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

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

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

Questions about Team Topologies

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

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

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

#team_topologies #team_managment

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

How Stripe Scaled to 5 Million Database Queries Per Second

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

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

#how_it_works #scalability #db

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

A Web API Design Methodology

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

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

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

#http_api

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

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

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

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

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

How Netflix Manages 238 Million Memberships?

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

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

#how_it_works #kafka

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

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

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

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

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

#failures #systems

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

Failure testing Kafka

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

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

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

#kafka #testing #chaos_engineering

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

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

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

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

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

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

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

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

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

It’s Time to Rethink Event Sourcing

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

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

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

#event_sourcing #cdc

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

Creating a Git commit: The Hard Way

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

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

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

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

#git #how_it_works

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

Just use Postgres

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

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

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

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

#data_bases #psql

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

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

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

An example of example-driven development

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

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

#testing #system_validation

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

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

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

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

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

#system_analysis #data_managment

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

10 Kubernetes Cost Optimization Techniques

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

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

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

#finops #cost_managment #k8s

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

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

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

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

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

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

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

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

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

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

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

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

#how_it_works #kafka

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

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

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

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

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

#how_it_works #graphQL

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

Building and scaling Notion’s data lake

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

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

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

#how_it_works #etl #datalake

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

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

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

Inside Shopify’s Modular Monolith

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

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

#how_it_works

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

How to Share Data Between Microservices on High Scale

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

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

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

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

#communications

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

The Problem with OpenTelemetry

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

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

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

#observability #open_telementry