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

Давайте договоримся, угадать будущие требования невозможно. Но реально предположить область, в которой система будет развиваться в будущем. Один из способов предположения описал в сегодняшнем ответе. Никакой кофейной гущи, будем определять 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