Пятничное чтиво
Канал уходит в ежегодный зимний отпуск, встретимся после 15 января. Всем большое спасибо кто читает канал, комментирует и задает вопросы ❤️
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Использование цвета при анализе и проектировании систем
Может показаться, что работа с цветами ближе к дизайну, UI или цветовой схеме в редакторе. Но в случае диаграмм и моделей цвет также может улучшить восприятие. Например, благодаря цветным стикерам в event storming, можно быстро высокоуровнево разобраться в модели, бегло посмотрев на нее.
Автор статьи ставит целью сделать шаг к стандартизации цветовых решений для схем. Сам текст делится на три части. В первой говорится о «базе» – концепциях цветового восприятия человеком:
- где лучше работает монохром, а где цветные диаграммы;
- как цвета влияют на восприятие (теперь хочу проверить вывод, что для лучшего запоминания диаграммы стоит использовать холодные цвета, а не монохром или теплые оттенки);
- как человек определяет “неестественные” цвета в зависимости от контекста (например зеленую листву в снежном поле)
Во второй части рассматриваются вопросы цветового кодирования - присвоение определенным цветам определенных смыслов для ускорения восприятия информации (красный - опасно, море на карте синее и так далее).
А в последней - рассматривается, какие подходы связанные с цветами можно использовать в анализе и проектировании (ниже пара примеров):
- использование «светофорных цветов» для дерева решений;
- выделение разных систем разными цветами;
- объединение одним цветом разных семейств;
- использование цветового обозначения для UML class diagram;
#design #documentation
—————————————
API Evolution - REST vs RPC
Каждый раз когда начинается вынос сервиса из монолита, появляется спор который преследует меня из проекта в проект – использование REST или RPC как кросс сервисной коммуникации. Короткая статья выше пытается ответить на этот вопрос и предложить критерии оценки, благодаря которым можно выбрать, что лучше подойдет для конкретного случая.
В начале, автор рассуждает о том, что такое процедура в терминологии RPC - стейтлесс функция, а также дается сравнение между процедурой и ооп вызовом метода. После рассказывается о ресурсе в терминологии REST. Тут автор рассуждает о разнице между verb и method терминологией и когда что использовать. Для примера автор упоминает POST метод, который воспринимается как create, хотя на деле это идемпотентный «catch all» метод. В конце автор подводит итоги и делится пониманием в каком из случаев подойдет REST, а где RPC.
Из минусов статьи - если ждете лонгрид с детальным объяснением каждого подхода или кучей деталей и примеров. Если ждете что-то подобное, лучше пропустить.
#communications #rest #rpc
—————————————
How to design an efficient Idempotency API
В математическом смысле идемпотентность - свойство при котором применение операции к объекту будет давать тот же результат, что и в первый раз. В случае it под идемпотентностью подразумевают, что многократное повторение действия эквивалентно однократному вызову. Когда дело касается идемпотентного API - статья про стажера Васю все еще в моем сердце.
В сегодняшней статье, кроме объяснения идемпотентности, так же говорит о том, как улучшить перфоманс (просто добавь кеша). А после, дается flow реализации (в виде модели), состоящим из 8 процессов и 5 условий (важно, что auth должен идти до). В самом флоу предлагается использовать
#communications #idempotency
Канал уходит в ежегодный зимний отпуск, встретимся после 15 января. Всем большое спасибо кто читает канал, комментирует и задает вопросы ❤️
Буду рад предложениям, вопросам и идеям. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Использование цвета при анализе и проектировании систем
Может показаться, что работа с цветами ближе к дизайну, UI или цветовой схеме в редакторе. Но в случае диаграмм и моделей цвет также может улучшить восприятие. Например, благодаря цветным стикерам в event storming, можно быстро высокоуровнево разобраться в модели, бегло посмотрев на нее.
Автор статьи ставит целью сделать шаг к стандартизации цветовых решений для схем. Сам текст делится на три части. В первой говорится о «базе» – концепциях цветового восприятия человеком:
- где лучше работает монохром, а где цветные диаграммы;
- как цвета влияют на восприятие (теперь хочу проверить вывод, что для лучшего запоминания диаграммы стоит использовать холодные цвета, а не монохром или теплые оттенки);
- как человек определяет “неестественные” цвета в зависимости от контекста (например зеленую листву в снежном поле)
Во второй части рассматриваются вопросы цветового кодирования - присвоение определенным цветам определенных смыслов для ускорения восприятия информации (красный - опасно, море на карте синее и так далее).
А в последней - рассматривается, какие подходы связанные с цветами можно использовать в анализе и проектировании (ниже пара примеров):
- использование «светофорных цветов» для дерева решений;
- выделение разных систем разными цветами;
- объединение одним цветом разных семейств;
- использование цветового обозначения для UML class diagram;
#design #documentation
—————————————
API Evolution - REST vs RPC
Каждый раз когда начинается вынос сервиса из монолита, появляется спор который преследует меня из проекта в проект – использование REST или RPC как кросс сервисной коммуникации. Короткая статья выше пытается ответить на этот вопрос и предложить критерии оценки, благодаря которым можно выбрать, что лучше подойдет для конкретного случая.
В начале, автор рассуждает о том, что такое процедура в терминологии RPC - стейтлесс функция, а также дается сравнение между процедурой и ооп вызовом метода. После рассказывается о ресурсе в терминологии REST. Тут автор рассуждает о разнице между verb и method терминологией и когда что использовать. Для примера автор упоминает POST метод, который воспринимается как create, хотя на деле это идемпотентный «catch all» метод. В конце автор подводит итоги и делится пониманием в каком из случаев подойдет REST, а где RPC.
Из минусов статьи - если ждете лонгрид с детальным объяснением каждого подхода или кучей деталей и примеров. Если ждете что-то подобное, лучше пропустить.
#communications #rest #rpc
—————————————
How to design an efficient Idempotency API
В математическом смысле идемпотентность - свойство при котором применение операции к объекту будет давать тот же результат, что и в первый раз. В случае it под идемпотентностью подразумевают, что многократное повторение действия эквивалентно однократному вызову. Когда дело касается идемпотентного API - статья про стажера Васю все еще в моем сердце.
В сегодняшней статье, кроме объяснения идемпотентности, так же говорит о том, как улучшить перфоманс (просто добавь кеша). А после, дается flow реализации (в виде модели), состоящим из 8 процессов и 5 условий (важно, что auth должен идти до). В самом флоу предлагается использовать
request_id, который сохраняется в кеше с ответом (автор советует использовать setnx для сохранения в редис). Кроме редиса, автор предлагает хранить кеш еще в DB и проверять наличие, после этого выполнять запрос и потом атомарно обновлять кеш.#communications #idempotency
Пятничное чтиво
Медленно возвращаюсь из отпуска с рассылкой статей. Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Error Handling in Asynchronous Systems
В асинхронных коммуникациях потеря данных приводит к тому, что данные не восстановить. Т.е. если произошла ошибка с обработкой события и ничего не записалось – о данных можно забыть. В случае синхронного response-request запроса можно отправить ошибку и тем самым попросить клиента отправить запрос по новой, т.е. данные не потеряются. Поэтому так важно уметь обрабатывать ошибки в асинхронных коммуникациях, чтобы не терять данные, которые восстановить проблематично.
Сегодняшняя статья описывает подход, который называется workflow event pattern. Идея в создании отдельной очереди для ошибочных событий и автоматической попытки исправить ошибочное сообщение. Если не получилось спустя N попыток – отправить сообщение человеку. Сама статья состоит из двух частей: в начале описывается что может пойти не так в распределенной системе (от потери интернета, до конкурирующих событий). Во второй части описывается паттерн, дается картинка «движения» событий и описывается каждый из шагов.
#error_handling #async_communications
—————————————
How we organize and get things done with SERVICEOWNERS
Если работали с большим монолитом, с большой вероятностью использовали CODEOWNERS файл для указания кто за какую часть кода отвечает. Т.е. настраивали людей, без апрува которых, изменения кода не принимаются на ревью. В случае распределенной системы, из нескольких сервисов, такого файла может не хватить. В таком случае компании либо берут готовый, либо пишут собственный сервис каталог, который показывает информацию о каждом сервисе. С похожей проблемой столкнулись инженеры гитхаба, а по ссылки можно прочитать, как реализована логика поиска овнеров для каждого сервиса в компании и как все связано с CODEOWNERS. Если коротко - инженеры написали библиотеку serviceowners, которая позволяет матчить сервисы и ответственных между собой в каждом из репозиториев компании. На данный момент решение не опенсорсное и статья в общих чертах описывает как подход работает.
#codeowners #ppl_managment
—————————————
Реализация консенсусного алгоритма Raft
Если решите писать распределенные системы, например базы данных, то без консенсусных алгоритмов будет сложно. Благодаря таким алгоритмам достигается надежность и согласованность между нодами, например в кафке или в кликхаусе (если правильно помню). Алгоритмов много (знаю о paxos и chandra–toueg алгоритмах), самый попсовый из них - raft.
Алгоритм состоит из трех основных видов нод: leader (нода, которая системой управляет), followers (ноды, которые выполняют команды лидера) и candidates (ноды, которые «хотят» стать лидерами). При этом, выбор лидера происходит определенным образом. Кроме того, используется лог операций, который синхронизируется между нодами.
Много лет назад я пытался написать raft алгоритм на стриме (тогда не вышло, повторять пока желание отсутствует 😅). Поэтому сегодня статья, которая описывает как реализовать алгоритм на питоне. Автор описывает виды нод, как реализуется журнал операций и алгоритм выбора лидера. Описывается за что лидер нода отвечает, как обеспечивается целостность данных передаваемых между нодами и как происходит репликация данных. Каждая описанная часть статьи сопровождается примерами на питоне, а в конце статьи найдете список улучшений алгоритма, куда вошла кластеризация, масштабирование, управление состоянием нод, фикс проблемы с бесконечным выбором лидеров. Кроме этого, дается сравнение между raft, paxos и zab алгоритмами.
#distributed_systems #raft
Медленно возвращаюсь из отпуска с рассылкой статей. Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Error Handling in Asynchronous Systems
В асинхронных коммуникациях потеря данных приводит к тому, что данные не восстановить. Т.е. если произошла ошибка с обработкой события и ничего не записалось – о данных можно забыть. В случае синхронного response-request запроса можно отправить ошибку и тем самым попросить клиента отправить запрос по новой, т.е. данные не потеряются. Поэтому так важно уметь обрабатывать ошибки в асинхронных коммуникациях, чтобы не терять данные, которые восстановить проблематично.
Сегодняшняя статья описывает подход, который называется workflow event pattern. Идея в создании отдельной очереди для ошибочных событий и автоматической попытки исправить ошибочное сообщение. Если не получилось спустя N попыток – отправить сообщение человеку. Сама статья состоит из двух частей: в начале описывается что может пойти не так в распределенной системе (от потери интернета, до конкурирующих событий). Во второй части описывается паттерн, дается картинка «движения» событий и описывается каждый из шагов.
#error_handling #async_communications
—————————————
How we organize and get things done with SERVICEOWNERS
Если работали с большим монолитом, с большой вероятностью использовали CODEOWNERS файл для указания кто за какую часть кода отвечает. Т.е. настраивали людей, без апрува которых, изменения кода не принимаются на ревью. В случае распределенной системы, из нескольких сервисов, такого файла может не хватить. В таком случае компании либо берут готовый, либо пишут собственный сервис каталог, который показывает информацию о каждом сервисе. С похожей проблемой столкнулись инженеры гитхаба, а по ссылки можно прочитать, как реализована логика поиска овнеров для каждого сервиса в компании и как все связано с CODEOWNERS. Если коротко - инженеры написали библиотеку serviceowners, которая позволяет матчить сервисы и ответственных между собой в каждом из репозиториев компании. На данный момент решение не опенсорсное и статья в общих чертах описывает как подход работает.
#codeowners #ppl_managment
—————————————
Реализация консенсусного алгоритма Raft
Если решите писать распределенные системы, например базы данных, то без консенсусных алгоритмов будет сложно. Благодаря таким алгоритмам достигается надежность и согласованность между нодами, например в кафке или в кликхаусе (если правильно помню). Алгоритмов много (знаю о paxos и chandra–toueg алгоритмах), самый попсовый из них - raft.
Алгоритм состоит из трех основных видов нод: leader (нода, которая системой управляет), followers (ноды, которые выполняют команды лидера) и candidates (ноды, которые «хотят» стать лидерами). При этом, выбор лидера происходит определенным образом. Кроме того, используется лог операций, который синхронизируется между нодами.
Много лет назад я пытался написать raft алгоритм на стриме (тогда не вышло, повторять пока желание отсутствует 😅). Поэтому сегодня статья, которая описывает как реализовать алгоритм на питоне. Автор описывает виды нод, как реализуется журнал операций и алгоритм выбора лидера. Описывается за что лидер нода отвечает, как обеспечивается целостность данных передаваемых между нодами и как происходит репликация данных. Каждая описанная часть статьи сопровождается примерами на питоне, а в конце статьи найдете список улучшений алгоритма, куда вошла кластеризация, масштабирование, управление состоянием нод, фикс проблемы с бесконечным выбором лидеров. Кроме этого, дается сравнение между raft, paxos и zab алгоритмами.
#distributed_systems #raft
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Building responsive, scalable and fault tolerant microservices: An unconventional approach with replicated cache
В случае распределенных систем могут забыть, что данные можно не только синхронно забирать из сервиса, но и асинхронно реплицировать у себя в нужном виде и использовать без ограничений связанных с доступностью сервисов. В частности, когда данные читать приходится часто.
Сегодняшняя статья рассказывает о том, как использовать реплицируемый кеш для подобных случаев. Сначала автор рассказывает о том, какие технологии могут помочь (там в in-memory решения), после идет пример расчета необходимого места под данные. После этого дается пример системы, которая считает сколько автомобилист должен платить за парковку в случае системы из нескольких сервисов. В конце перечисляются проблемы подхода: необходимость наполнения данных, возможные проблемы с объемом данных и возможные проблемы с синхронизацией. В конце кусок с реализацией примера на дотнете.
#data_streaming #cache #eda
—————————————
Crafting Process-Centric Domain Models in DDD
Если верить системной инженерии, система состоит из поведения и структуры (формы/состояния). При этом, нельзя сказать, что поведения и структуры одинаковое количество для любого проекта: может быть как больше структуры (например, в агрегаторах информации), так и больше упора на процессы (в автоматизации, например полива). В программировании может возникнуть ситуация, когда использование MVC меняет восприятие и каждая первая система строится вокруг формы (моделей), а поведение накручивается поверх. Взглянуть на систему как на набор процессов может помочь event storming, но автор статьи выше предлагает другой подход, основанный на process-centric подходе.
Для этого, предлагается рассматривать доменную модель как процесс, который состоит из действий, транзишенов и состояний в рамках общего языка. В качестве примера, автор рассматривает как построить подобную модель для подготовки заказа. Дальше рассказывается как реализовать полученную модель (тут появляются агрегаты). После даются плюсы подхода (о минусах автор не написал, к сожалению). Ну и как тех требование - необходимо workflow engine и элемента для выполнения флоу (оркестратора).
#ddd #workflow
—————————————
How to design a Read Heavy system ? Some strategies and best practices
Короткая статья в которой описываются стратегии, помогающие в проектировании систем с большим количеством read запросов. Стратегии делятся на две части: относительно базы данных и относительно самого приложения.
Описанные стратегии вокруг бд:
- Использование read реплики;
- Работа с индексами;
- Денормализация данных;
- Кеширование бд;
- Настройка мониторинга бд;
А стратегии вокруг приложения включают в себя:
- Кеширование;
- Асинхронный процессинг
- Выбор оптимизированных на чтение бд
- Использование CDN
- Настройка лоад балансинга
- Выбор оптимального скейлинга;
Статья подробно не описывает каждый способ, но как список подходов для дальнейшего изучения подойдет.
#performance
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Building responsive, scalable and fault tolerant microservices: An unconventional approach with replicated cache
В случае распределенных систем могут забыть, что данные можно не только синхронно забирать из сервиса, но и асинхронно реплицировать у себя в нужном виде и использовать без ограничений связанных с доступностью сервисов. В частности, когда данные читать приходится часто.
Сегодняшняя статья рассказывает о том, как использовать реплицируемый кеш для подобных случаев. Сначала автор рассказывает о том, какие технологии могут помочь (там в in-memory решения), после идет пример расчета необходимого места под данные. После этого дается пример системы, которая считает сколько автомобилист должен платить за парковку в случае системы из нескольких сервисов. В конце перечисляются проблемы подхода: необходимость наполнения данных, возможные проблемы с объемом данных и возможные проблемы с синхронизацией. В конце кусок с реализацией примера на дотнете.
#data_streaming #cache #eda
—————————————
Crafting Process-Centric Domain Models in DDD
Если верить системной инженерии, система состоит из поведения и структуры (формы/состояния). При этом, нельзя сказать, что поведения и структуры одинаковое количество для любого проекта: может быть как больше структуры (например, в агрегаторах информации), так и больше упора на процессы (в автоматизации, например полива). В программировании может возникнуть ситуация, когда использование MVC меняет восприятие и каждая первая система строится вокруг формы (моделей), а поведение накручивается поверх. Взглянуть на систему как на набор процессов может помочь event storming, но автор статьи выше предлагает другой подход, основанный на process-centric подходе.
Для этого, предлагается рассматривать доменную модель как процесс, который состоит из действий, транзишенов и состояний в рамках общего языка. В качестве примера, автор рассматривает как построить подобную модель для подготовки заказа. Дальше рассказывается как реализовать полученную модель (тут появляются агрегаты). После даются плюсы подхода (о минусах автор не написал, к сожалению). Ну и как тех требование - необходимо workflow engine и элемента для выполнения флоу (оркестратора).
#ddd #workflow
—————————————
How to design a Read Heavy system ? Some strategies and best practices
Короткая статья в которой описываются стратегии, помогающие в проектировании систем с большим количеством read запросов. Стратегии делятся на две части: относительно базы данных и относительно самого приложения.
Описанные стратегии вокруг бд:
- Использование read реплики;
- Работа с индексами;
- Денормализация данных;
- Кеширование бд;
- Настройка мониторинга бд;
А стратегии вокруг приложения включают в себя:
- Кеширование;
- Асинхронный процессинг
- Выбор оптимизированных на чтение бд
- Использование CDN
- Настройка лоад балансинга
- Выбор оптимального скейлинга;
Статья подробно не описывает каждый способ, но как список подходов для дальнейшего изучения подойдет.
#performance
Запускаем шестой поток курса по асинхронным коммуникациям. Старт 15 февраля, закончим 21 марта. Промокод на 10% скидку PEPEPARROT, действует до 5 февраля.
Этот поток будет последнем в текущем виде. После курс уйдет в архив, а я сяду думать как его улучшить (к сожалению гарантий, когда курс вернется дать никаких не могу).
Курс позволит профессионально вырасти и улучшить знания вокруг проектирования систем и работы с событиями. Если в анализе систем больше упор делался на поиск элементов, связей и характеристик, то в АА больший упор на event-driven коммуникацию: отправка событий, эволюция схем, обработка ошибок, объяснение логики поиска событий из поведения системы и данных, необходимых для ее работы, разделение событий на два вида - бизнесовые и "технические". А также объяснить процесс мышления "что делать важнее чем как что-то делать". Ну и до кучи - показать и рассказать что делать в случае проблем.
Кроме того, оказалось, что курс помогает найти новую работу или улучшить положение на старой работе. У нас были случаи, когда ученики прошлых потоков проходили собеседования во время обучения и получали офферы. Очень хочу верить, что тенденция продолжится и на рынке окажется больше инженеров, которые справятся с асинхронными взаимодействиями в распределенных системах.
К тому же, в прошлый раз попробовали провести дополнительные факультативы, где делали event storming, модель данных и говорили о событийном аккаунтинге/биллинге. В этот раз воркшоп будет по заявкам, с вас тема, с меня воркшоп. Для меня это способ помочь людям с тем, что я знаю и умею - системы с асинхронными коммуникациями и проектирование систем в целом, а также пошарить свой опыт в живую.
Промокод на 10% скидку PEPEPARROT, действует до 5 февраля.
Этот поток будет последнем в текущем виде. После курс уйдет в архив, а я сяду думать как его улучшить (к сожалению гарантий, когда курс вернется дать никаких не могу).
Курс позволит профессионально вырасти и улучшить знания вокруг проектирования систем и работы с событиями. Если в анализе систем больше упор делался на поиск элементов, связей и характеристик, то в АА больший упор на event-driven коммуникацию: отправка событий, эволюция схем, обработка ошибок, объяснение логики поиска событий из поведения системы и данных, необходимых для ее работы, разделение событий на два вида - бизнесовые и "технические". А также объяснить процесс мышления "что делать важнее чем как что-то делать". Ну и до кучи - показать и рассказать что делать в случае проблем.
Кроме того, оказалось, что курс помогает найти новую работу или улучшить положение на старой работе. У нас были случаи, когда ученики прошлых потоков проходили собеседования во время обучения и получали офферы. Очень хочу верить, что тенденция продолжится и на рынке окажется больше инженеров, которые справятся с асинхронными взаимодействиями в распределенных системах.
К тому же, в прошлый раз попробовали провести дополнительные факультативы, где делали event storming, модель данных и говорили о событийном аккаунтинге/биллинге. В этот раз воркшоп будет по заявкам, с вас тема, с меня воркшоп. Для меня это способ помочь людям с тем, что я знаю и умею - системы с асинхронными коммуникациями и проектирование систем в целом, а также пошарить свой опыт в живую.
Промокод на 10% скидку PEPEPARROT, действует до 5 февраля.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Building WebSocket chat app from scratch
По работе возникла проблема, что нужно было сделать базовый чат на вебсокетах, готовое решение, которое удовлетворяло бы требованиям не нашлось. Поэтому пошел смотреть что есть на тему, наткнулся на ссылку выше. В этот раз в ссылках не статья, а туториал о том, как написать чат на вебсокетах с группами и прочим.
Из описанных в туториале тем, заинтересовало:
- моделирование данных необходимых для чата;
- описание необходимого набора эндпоинтов;
- настройка messages recovery;
- использование outbox паттерна для публикации сообщений;
- как скейлиться на 100к человек;
- список улучшений и список советов;
Важно отметить, что туториал от разработчиков centirfugo, но идеи и подходы можно использовать с другими технологиями.
#how_it_works #websockets #chat
—————————————
Consistency Patterns
Одной из трех проблем распределенных систем (привет CAP теорема) является консистентность, т.е. данные не противоречат друг другу в один момент времени. Статья выше рассказывает о консистентности, точнее про три вида: strong (когда данные для чтения всегда аналогичны данным последней записи), eventual (когда данные на чтение и запись могут отличаться, но будут одинаковыми в будущем) и weak (когда данные могут быть согласованы, а могут и нет). Для каждого вида указываются плюсы и минусы, а также дается картинка с объяснением подхода. Понравилось, что автор сделал таблицу с трейдоффами подходов. В конце говорится еще о двух подходах: linearizability и causal consistency.
Если ничего не знаете о консистентности - статья хороший энтри гайд в тему.
#consistency
—————————————
arc42 Quality Model
Во время работы с характеристиками возникает вопрос - как получить нужные характеристики для дальнейшего анализа или принятия решений. Можно воспользоваться сторонними концепциями как сделано в курсе по анализу систем (DDD, системной инженерией, логикой и так далее), а можно пойти другим путем.
Так, авторы arc42 (это фреймворк описания архитектуры) решили сделать фреймворк/модель по работе с характеристиками системы. Прикол модели в том, что на сайте можно найти 100+ примеров из требований, которые говорят об определенной характеристики (смотреть секцию «Examples of Quality Requirements»).
В качестве целей инициативы указывают:
- Минимальность и покрытие всех возможных продуктов;
- понятность объяснения характеристик;
- бесплатность, открытость, технологическую независимость и так далее;
#characteristics #quality_attributes
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Building WebSocket chat app from scratch
По работе возникла проблема, что нужно было сделать базовый чат на вебсокетах, готовое решение, которое удовлетворяло бы требованиям не нашлось. Поэтому пошел смотреть что есть на тему, наткнулся на ссылку выше. В этот раз в ссылках не статья, а туториал о том, как написать чат на вебсокетах с группами и прочим.
Из описанных в туториале тем, заинтересовало:
- моделирование данных необходимых для чата;
- описание необходимого набора эндпоинтов;
- настройка messages recovery;
- использование outbox паттерна для публикации сообщений;
- как скейлиться на 100к человек;
- список улучшений и список советов;
Важно отметить, что туториал от разработчиков centirfugo, но идеи и подходы можно использовать с другими технологиями.
#how_it_works #websockets #chat
—————————————
Consistency Patterns
Одной из трех проблем распределенных систем (привет CAP теорема) является консистентность, т.е. данные не противоречат друг другу в один момент времени. Статья выше рассказывает о консистентности, точнее про три вида: strong (когда данные для чтения всегда аналогичны данным последней записи), eventual (когда данные на чтение и запись могут отличаться, но будут одинаковыми в будущем) и weak (когда данные могут быть согласованы, а могут и нет). Для каждого вида указываются плюсы и минусы, а также дается картинка с объяснением подхода. Понравилось, что автор сделал таблицу с трейдоффами подходов. В конце говорится еще о двух подходах: linearizability и causal consistency.
Если ничего не знаете о консистентности - статья хороший энтри гайд в тему.
#consistency
—————————————
arc42 Quality Model
Во время работы с характеристиками возникает вопрос - как получить нужные характеристики для дальнейшего анализа или принятия решений. Можно воспользоваться сторонними концепциями как сделано в курсе по анализу систем (DDD, системной инженерией, логикой и так далее), а можно пойти другим путем.
Так, авторы arc42 (это фреймворк описания архитектуры) решили сделать фреймворк/модель по работе с характеристиками системы. Прикол модели в том, что на сайте можно найти 100+ примеров из требований, которые говорят об определенной характеристики (смотреть секцию «Examples of Quality Requirements»).
В качестве целей инициативы указывают:
- Минимальность и покрытие всех возможных продуктов;
- понятность объяснения характеристик;
- бесплатность, открытость, технологическую независимость и так далее;
#characteristics #quality_attributes
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Horizontal Scaling of a Stateful Server with redis pub/sub
System Design Case Study \#4: How WalkMe Engineering Scaled Their Stateful Service Leveraging Pub-Sub Mechanism
Обе статьи рассказывают опыт компании WalkMe (первая оригинал, вторая пересказ), которая решила разбить монолит на сервисы. В результате эволюции системы появился стейтфулл сервис, который хранит контент файлы в памяти, что было сделано, чтобы уменьшить задержку. Для сравнения говорится, что из s3 файл грузился 2 минуты, а из памяти хватает 20 секунд. При этом, консистентность поддерживается за счет синхронизации между памятью и s3, что создало проблемы с синхронизацией файлов при добавлении нового инстанса.
После этого рассказывается о том, что в качестве решения, сначала выбрали вариант с кешом (aws ElastiCache), а после этого, когда возник вопрос с синхронизацией данных в разных инстансах кеша, было решено использовать реализацию pub-sub подхода поверх редиса, для синхронизации нод в кластере. Т.е. при изменении данных в ноде, апдейт автоматически приходит к остальным. При этом, в оригинальной статье еще описывается, почему не подошла очередь в виде aws SNS.
#system_design #scalability #event_driven
—————————————
5 pitfalls to avoid when implementing an Event-Driven Architecture
Проблема асинхронных коммуникаций сводится к дорогому исправлении ошибок, если что пойдет не так. Это связанно как с потерей данных, которые не восстановить (продьюсера, в отличии от клиента, сложно попросить два раза отправить данные), так и с связанностью и наблюдаемостью системы, которая спроектирована без оглядки на поддерживаемость. Поэтому, дешевле сразу применить некоторые принципы и потратить чуть больше ресурсов пока нет проблем, вместо того, чтобы разгребать ошибки и потратить больше ресурсов в будущем.
О таких принципах пишет автор статьи выше. В тексте найдете пять пунктов:
- Название топиков основанное на бизнес модели, а не на технической реализации (добавлю, что это касается и названий событий);
- Помнить о версионировании и заранее закладывать подходы для будущей эволюции схем событий;
- Выбирать между синхронными и асинхронными коммуникациями;
- Выработать стандарты схемы headers и payload событий. Например с помощью cloudevents;
- Мониторинг всего, что движется;
Чего не хватило: какие виды событий бывают и как с ними работать, как хранить версии схем и как обрабатывать ошибки, если пошло что-то не так. Если проходили АА курс, нового ничего не найдете, но что бы освежить темы в голове – подойдет. Если курс не проходили, но по работе приходится сталкиваться с асинхронными коммуникациями - лучше прочитать.
#event_driven #events
—————————————
Evolution of a high-performance system: from synchronous to seamless scalability
Еще одна статья о том, как улучшали scalability системы. В этот раз система запрашивала travel solutions через внешних поставщиков, потом ответы собирались в кучу и отдавались пользователю. У решения были проблемы с ресурсоемкостью (в статье говорится об обработке 50кк запросов в день), масштабированием и сложностью деплоймента. После этого, систему разбили на 2 части: поиск и работу с поставщиками вынести в отдельные консьюмеры, плюс добавили очередь и редис для хранения результатов. А тексте найдете картинки и подробное описание проблем и плюсов решения.
#scalability #event_driven
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Horizontal Scaling of a Stateful Server with redis pub/sub
System Design Case Study \#4: How WalkMe Engineering Scaled Their Stateful Service Leveraging Pub-Sub Mechanism
Обе статьи рассказывают опыт компании WalkMe (первая оригинал, вторая пересказ), которая решила разбить монолит на сервисы. В результате эволюции системы появился стейтфулл сервис, который хранит контент файлы в памяти, что было сделано, чтобы уменьшить задержку. Для сравнения говорится, что из s3 файл грузился 2 минуты, а из памяти хватает 20 секунд. При этом, консистентность поддерживается за счет синхронизации между памятью и s3, что создало проблемы с синхронизацией файлов при добавлении нового инстанса.
После этого рассказывается о том, что в качестве решения, сначала выбрали вариант с кешом (aws ElastiCache), а после этого, когда возник вопрос с синхронизацией данных в разных инстансах кеша, было решено использовать реализацию pub-sub подхода поверх редиса, для синхронизации нод в кластере. Т.е. при изменении данных в ноде, апдейт автоматически приходит к остальным. При этом, в оригинальной статье еще описывается, почему не подошла очередь в виде aws SNS.
#system_design #scalability #event_driven
—————————————
5 pitfalls to avoid when implementing an Event-Driven Architecture
Проблема асинхронных коммуникаций сводится к дорогому исправлении ошибок, если что пойдет не так. Это связанно как с потерей данных, которые не восстановить (продьюсера, в отличии от клиента, сложно попросить два раза отправить данные), так и с связанностью и наблюдаемостью системы, которая спроектирована без оглядки на поддерживаемость. Поэтому, дешевле сразу применить некоторые принципы и потратить чуть больше ресурсов пока нет проблем, вместо того, чтобы разгребать ошибки и потратить больше ресурсов в будущем.
О таких принципах пишет автор статьи выше. В тексте найдете пять пунктов:
- Название топиков основанное на бизнес модели, а не на технической реализации (добавлю, что это касается и названий событий);
- Помнить о версионировании и заранее закладывать подходы для будущей эволюции схем событий;
- Выбирать между синхронными и асинхронными коммуникациями;
- Выработать стандарты схемы headers и payload событий. Например с помощью cloudevents;
- Мониторинг всего, что движется;
Чего не хватило: какие виды событий бывают и как с ними работать, как хранить версии схем и как обрабатывать ошибки, если пошло что-то не так. Если проходили АА курс, нового ничего не найдете, но что бы освежить темы в голове – подойдет. Если курс не проходили, но по работе приходится сталкиваться с асинхронными коммуникациями - лучше прочитать.
#event_driven #events
—————————————
Evolution of a high-performance system: from synchronous to seamless scalability
Еще одна статья о том, как улучшали scalability системы. В этот раз система запрашивала travel solutions через внешних поставщиков, потом ответы собирались в кучу и отдавались пользователю. У решения были проблемы с ресурсоемкостью (в статье говорится об обработке 50кк запросов в день), масштабированием и сложностью деплоймента. После этого, систему разбили на 2 части: поиск и работу с поставщиками вынести в отдельные консьюмеры, плюс добавили очередь и редис для хранения результатов. А тексте найдете картинки и подробное описание проблем и плюсов решения.
#scalability #event_driven
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Два года пишем RFC — статистика
Редкий гость рассылки – «решил попробовать N и вот что получилось». В этот раз автор решил ввести практику RFC (Request for Change) и после собрал статистику за два года. В начале рассказываются общие ожидания от введения практики и говорится о структуре и подходах, плюс примеры тайтлов. Главное ожидание – введение «мышления письмом» на уровне команды, а также документация и быстрый онбординг. Дальше дается контекст по данным: кто писал, какой размер команды, какие статусы и так далее. После этого дается статистика: актуальность, был ли ресерч или нет, распределение по тематикам, количество комментариев и так далее. В конце даются выводы, меня заинтересовала мысль с использованием rfc/adr как индикатор состояния команды или проекта.
#rfc #docs #management
—————————————
A Crash Course in P2P
Главная идея p2p network – клиенты общаются напрямую между собой, без централизации (почти). Если тоже застали strongdc++, скайп, торренты или работали с блокчейном или гитом с коммитами по почте - это оно.
Сегодня статья интродакшн в p2p. В начале дается краткое объяснение подхода и сравнение с client-server, после чего показывается исторический таймлайн, как технология развивалась. Дальше рассказывается о трех видах реализации: pure (нет централизации), hybrid (когда присутствует централизованный сервер) и blockchain. Дальше объясняются принципы работы сети, начиная от инициализации и получения id ноды, переходя в определение других нод и подключения к сети. После этого говорится о том, как шарятся файлы и происходит роутинг. Потом даются примеры технологий и описываются плюсы и минусы подхода.
Если ничего не знаете о p2p – статья объяснит основну. На всякий случай напишу: в статье есть реклама в начале и в середине, не пугайтесь.
#p2p #distributed_systems
—————————————
Git Tips 1: Oldies but Goodies
Git Tips 2: New Stuff in Git
Git Tips 3: Really Large Repositories
Пользуюсь гитом 13 лет и каждый раз узнаю что-то новое. Сегодня не исключение: один из основателей гитхаба, делает гитовый клиент gitbutler, а к клиенту прилагается блог, где даются советы по работе с гитом, поэтому сегодня 3 статьи по цене одной. Кратко перескажу что в статьях найдете.
Первый пост о мелких советах:
- оказалось, что можно подсовывать специфичный конфиг гита не просто под репозиторий, но и под каждый репозиторий по определенному пути (а также под конкретную ветку в репозитории). Персональный майндблоу;
- пара советов под консольный гит блейм;
- настройка git diff для отображения разницы не по строкам, а по словам;
- сохранение разрешения конфликта для повторного резолва;
Во втором посте рассказывается о:
- сортировке веток по мета информации (дате, размеру, автору и так далее);
- безопасному форс пушу;
- git maintenance команде, оптимизирующей репозиторий и которая упоминалось в канале в статье от гитхаба;
А заключительном посте рассказывается о том, как используя git maintenance упаковывать большие репозитории. Где примером репозитория является исходный код винды на 300 гигов.
Для любителей видео есть запись выступления от автора.
#git #tips
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Два года пишем RFC — статистика
Редкий гость рассылки – «решил попробовать N и вот что получилось». В этот раз автор решил ввести практику RFC (Request for Change) и после собрал статистику за два года. В начале рассказываются общие ожидания от введения практики и говорится о структуре и подходах, плюс примеры тайтлов. Главное ожидание – введение «мышления письмом» на уровне команды, а также документация и быстрый онбординг. Дальше дается контекст по данным: кто писал, какой размер команды, какие статусы и так далее. После этого дается статистика: актуальность, был ли ресерч или нет, распределение по тематикам, количество комментариев и так далее. В конце даются выводы, меня заинтересовала мысль с использованием rfc/adr как индикатор состояния команды или проекта.
#rfc #docs #management
—————————————
A Crash Course in P2P
Главная идея p2p network – клиенты общаются напрямую между собой, без централизации (почти). Если тоже застали strongdc++, скайп, торренты или работали с блокчейном или гитом с коммитами по почте - это оно.
Сегодня статья интродакшн в p2p. В начале дается краткое объяснение подхода и сравнение с client-server, после чего показывается исторический таймлайн, как технология развивалась. Дальше рассказывается о трех видах реализации: pure (нет централизации), hybrid (когда присутствует централизованный сервер) и blockchain. Дальше объясняются принципы работы сети, начиная от инициализации и получения id ноды, переходя в определение других нод и подключения к сети. После этого говорится о том, как шарятся файлы и происходит роутинг. Потом даются примеры технологий и описываются плюсы и минусы подхода.
Если ничего не знаете о p2p – статья объяснит основну. На всякий случай напишу: в статье есть реклама в начале и в середине, не пугайтесь.
#p2p #distributed_systems
—————————————
Git Tips 1: Oldies but Goodies
Git Tips 2: New Stuff in Git
Git Tips 3: Really Large Repositories
Пользуюсь гитом 13 лет и каждый раз узнаю что-то новое. Сегодня не исключение: один из основателей гитхаба, делает гитовый клиент gitbutler, а к клиенту прилагается блог, где даются советы по работе с гитом, поэтому сегодня 3 статьи по цене одной. Кратко перескажу что в статьях найдете.
Первый пост о мелких советах:
- оказалось, что можно подсовывать специфичный конфиг гита не просто под репозиторий, но и под каждый репозиторий по определенному пути (а также под конкретную ветку в репозитории). Персональный майндблоу;
- пара советов под консольный гит блейм;
- настройка git diff для отображения разницы не по строкам, а по словам;
- сохранение разрешения конфликта для повторного резолва;
Во втором посте рассказывается о:
- сортировке веток по мета информации (дате, размеру, автору и так далее);
- безопасному форс пушу;
- git maintenance команде, оптимизирующей репозиторий и которая упоминалось в канале в статье от гитхаба;
А заключительном посте рассказывается о том, как используя git maintenance упаковывать большие репозитории. Где примером репозитория является исходный код винды на 300 гигов.
Для любителей видео есть запись выступления от автора.
#git #tips
Пятничное чтиво
Спец выпуск: три статьи об опыте компаний в решении технических проблем. Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Breaking the Monolith at Twitch: Part 1
Серия статей о микросервисах, которые «спасли» компанию.
В первой части описывается предыстория: начали с рельсового монолит, который уже было сложно поддерживать, возникали сложности при поддержки и проблемы с перфомансом. При этом, проблемы с перфомансом заставили компанию смотреть на другие технологии. Что привело к первому pubsub сервису на го для чата.
Во второй части (ссылка в первой части) рассказывается о переезде. Так, после успеха с сервисом на го, компания решила монолит переписать на микросервисы. При этом, вскользь, говорят, что хотели переписать спагети код в контроллерах. А первое что сделали с инфраструктурной точки зрения – reverse proxy на nginx для разделения трафика. После рассказывается как микросервисы помогли с орг структурой компании при росте. В конце второй части найдете интересный подход с тем, как избавлялись от частей, которые до конца не перенесли и уже не знали что с этим делать – компания выключала эндпоинты и смотрела что произойдет. Если не жаловались – код выкладывался. К сожалению не хватило конкретики, способов определения сервисов и больше деталей в статье.
#monolith_decomposition
—————————————
Slack’s Migration to a Cellular Architecture
В августе 2021 года в канале упоминалась Cell-Based Architecture (по ссылке найдете описание структуры, плюсы минусы и референс архитектуру). Прошло 3 года, а я так и не углубился в тему. Зато slack успела переехать на подобную структуру, о чем и написала пост у себя в блоге.
Все началось с инцидента, при котором вышло оборудование в одном из регионов, что повлияло на пользователей. В результате анализа выяснили, что часть общей инфры находится в одном aws регионе. Поэтому, компания решила устранить эту проблему, а cell-based подход помог, из-за следующих требований:
- переводу всего трафика из «упавшего» региона в другой
- пользователь не должен замечать проблемы при подобном перегоне трафика
- хотели управляемый перегон трафика (в статье говорят о 1% трафика для проверок)
Ну а дальше, в общих словах, рассказывается о том, как менялась система под требования (в инфраструктурном плане) и при чем тут Envoy.
#cell_based_Architecture
—————————————
Rebuilding Netflix Video Processing Pipeline
The Netflix Cosmos Platform
В первой статье, рассказывается о том, компания пять лет переезжала на новый пайплайн для видео процессинга. Для этого использовалась платформа Cosmos (вторая статья). Где каждый «юнит» платформы состоит из трех частей: api, воркфлоу энджина и serverless обработки. А дальше «юниты» скейлятся под нужную нагрузку. Например, в тексте говорится о делении видео на 31 чанк, который параллельно обрабатывается. При этом, воркфлоу не только паралелит обработку, но и собирает видео после. А сама обработка видео состоит не только из энкодинга в нужный формат, разрешие и качество, но и генерации субтитров.
Возвращаясь к переезду на новую платформу. В начале текста описывается, что изменилось в обработке видео с 2007 года: переход на 4к и HDR, переход на chunk-based encoding, переезд на новую инфраструктуру, куча сделанной оптимизации и так далее. После этого рассказывается о старом решении (с 2014 года): монолитном приложении, которое удовлетворяло потребностям бизнеса, но имело недостатки (релизный цикл и каплинг). После чего, требования поменялись и в 2018 компания начала переезд на cosmos. В конце рассказывается из каких сервисов состоит теперь обработка видео, как происходит оркестрация и в каком состоянии проект на сегодня.
#video_processing #system_evolution
Спец выпуск: три статьи об опыте компаний в решении технических проблем. Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму (для обратной связи оставьте, пожалуйста, контакт).
—————————————
Breaking the Monolith at Twitch: Part 1
Серия статей о микросервисах, которые «спасли» компанию.
В первой части описывается предыстория: начали с рельсового монолит, который уже было сложно поддерживать, возникали сложности при поддержки и проблемы с перфомансом. При этом, проблемы с перфомансом заставили компанию смотреть на другие технологии. Что привело к первому pubsub сервису на го для чата.
Во второй части (ссылка в первой части) рассказывается о переезде. Так, после успеха с сервисом на го, компания решила монолит переписать на микросервисы. При этом, вскользь, говорят, что хотели переписать спагети код в контроллерах. А первое что сделали с инфраструктурной точки зрения – reverse proxy на nginx для разделения трафика. После рассказывается как микросервисы помогли с орг структурой компании при росте. В конце второй части найдете интересный подход с тем, как избавлялись от частей, которые до конца не перенесли и уже не знали что с этим делать – компания выключала эндпоинты и смотрела что произойдет. Если не жаловались – код выкладывался. К сожалению не хватило конкретики, способов определения сервисов и больше деталей в статье.
#monolith_decomposition
—————————————
Slack’s Migration to a Cellular Architecture
В августе 2021 года в канале упоминалась Cell-Based Architecture (по ссылке найдете описание структуры, плюсы минусы и референс архитектуру). Прошло 3 года, а я так и не углубился в тему. Зато slack успела переехать на подобную структуру, о чем и написала пост у себя в блоге.
Все началось с инцидента, при котором вышло оборудование в одном из регионов, что повлияло на пользователей. В результате анализа выяснили, что часть общей инфры находится в одном aws регионе. Поэтому, компания решила устранить эту проблему, а cell-based подход помог, из-за следующих требований:
- переводу всего трафика из «упавшего» региона в другой
- пользователь не должен замечать проблемы при подобном перегоне трафика
- хотели управляемый перегон трафика (в статье говорят о 1% трафика для проверок)
Ну а дальше, в общих словах, рассказывается о том, как менялась система под требования (в инфраструктурном плане) и при чем тут Envoy.
#cell_based_Architecture
—————————————
Rebuilding Netflix Video Processing Pipeline
The Netflix Cosmos Platform
В первой статье, рассказывается о том, компания пять лет переезжала на новый пайплайн для видео процессинга. Для этого использовалась платформа Cosmos (вторая статья). Где каждый «юнит» платформы состоит из трех частей: api, воркфлоу энджина и serverless обработки. А дальше «юниты» скейлятся под нужную нагрузку. Например, в тексте говорится о делении видео на 31 чанк, который параллельно обрабатывается. При этом, воркфлоу не только паралелит обработку, но и собирает видео после. А сама обработка видео состоит не только из энкодинга в нужный формат, разрешие и качество, но и генерации субтитров.
Возвращаясь к переезду на новую платформу. В начале текста описывается, что изменилось в обработке видео с 2007 года: переход на 4к и HDR, переход на chunk-based encoding, переезд на новую инфраструктуру, куча сделанной оптимизации и так далее. После этого рассказывается о старом решении (с 2014 года): монолитном приложении, которое удовлетворяло потребностям бизнеса, но имело недостатки (релизный цикл и каплинг). После чего, требования поменялись и в 2018 компания начала переезд на cosmos. В конце рассказывается из каких сервисов состоит теперь обработка видео, как происходит оркестрация и в каком состоянии проект на сегодня.
#video_processing #system_evolution
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Plan for tradeoffs: You can’t optimize all software quality attributes
На практике, при принятии тех решений, видел две крайности : «сначала делаем, а потом решаем, подошла система по свойствам бизнесу или нет» и «определяем свойства, потом принимаем лучшее из возможных решений, для достижения свойств». Первая крайность «дефолтна», а ко второй приходится приходить через опыт, обучение и ошибки (попытка улучшить ситуацию как раз привела к появлению курса).
В статье, автор объясняет важность принятия решений на основе характеристик. Так, в начале, описываются характеристики на которые стоит обратить внимание. После этого говорится о том, как определять ключевые характеристики (спойлер - наймите БА, но также даются референсы на книги, которые помогут в описании характеристик). А после, начинается главная идея статьи – выбор тех решений на основе вопроса «поможет решение в достижении важных характеристик или нет». Здорово, что автор описал примеры конфликтов, когда одно решение влияет на разные характеристики.
Из минусов текста – тут только описание идеи, если захотите углубленных знаний, придется читать референсы. А в качестве «ДЗ»: в следующий раз, когда будете выбирать какой фреймворк/язык/паттерн выбрать – попробуйте определить как каждый из вариантов решений будет влиять на общие характеристики системы.
Русский перевод
#architecture_characteristics #decision_making
—————————————
Using Git offline
Хоть гит и децентрализованная система контроля версий, сложно с ходу представить работу с гитом без центрального сервера (гитхаба, гитлаба, гитеи, етц). Хотя для коммита в linux kernel все еще нужно использовать почту.
Сегодняшняя статья идет дальше и рассказывает о трех вариантах использования гита без централизованного сервера:
- как, используя флешку, сделать remote repository, работа с которым не отличается от работы с гитхабом;
- использование дисков с git bundle, что позволяет клонировать или фетчить репозиторий;
- создание remote repository для локальной сети, когда компьютер становится «сервером», благодаря чему, другие клиенты могут пуллить обновления;
Понятно, что подобный git workflow экзотика (кроме особых случаев), но в качестве расширения кругозора статью стоит посмотреть.
#git
—————————————
Goodbye databases, it’s time to embrace Vector Databases!
Все больше и больше слежу за векторными базами. Это бд, которые позволяют хранить и работать с векторами (структура содержащая «смысл» записи в виде набора характеристик) и на основе чего можно делать семантический или контекстуальный поиск (вместо совпадений).
Сегодняшний текст можно характеризовать как «vector db 101». В начале рассказывается о vector embeddings - массивах чисел, описывающие семантическое значение объектов. После этого говорится о векторном поиске и методе ближайших соседей. Потом рассказывается как работают векторные БД: из чего состоят и описывается флоу работы с данными. После даются примеры баз с краткой информацией о каждой. В самом конце описываются примеры использования: обработка языка, системы рекомендаций, анализ фин данных, работа с аномалиями, мед данными и так далее.
Русский перевод
#db #vector_db
——— одной строкой ———
- Случайно узнал, что в 2k24 люди не слышали (или не помнят) о VimGolf – лучшем учебнике по редактору. Смысл в редактировании текста за наименьшее количество нажатий клавиш.
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Plan for tradeoffs: You can’t optimize all software quality attributes
На практике, при принятии тех решений, видел две крайности : «сначала делаем, а потом решаем, подошла система по свойствам бизнесу или нет» и «определяем свойства, потом принимаем лучшее из возможных решений, для достижения свойств». Первая крайность «дефолтна», а ко второй приходится приходить через опыт, обучение и ошибки (попытка улучшить ситуацию как раз привела к появлению курса).
В статье, автор объясняет важность принятия решений на основе характеристик. Так, в начале, описываются характеристики на которые стоит обратить внимание. После этого говорится о том, как определять ключевые характеристики (спойлер - наймите БА, но также даются референсы на книги, которые помогут в описании характеристик). А после, начинается главная идея статьи – выбор тех решений на основе вопроса «поможет решение в достижении важных характеристик или нет». Здорово, что автор описал примеры конфликтов, когда одно решение влияет на разные характеристики.
Из минусов текста – тут только описание идеи, если захотите углубленных знаний, придется читать референсы. А в качестве «ДЗ»: в следующий раз, когда будете выбирать какой фреймворк/язык/паттерн выбрать – попробуйте определить как каждый из вариантов решений будет влиять на общие характеристики системы.
Русский перевод
#architecture_characteristics #decision_making
—————————————
Using Git offline
Хоть гит и децентрализованная система контроля версий, сложно с ходу представить работу с гитом без центрального сервера (гитхаба, гитлаба, гитеи, етц). Хотя для коммита в linux kernel все еще нужно использовать почту.
Сегодняшняя статья идет дальше и рассказывает о трех вариантах использования гита без централизованного сервера:
- как, используя флешку, сделать remote repository, работа с которым не отличается от работы с гитхабом;
- использование дисков с git bundle, что позволяет клонировать или фетчить репозиторий;
- создание remote repository для локальной сети, когда компьютер становится «сервером», благодаря чему, другие клиенты могут пуллить обновления;
Понятно, что подобный git workflow экзотика (кроме особых случаев), но в качестве расширения кругозора статью стоит посмотреть.
#git
—————————————
Goodbye databases, it’s time to embrace Vector Databases!
Все больше и больше слежу за векторными базами. Это бд, которые позволяют хранить и работать с векторами (структура содержащая «смысл» записи в виде набора характеристик) и на основе чего можно делать семантический или контекстуальный поиск (вместо совпадений).
Сегодняшний текст можно характеризовать как «vector db 101». В начале рассказывается о vector embeddings - массивах чисел, описывающие семантическое значение объектов. После этого говорится о векторном поиске и методе ближайших соседей. Потом рассказывается как работают векторные БД: из чего состоят и описывается флоу работы с данными. После даются примеры баз с краткой информацией о каждой. В самом конце описываются примеры использования: обработка языка, системы рекомендаций, анализ фин данных, работа с аномалиями, мед данными и так далее.
Русский перевод
#db #vector_db
——— одной строкой ———
- Случайно узнал, что в 2k24 люди не слышали (или не помнят) о VimGolf – лучшем учебнике по редактору. Смысл в редактировании текста за наименьшее количество нажатий клавиш.
Пятничное чтиво
Хорошие знакомые попросили рассказать о своем выездном лагере для рубистов/питонистов. Также буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Rethinking Temporal data Modeling: Abandoning the “to” and “from” Column Approach
Если платили за парковку, которая в будни стоит 5 у.е., в выходные 10 у.е., а летом цена отличается от зимней в два раза - то поздравляю, вы сталкивались с temporal data. Первое, что может прийти в голову, если реализовывать подобную логику в коде - добавить колонки
Текст начинается с объяснения разницы между valid time и transaction time: valid time говорит о промежутке, когда запись валидна в реальности, а transaction говорит о времени, когда запись появилась в бд (тут понравился референс на event sourcing, который больше о transaction time). После чего объясняется, почему хранить интервал/период лучше как один тип, вместо двух колонок (атомарность, простота запросов/индексирования и так далее). Дальше автор показывает пару примеров с плохим дизайном таблиц, после чего рассказывает об избыточности данных. А в конце показывается, как используя постгрес можно реализовать хранение интервалов и получение необходимых значений.
#temporal_data #data_modelling
—————————————
Implementing an Object Pool (the right way)
Статья из серии: «как написать object pool (connection pool как частный случай) из подручных средств». В начале, автор, рассказывает о object pool паттерне, как работает (хранит пул объектов), для чего нужен (чаще для работы с коннекшенами к базе). После чего рассказывается, как реализуется пул (с кодом похожим на ts): первая версия состоит из самого пула и ресурсов, которые отдаются под запрос (с локом). А во второй версии реализации пула уже скрывается работа с явным получением коннекшенов к бд. В конце даются советы по размеру пула.
#how_it_works #connection_pool
—————————————
A Brief History of Airbnb’s Architecture
Еще одна статья о том, как компания мигрировала с монолита (на рельсе) на набор сервисов. При этом, это выжимка из того, что компания рассказывала в разных постах/подкастах. Изначально airbnb написали на рельсе в виде монолита. Дальше описываются две фазы эволюции (причин переезда я не нашел): сначала компания разделила данные через адаптеры к active record, после чего монолит поделили на уровне бизнес логики. После середины начинаются интересные детали: рассказывается как выносили read и write модели из монолита, даются плюсы и минусы подхода подобного разделения. После рассказывается о некоторых технологиях, используемых в компании: thrift rpc, spinnaker как CI/CD решение и написанный компанией powergrid как оркестратор процессов.
#system_evolution #monolith_decomposition
Хорошие знакомые попросили рассказать о своем выездном лагере для рубистов/питонистов. Также буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Rethinking Temporal data Modeling: Abandoning the “to” and “from” Column Approach
Если платили за парковку, которая в будни стоит 5 у.е., в выходные 10 у.е., а летом цена отличается от зимней в два раза - то поздравляю, вы сталкивались с temporal data. Первое, что может прийти в голову, если реализовывать подобную логику в коде - добавить колонки
from и to, где будет указано две даты: начало и конец условия, но у такого решения есть свои проблемы. Об этом статья выше, где автор описывает как сам реализует в базе подход с хранением временных интервалов.Текст начинается с объяснения разницы между valid time и transaction time: valid time говорит о промежутке, когда запись валидна в реальности, а transaction говорит о времени, когда запись появилась в бд (тут понравился референс на event sourcing, который больше о transaction time). После чего объясняется, почему хранить интервал/период лучше как один тип, вместо двух колонок (атомарность, простота запросов/индексирования и так далее). Дальше автор показывает пару примеров с плохим дизайном таблиц, после чего рассказывает об избыточности данных. А в конце показывается, как используя постгрес можно реализовать хранение интервалов и получение необходимых значений.
#temporal_data #data_modelling
—————————————
Implementing an Object Pool (the right way)
Статья из серии: «как написать object pool (connection pool как частный случай) из подручных средств». В начале, автор, рассказывает о object pool паттерне, как работает (хранит пул объектов), для чего нужен (чаще для работы с коннекшенами к базе). После чего рассказывается, как реализуется пул (с кодом похожим на ts): первая версия состоит из самого пула и ресурсов, которые отдаются под запрос (с локом). А во второй версии реализации пула уже скрывается работа с явным получением коннекшенов к бд. В конце даются советы по размеру пула.
#how_it_works #connection_pool
—————————————
A Brief History of Airbnb’s Architecture
Еще одна статья о том, как компания мигрировала с монолита (на рельсе) на набор сервисов. При этом, это выжимка из того, что компания рассказывала в разных постах/подкастах. Изначально airbnb написали на рельсе в виде монолита. Дальше описываются две фазы эволюции (причин переезда я не нашел): сначала компания разделила данные через адаптеры к active record, после чего монолит поделили на уровне бизнес логики. После середины начинаются интересные детали: рассказывается как выносили read и write модели из монолита, даются плюсы и минусы подхода подобного разделения. После рассказывается о некоторых технологиях, используемых в компании: thrift rpc, spinnaker как CI/CD решение и написанный компанией powergrid как оркестратор процессов.
#system_evolution #monolith_decomposition
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How to measure DevOps success?
Для проверки, что система соответствует требуемым характеристикам можно использовать фитнесс функции, которые могут быть как вызваны явно (triggered), так и основаны на метриках (сontinuous). Если говорить о сontinuous, то первое что в голову приходит – метрики связанные с временем обработки запросов, количеством запросов и ошибок. Но кроме этого, можно также посмотреть о метриках связанных с deployability, TTM и availability.
В статье рассказывается таких метриках, которые называют DORA, придуманных DevOps Research and Assessment team (поэтому DORA). В метрики входят четыре показателя:
Частота деплоев (_Deployment Frequency (DF)_) - как часто происходят успешные релизы;
Время затраченное на изменения (Lead Time for Changes (LT)) - сколько времени пройдет между «коммитом в мастер» и выкаткой в прод;
Коэффициент ошибок (_Change Failure Rate (CFR)_) - количество проблем возникших после релиза;
Время восстановления (Time to Restore Service (TRTS)) - сколько времени требуется на починку сбоя;
Кроме подробного определения и примеров каждого показателя, автор показывает как улучшение DORA метрик влияет на бизнес (уменьшение костов, улучшение ттм, etc). После даются советы, как добавить в проект метрики и какие проблемы могут возникнуть. Единственное, в статье не хватило списка инструментов (хотя бы ссылки на доку gitlab).
#fitness_functions #metrics #devops
—————————————
Geo-Replication
Одним из способов улучшения availability и fault tolerance, для систем работающих в разных регионах, является гео репликация данных. Статья выше – краткое хайлевел введение в тему, где автор рассказывает о том, как кворум помогает с репликацией. После этого расширяет пример на два кластера и реализации кворума в двух регионах. После этого, кратко, рассказывается о синхронном и асинхронном виде репликации (отличии только в том, будет ack вызываться или нет, что влияет на скорость репликации). К сожалению, для каждой базы или брокера придется искать информацию о способах гео репликации. Плюс, в статье не хватило больше деталей, связанных с работой алгоритмов.
#replication #data_managment
—————————————
A Deep Dive into Amazon DynamoDB Architecture
В персональной рабочей деятельности я практически не работал с dynamoDB (тут не понятно, повезло или нет). А все знания о базе можно было сформулировать одной фразой: «nosql с высоким availability и мастер-мастер репликацией», при этом разобраться в работе и свойствах бд хотелось, с чем помогла статья выше.
В начале рассказывается история появления баз данных и как онлайн торговля повлияла на создание проекта. После описываются свойства, которые можно ждать от бд. А дальше рассказывается об архитектуре: как таблицы связаны с items, при чем тут attributes и какие операции над данными доступны. Далее идет блок о репликации (в чем разница между storage и log репликами), партиции и как можно управлять durability и availability средствами бд. В самом конце найдете ссылки референсы. Если хотите разобраться с dynamoDB, но не знаете с чего начать - статья must read.
#dynamoDB #how_it_works
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How to measure DevOps success?
Для проверки, что система соответствует требуемым характеристикам можно использовать фитнесс функции, которые могут быть как вызваны явно (triggered), так и основаны на метриках (сontinuous). Если говорить о сontinuous, то первое что в голову приходит – метрики связанные с временем обработки запросов, количеством запросов и ошибок. Но кроме этого, можно также посмотреть о метриках связанных с deployability, TTM и availability.
В статье рассказывается таких метриках, которые называют DORA, придуманных DevOps Research and Assessment team (поэтому DORA). В метрики входят четыре показателя:
Частота деплоев (_Deployment Frequency (DF)_) - как часто происходят успешные релизы;
Время затраченное на изменения (Lead Time for Changes (LT)) - сколько времени пройдет между «коммитом в мастер» и выкаткой в прод;
Коэффициент ошибок (_Change Failure Rate (CFR)_) - количество проблем возникших после релиза;
Время восстановления (Time to Restore Service (TRTS)) - сколько времени требуется на починку сбоя;
Кроме подробного определения и примеров каждого показателя, автор показывает как улучшение DORA метрик влияет на бизнес (уменьшение костов, улучшение ттм, etc). После даются советы, как добавить в проект метрики и какие проблемы могут возникнуть. Единственное, в статье не хватило списка инструментов (хотя бы ссылки на доку gitlab).
#fitness_functions #metrics #devops
—————————————
Geo-Replication
Одним из способов улучшения availability и fault tolerance, для систем работающих в разных регионах, является гео репликация данных. Статья выше – краткое хайлевел введение в тему, где автор рассказывает о том, как кворум помогает с репликацией. После этого расширяет пример на два кластера и реализации кворума в двух регионах. После этого, кратко, рассказывается о синхронном и асинхронном виде репликации (отличии только в том, будет ack вызываться или нет, что влияет на скорость репликации). К сожалению, для каждой базы или брокера придется искать информацию о способах гео репликации. Плюс, в статье не хватило больше деталей, связанных с работой алгоритмов.
#replication #data_managment
—————————————
A Deep Dive into Amazon DynamoDB Architecture
В персональной рабочей деятельности я практически не работал с dynamoDB (тут не понятно, повезло или нет). А все знания о базе можно было сформулировать одной фразой: «nosql с высоким availability и мастер-мастер репликацией», при этом разобраться в работе и свойствах бд хотелось, с чем помогла статья выше.
В начале рассказывается история появления баз данных и как онлайн торговля повлияла на создание проекта. После описываются свойства, которые можно ждать от бд. А дальше рассказывается об архитектуре: как таблицы связаны с items, при чем тут attributes и какие операции над данными доступны. Далее идет блок о репликации (в чем разница между storage и log репликами), партиции и как можно управлять durability и availability средствами бд. В самом конце найдете ссылки референсы. Если хотите разобраться с dynamoDB, но не знаете с чего начать - статья must read.
#dynamoDB #how_it_works
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
The Hunt for the Missing Data Type
Как главный фанат графов, не мог пройти мимо статьи где автор так же видит по всюду графы. При этом, автор задается вопросом: «если графы повсюду и так помогают в анализе, почему в коде графы редко используются и не добавляются в стандартную библиотеку языков». А с ответом на вопрос, помогли читатели автора (разработчики графовых бд и разработчики библиотек для работы с графами).
Основных причин оказалось три:
- много вариантов дизайна графов
- много вариантов реализации алгоритмов (можно хранить списки ребер, матрицы или списки смежности, структуры с ссылками)
- проблемы с производительностью для разных решений (одни алгоритмы быстрые для больших графов, другие для мелких, одни для вставки, а другие для поиска)
Понравилось, что в конце присутствует секция связанная с языками с графовыми типами. В первой части рассказывается о языках запросов: почему GQL и graphQL разные вещи, в чем разница между GQL и SQL, немного о chpher рассказывается (это язык запросов neo4j). Во второй части рассказывается о языках с поддержкой графов, это graphlib питона и эрланг + swi prolog, кроме этого упоминаются языки в которых все из графов состоит (как s-exp в лиспе): GP 2 и GrapeVine.
Русский перевод
#graph #graphDB
—————————————
Big Picture Event Storming - finding the gaps
Статья о том, как искать проблемы с неконсистентностью big picture es модели. Для этого автор предлагает два решения:
- Explicit walk-through – когда детально рассматривается последовательность событий, для чего доменный эксперт рассказывает последовательную историю основанную на событиях;
- Reverse narrative – подход похож на предыдущий, только история рассказывается с конца и с ответа на вопрос «как мы попали сюда?»;
В конце, автор на примере показывает как исправить ситуацию, когда представление о процессе разошлось с тем, что показала ES модель и как использование reverse narrative помогло решить данную неконсистентность.
#ddd #strategy_ddd #event_storming
—————————————
4 Common Mistakes in Event-Driven Systems
У event-driven коммуникаций есть как плюсы: меньше связанность при «правильном» проектировании, reliability выше, использование реакционной модели, которая на бизнес ложится и так далее (в начале статьи упоминаются некоторые плюсы). При этом, минусов тоже хватает, как связанных со стоимостью, так и со сложностью (включая перестройку мышления разработчиков).
Автор статьи собрал четыре проблемы, которые встречаются в подобных коммуникациях:
- Как гарантировать ordering для событий;
- Что делать с «транзакционностью»;
- Как быть с консистентностью при отправке пачки событий;
- Как быть, если необходимы изменения, ломающие обратную совместимость;
Для некоторых проблем предлагаются решения, так увидите упоминания transactional outbox паттерна, партишены кафки, распределенные транзакции и так далее.
Русский перевод
#eda
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
The Hunt for the Missing Data Type
Как главный фанат графов, не мог пройти мимо статьи где автор так же видит по всюду графы. При этом, автор задается вопросом: «если графы повсюду и так помогают в анализе, почему в коде графы редко используются и не добавляются в стандартную библиотеку языков». А с ответом на вопрос, помогли читатели автора (разработчики графовых бд и разработчики библиотек для работы с графами).
Основных причин оказалось три:
- много вариантов дизайна графов
- много вариантов реализации алгоритмов (можно хранить списки ребер, матрицы или списки смежности, структуры с ссылками)
- проблемы с производительностью для разных решений (одни алгоритмы быстрые для больших графов, другие для мелких, одни для вставки, а другие для поиска)
Понравилось, что в конце присутствует секция связанная с языками с графовыми типами. В первой части рассказывается о языках запросов: почему GQL и graphQL разные вещи, в чем разница между GQL и SQL, немного о chpher рассказывается (это язык запросов neo4j). Во второй части рассказывается о языках с поддержкой графов, это graphlib питона и эрланг + swi prolog, кроме этого упоминаются языки в которых все из графов состоит (как s-exp в лиспе): GP 2 и GrapeVine.
Русский перевод
#graph #graphDB
—————————————
Big Picture Event Storming - finding the gaps
Статья о том, как искать проблемы с неконсистентностью big picture es модели. Для этого автор предлагает два решения:
- Explicit walk-through – когда детально рассматривается последовательность событий, для чего доменный эксперт рассказывает последовательную историю основанную на событиях;
- Reverse narrative – подход похож на предыдущий, только история рассказывается с конца и с ответа на вопрос «как мы попали сюда?»;
В конце, автор на примере показывает как исправить ситуацию, когда представление о процессе разошлось с тем, что показала ES модель и как использование reverse narrative помогло решить данную неконсистентность.
#ddd #strategy_ddd #event_storming
—————————————
4 Common Mistakes in Event-Driven Systems
У event-driven коммуникаций есть как плюсы: меньше связанность при «правильном» проектировании, reliability выше, использование реакционной модели, которая на бизнес ложится и так далее (в начале статьи упоминаются некоторые плюсы). При этом, минусов тоже хватает, как связанных со стоимостью, так и со сложностью (включая перестройку мышления разработчиков).
Автор статьи собрал четыре проблемы, которые встречаются в подобных коммуникациях:
- Как гарантировать ordering для событий;
- Что делать с «транзакционностью»;
- Как быть с консистентностью при отправке пачки событий;
- Как быть, если необходимы изменения, ломающие обратную совместимость;
Для некоторых проблем предлагаются решения, так увидите упоминания transactional outbox паттерна, партишены кафки, распределенные транзакции и так далее.
Русский перевод
#eda
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How Figma's Databases Team Lived to Tell the Scale
Статья за авторством инженеров figma, в которой рассказывается, как потратив 9 месяцев получить горизонтальное шардирование постгреса. Связанно это с х100 ростом с 2020 года и невозможностью использовать aws RDS из-за слишком большого количества IO операций в секунду (IOPS). В тексте рассказывается о целях, вариантах, которые рассматривались (как NoSQL базы, так и тюнинг постгреса). После рассказывается о том, как шардировались данные и почему партицирование не подошло. А в конце описывается подход, который выбрала фигма состоящий из пяти пунктов:
- разделение данных по collocations;
- использование логического шардирования и репликации;
- использование DBProxy query engine;
- работа с предсказанием того, как трафик будет себя вести с таким шардированием;
Дальше каждый пункт подробно описывается в тексте, а после даются выводы и что полезного удалось получить компании от такого решения.
#sharding #psql
—————————————
How Uber Uses Integrated Redis Cache to Serve 40M Reads/Second?
Еще одна статья из серии «в компании X решили проблему Y». На этот раз это убер и кеширование в редисе. История началась с создания распределенной базы Docstore, которая работает поверх MySQL. Но проблемы начались с low-latency чтением из-за чего добавили слой кэширования с редисом, где сначала чтение происходит из редиса, и если записи нет - делается запрос в Docstore. При этом, и у такого подхода возникли проблемы: менедж редис кластера каждой командой, дублирование логики инвалидации кеша, проблемы с репликацией кеша.
В результате этой истории появился CacheFront – внутренняя доработка для Docstore, которая потенциально помогает с low-latency чтением данных, унифицированная для каждой команды разработки и поддерживающая horizontal scalability для caching layer. По ссылке выше подробное описание причин, целей проекта, его высокоуровневой архитектуры. При этом, показывается, как работает чтение, инвалидация данных, скейлинг, шардирование. А в конце указаны выводы и успехи работы.
#cache #redis
—————————————
Журнал проектирования
Статья привлекла идеей создания отдельного места, где будут учитываться заметки во время работы над проектом. В отличии от GTD, в этом журнале указываются не только задачи, но и другие заметки вокруг проекта: предположения, гипотезы, проблемы, идеи, договоренности и так далее. А в отличии от базы знаний – журнал не является вики проекта, служит только для отображения текущих проблем. Т.е. никто не мешает давать ссылку на справочный материал в журнале или делать задачи в таск трекере по заметкам.
Благодаря подходу можно избежать путаницы или пропуска чего-то важного в документах. При этом, журнал не является единственным источником информации по проекту, а служит скорее инбоксом. В статье автор рассказывает какие проблемы решает журналом, какие задачи закрывает журнал (уменьшить когнитивную нагрузку, придать логическую структуру ходу проектирования, получить строгое движение от проблем к решениям). После указывает этапы работы с журналом и какие категории использует (никто не мешает свои добавить).
Как я понимаю, автор использует подход для UI/UX задач, но никто не мешает использовать аналогичный подход для работы над архитектурой, кодом или другими задачами. А если используете что-то похожее – будет здорово если в комментариях поделитесь своим опытом.
#проектирование
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How Figma's Databases Team Lived to Tell the Scale
Статья за авторством инженеров figma, в которой рассказывается, как потратив 9 месяцев получить горизонтальное шардирование постгреса. Связанно это с х100 ростом с 2020 года и невозможностью использовать aws RDS из-за слишком большого количества IO операций в секунду (IOPS). В тексте рассказывается о целях, вариантах, которые рассматривались (как NoSQL базы, так и тюнинг постгреса). После рассказывается о том, как шардировались данные и почему партицирование не подошло. А в конце описывается подход, который выбрала фигма состоящий из пяти пунктов:
- разделение данных по collocations;
- использование логического шардирования и репликации;
- использование DBProxy query engine;
- работа с предсказанием того, как трафик будет себя вести с таким шардированием;
Дальше каждый пункт подробно описывается в тексте, а после даются выводы и что полезного удалось получить компании от такого решения.
#sharding #psql
—————————————
How Uber Uses Integrated Redis Cache to Serve 40M Reads/Second?
Еще одна статья из серии «в компании X решили проблему Y». На этот раз это убер и кеширование в редисе. История началась с создания распределенной базы Docstore, которая работает поверх MySQL. Но проблемы начались с low-latency чтением из-за чего добавили слой кэширования с редисом, где сначала чтение происходит из редиса, и если записи нет - делается запрос в Docstore. При этом, и у такого подхода возникли проблемы: менедж редис кластера каждой командой, дублирование логики инвалидации кеша, проблемы с репликацией кеша.
В результате этой истории появился CacheFront – внутренняя доработка для Docstore, которая потенциально помогает с low-latency чтением данных, унифицированная для каждой команды разработки и поддерживающая horizontal scalability для caching layer. По ссылке выше подробное описание причин, целей проекта, его высокоуровневой архитектуры. При этом, показывается, как работает чтение, инвалидация данных, скейлинг, шардирование. А в конце указаны выводы и успехи работы.
#cache #redis
—————————————
Журнал проектирования
Статья привлекла идеей создания отдельного места, где будут учитываться заметки во время работы над проектом. В отличии от GTD, в этом журнале указываются не только задачи, но и другие заметки вокруг проекта: предположения, гипотезы, проблемы, идеи, договоренности и так далее. А в отличии от базы знаний – журнал не является вики проекта, служит только для отображения текущих проблем. Т.е. никто не мешает давать ссылку на справочный материал в журнале или делать задачи в таск трекере по заметкам.
Благодаря подходу можно избежать путаницы или пропуска чего-то важного в документах. При этом, журнал не является единственным источником информации по проекту, а служит скорее инбоксом. В статье автор рассказывает какие проблемы решает журналом, какие задачи закрывает журнал (уменьшить когнитивную нагрузку, придать логическую структуру ходу проектирования, получить строгое движение от проблем к решениям). После указывает этапы работы с журналом и какие категории использует (никто не мешает свои добавить).
Как я понимаю, автор использует подход для UI/UX задач, но никто не мешает использовать аналогичный подход для работы над архитектурой, кодом или другими задачами. А если используете что-то похожее – будет здорово если в комментариях поделитесь своим опытом.
#проектирование
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Consuming a Kafka Topic Is Easy, Isn’t It?
Статья рассказывает о двух проблемах которые могут возникнуть при использовании кафки: error handling и consumer lag. Стоит сразу написать, что текст будет полезен только если до этого с кафкой не работали и не знаете как работают офсеты в распределенных логах.
Для объяснения проблем с обработкой ошибок, автор берет код get started tutorial от Confluent, после чего воспроизводит ошибку на стороне консьюмера в коде. Из-за этого офсет у консьюмер группы не двигается, что приводит к тому, что события дальше не обрабатываются после перезагрузки консьюмера. После чего, рассказывается о том, как работают консьюмеры, при чем тут офсеты и какие конфиги кафки влияют на работу с офсетами.
В качестве решения проблемы, автор предлагает три варианта:
- логирование ошибки с последующим «выкидыванием» сообщения;
- dead letter queue topic;
- retry topic and retry consumer;
После, следуют рассуждения о том, что произойдет, если самостоятельно обновлять офсет для консьюмер группы. В конце рассматриваются потенциальные проблемы связанные с долгой обработкой запросов в консьюмере.
#kafka
—————————————
Distributed business transaction performance tuning
Потенциальная проблема распределенных транзакций – не понятно как проверить, что воркфлоу ок в плане перфоманса и где кроется проблема. Поэтому сегодняшняя статья показывает ход рассуждений во время нагрузочного тестирования воркфлоу энджина.
Для этого сделали пример с воркфлоу энджином и тремя сервисами. На этом примере провели нагрузочное тестирование, в результате которого выяснилось, что система упала. Дальше статья идет по пути «правим - падает - правим опять». Но по ходу текста раскрываются причины отказов, такие как:
- проблемы с нехваткой памяти для кеша
- недостаточная параллельная обработка событий
- проблемы с локами и таймаутами
- проблемы с CPU
Так как статья от майкрософт, то стоит ждать специфики по технологиям, но для понимания как проводить подобный вид тестирования и на что смотреть – пойдет.
#distributed_transactions
—————————————
Remote EventStorming
Изначально event storming придумывался как ирл воркшоп, при котором люди «запираются» в комнате и описывают доменную модель используя стикеры, стены и пишущие принадлежности. Во времена ковида собирать людей в одной комнате стало сложно, поэтому появилась статья от автора ES.
В тексте сравнивается проведение ES локально и удаленно для трех вариантов воркшопа: Big Picture, Process Modelling и Software Design. В итоге Альберто приходит к выводу что big picture не сработает удаленно, а process modelling и software design потенциально могут быть выполнены, но без дисциплины и контроля обсуждения – получите проблемы.
Из интересного – понравилась «карта» для big picture, которая показывает что можно получить от воркшопа, включая язык тела и прочие вещи, о которых не думаешь в первую очередь.
#event_storming #system_modelling
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Consuming a Kafka Topic Is Easy, Isn’t It?
Статья рассказывает о двух проблемах которые могут возникнуть при использовании кафки: error handling и consumer lag. Стоит сразу написать, что текст будет полезен только если до этого с кафкой не работали и не знаете как работают офсеты в распределенных логах.
Для объяснения проблем с обработкой ошибок, автор берет код get started tutorial от Confluent, после чего воспроизводит ошибку на стороне консьюмера в коде. Из-за этого офсет у консьюмер группы не двигается, что приводит к тому, что события дальше не обрабатываются после перезагрузки консьюмера. После чего, рассказывается о том, как работают консьюмеры, при чем тут офсеты и какие конфиги кафки влияют на работу с офсетами.
В качестве решения проблемы, автор предлагает три варианта:
- логирование ошибки с последующим «выкидыванием» сообщения;
- dead letter queue topic;
- retry topic and retry consumer;
После, следуют рассуждения о том, что произойдет, если самостоятельно обновлять офсет для консьюмер группы. В конце рассматриваются потенциальные проблемы связанные с долгой обработкой запросов в консьюмере.
#kafka
—————————————
Distributed business transaction performance tuning
Потенциальная проблема распределенных транзакций – не понятно как проверить, что воркфлоу ок в плане перфоманса и где кроется проблема. Поэтому сегодняшняя статья показывает ход рассуждений во время нагрузочного тестирования воркфлоу энджина.
Для этого сделали пример с воркфлоу энджином и тремя сервисами. На этом примере провели нагрузочное тестирование, в результате которого выяснилось, что система упала. Дальше статья идет по пути «правим - падает - правим опять». Но по ходу текста раскрываются причины отказов, такие как:
- проблемы с нехваткой памяти для кеша
- недостаточная параллельная обработка событий
- проблемы с локами и таймаутами
- проблемы с CPU
Так как статья от майкрософт, то стоит ждать специфики по технологиям, но для понимания как проводить подобный вид тестирования и на что смотреть – пойдет.
#distributed_transactions
—————————————
Remote EventStorming
Изначально event storming придумывался как ирл воркшоп, при котором люди «запираются» в комнате и описывают доменную модель используя стикеры, стены и пишущие принадлежности. Во времена ковида собирать людей в одной комнате стало сложно, поэтому появилась статья от автора ES.
В тексте сравнивается проведение ES локально и удаленно для трех вариантов воркшопа: Big Picture, Process Modelling и Software Design. В итоге Альберто приходит к выводу что big picture не сработает удаленно, а process modelling и software design потенциально могут быть выполнены, но без дисциплины и контроля обсуждения – получите проблемы.
Из интересного – понравилась «карта» для big picture, которая показывает что можно получить от воркшопа, включая язык тела и прочие вещи, о которых не думаешь в первую очередь.
#event_storming #system_modelling
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Exploring Advanced Error Handling Patterns with Event-Driven Architecture
Еще одна статья об обработках ошибок в event-driven системах/коммуникациях. Понравилось, что автор начинает текст с объяснения где может возникнуть ошибка (на стороне продьюсера, брокера и консьюмера). После чего говорит о transience ошибках – ситуациях, когда событие не валидно в текущий момент времени, но будет валидно спустя время. После чего рассуждает, как можно исправить ситуацию с transience ошибками, либо с ожиданием и асинхронной request-response коммуникацией, либо реализацией компенсаторного события из саг. После чего приходит к DLQ (dead letter queue), в которых событие с ошибкой отправляется в очередь, в которой события обрабатываются потом.
При этом, использование DQL также может привести к проблемам, например когда события добавляются в очередь быстрее, чем разбираются из нее. Для этого рассматривается два подхода expiration www.tg-me.com/retry count для событий: когда событие спустя время или количество повторений удаляется из очереди, либо руками обрабатывается. Понравилось, что в конце автор призывает помнить о trade-off каждого из решений.
#eda #error_handling
—————————————
Visual Guide to NoSQL Systems
Старая статья из 2010 года которая сводится к одной картинке. Идя в том, что берется CAP треугольник (это который о CAP теореме), после, для каждой грани (CA-AP-CP), приводятся примеры баз данных, которые соответствуют каждой из граней. базы, которые будут соответствуют. Из баз используются четыре вида: relational, k-v, column, document. Дальше идет список баз данных с ссылками на каждую. Важно учитывать, что за 14 лет, часть информации устарела и поменялись базы. Если нашли ошибку - пишите в комментариях.
#cap #db
—————————————
Reddit's Architecture: The Evolutionary Journey
Еще одна статья на тему того, как технически развивалась компания. Сегодня это путь reddit от проекта на лиспе к распределенной системе с graphQL, CDC, кафкой и gRPC.
Начинается текст с использования лиспа, который заменили на монолит на питоне в 2005-2009 годах, где для баз использовался постгрес и в некоторых местах кассандра (тут вопросы к тексту, ибо по датам не сходится). После этого началась expansion фаза, в которой добавили graphQL федерацию (хотели от монолита уйти, канкаренси улучшить и separation of concerns добавить) и сервисы на го. В статье найдете как происходила миграция и описывается вариант blue/green деплоймента для федерации. Кроме этого добавили CDC для репликации данных, при этом, изначально репликация работала через копию WAL файла в s3 и ежедневным обновлением.
Дальше рассказывается как реддит работает медиа файлами и как происходит оптимизация картинок. Последние две бизнесовые темы из статьи – модерация под нагрузкой (условно бан по словам) и реализация фидов. Для модерации сделали сервис который назвали REV(1/2), написанный на lua. А для фидов сделали server-driven feeds платформа. А в самом конце описаны причины переезда с thrift на grpc и список используемых материалов для статьи.
#system_evolution #monolith_decomposition
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Exploring Advanced Error Handling Patterns with Event-Driven Architecture
Еще одна статья об обработках ошибок в event-driven системах/коммуникациях. Понравилось, что автор начинает текст с объяснения где может возникнуть ошибка (на стороне продьюсера, брокера и консьюмера). После чего говорит о transience ошибках – ситуациях, когда событие не валидно в текущий момент времени, но будет валидно спустя время. После чего рассуждает, как можно исправить ситуацию с transience ошибками, либо с ожиданием и асинхронной request-response коммуникацией, либо реализацией компенсаторного события из саг. После чего приходит к DLQ (dead letter queue), в которых событие с ошибкой отправляется в очередь, в которой события обрабатываются потом.
При этом, использование DQL также может привести к проблемам, например когда события добавляются в очередь быстрее, чем разбираются из нее. Для этого рассматривается два подхода expiration www.tg-me.com/retry count для событий: когда событие спустя время или количество повторений удаляется из очереди, либо руками обрабатывается. Понравилось, что в конце автор призывает помнить о trade-off каждого из решений.
#eda #error_handling
—————————————
Visual Guide to NoSQL Systems
Старая статья из 2010 года которая сводится к одной картинке. Идя в том, что берется CAP треугольник (это который о CAP теореме), после, для каждой грани (CA-AP-CP), приводятся примеры баз данных, которые соответствуют каждой из граней. базы, которые будут соответствуют. Из баз используются четыре вида: relational, k-v, column, document. Дальше идет список баз данных с ссылками на каждую. Важно учитывать, что за 14 лет, часть информации устарела и поменялись базы. Если нашли ошибку - пишите в комментариях.
#cap #db
—————————————
Reddit's Architecture: The Evolutionary Journey
Еще одна статья на тему того, как технически развивалась компания. Сегодня это путь reddit от проекта на лиспе к распределенной системе с graphQL, CDC, кафкой и gRPC.
Начинается текст с использования лиспа, который заменили на монолит на питоне в 2005-2009 годах, где для баз использовался постгрес и в некоторых местах кассандра (тут вопросы к тексту, ибо по датам не сходится). После этого началась expansion фаза, в которой добавили graphQL федерацию (хотели от монолита уйти, канкаренси улучшить и separation of concerns добавить) и сервисы на го. В статье найдете как происходила миграция и описывается вариант blue/green деплоймента для федерации. Кроме этого добавили CDC для репликации данных, при этом, изначально репликация работала через копию WAL файла в s3 и ежедневным обновлением.
Дальше рассказывается как реддит работает медиа файлами и как происходит оптимизация картинок. Последние две бизнесовые темы из статьи – модерация под нагрузкой (условно бан по словам) и реализация фидов. Для модерации сделали сервис который назвали REV(1/2), написанный на lua. А для фидов сделали server-driven feeds платформа. А в самом конце описаны причины переезда с thrift на grpc и список используемых материалов для статьи.
#system_evolution #monolith_decomposition
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How PayPal Serves 350 Billion Daily Requests with JunoDB
Очередная статья о том, как компания решает проблемы. На этот раз это платежный сервис PayPal сделал базу для кеша, идемпотентности, хранения counter для rate limits и других юзкейсов. База называется JunoDB – это key-value хранилище. Прикол базы в том, что решение помогает добиться 6 девяток SLA (это 99.9999% аптайма или 86.40 миллисекунд даунтайма в сутки). А в отличии от single-threaded редиса, JunoDB работает с несколькими ядрами и поддерживает high concurrency.
В тексте найдете описание причин появления базы данных, описание архитектуры (там три части: клиенты, прокси с load balancer и storage сервера). После описываются характеристики базы: scalability (и за счет чего достигается), availability (и способы репликации данных), перфоманс и секьюрити. В конце традиционно ссылки на статьи, на основе которых был написан текст и которые для дальнейшего чтения можно использовать.
#db
—————————————
Refactor like a PRO
Короткая статья с семью советами связанными с рефакторингом кода. В тексте найдете следующие советы:
- итерационный рефакторинг малых частей;
- использование возможностей IDE;
- использование мутационного тестирования;
- использование комментарий для сохранения контекста, а не описания алгоритма;
- использование DRY принципа подумав два раза (не всегда одинаковый код == один и тот же код);
- не менять поведение во время рефакторинга (на этом сам обжегся пару раз);
- в конце привязывается идея постоянного рефакторинга из TDD, т.е. вместо отдельного действия, это должно быть рутиной;
Из минусов, жаль не рассказывается, как производить рефакторинг глобальных вещей, которые затрагивают систему целиком (ну или хотя бы советы об этом).
#refactoring #tips_and_trics
—————————————
How does Sidekiq work?
Для тех, кто не в курсе (и не писал на руби): sidekiq - бэкграунд процессинг для руби, который поднимается как отдельный сервер и асинхронно выполняет код на руби. При этом, из коробки реализованы ретраи, можно делать плагины и реализован graceful shutdown. Под капотом использует редис и решает проблему с канкаренси и многопоточностью в руби приложениях. Ближайший аналог - celery из питона, который работает поверх кролика, а не редиса. Много лет назад я помогал Майку (автору) делать sidekiq и могу сказать, что Майк шарит как делать подобные системы. Ну и благодаря этой работе я смог лучше разобраться в асинхронщине в коде и полюбил редис не только как бд для кеша.
Статья выше (точнее кросспост) – это описание того как работает sidekiq. Из нее узнаете, как работает main loop который запускает задачи, как происходит обработка сигналов, как останавливается сервер, как происходит работа с очередями из редиса, работают ретраи, обрабатываются ошибки и прочее.
Забейте, что тут о руби и редисе, причина, почему статья оказалась в рассылки не в этом. Данный текст будет полезен кому угодно, кто захочет писать бэкграунд процессинг потому, не важно на каком языке и что используя для персистенса. Связанно это с тем, что в тексте описываются общие подходы и принципы написания асинхронных обработчиков. Т.е. взяв идеи из существующей библиотеки, будет проще написать свою реализацию на том же go.
#how_it_works #async_communications
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
How PayPal Serves 350 Billion Daily Requests with JunoDB
Очередная статья о том, как компания решает проблемы. На этот раз это платежный сервис PayPal сделал базу для кеша, идемпотентности, хранения counter для rate limits и других юзкейсов. База называется JunoDB – это key-value хранилище. Прикол базы в том, что решение помогает добиться 6 девяток SLA (это 99.9999% аптайма или 86.40 миллисекунд даунтайма в сутки). А в отличии от single-threaded редиса, JunoDB работает с несколькими ядрами и поддерживает high concurrency.
В тексте найдете описание причин появления базы данных, описание архитектуры (там три части: клиенты, прокси с load balancer и storage сервера). После описываются характеристики базы: scalability (и за счет чего достигается), availability (и способы репликации данных), перфоманс и секьюрити. В конце традиционно ссылки на статьи, на основе которых был написан текст и которые для дальнейшего чтения можно использовать.
#db
—————————————
Refactor like a PRO
Короткая статья с семью советами связанными с рефакторингом кода. В тексте найдете следующие советы:
- итерационный рефакторинг малых частей;
- использование возможностей IDE;
- использование мутационного тестирования;
- использование комментарий для сохранения контекста, а не описания алгоритма;
- использование DRY принципа подумав два раза (не всегда одинаковый код == один и тот же код);
- не менять поведение во время рефакторинга (на этом сам обжегся пару раз);
- в конце привязывается идея постоянного рефакторинга из TDD, т.е. вместо отдельного действия, это должно быть рутиной;
Из минусов, жаль не рассказывается, как производить рефакторинг глобальных вещей, которые затрагивают систему целиком (ну или хотя бы советы об этом).
#refactoring #tips_and_trics
—————————————
How does Sidekiq work?
Для тех, кто не в курсе (и не писал на руби): sidekiq - бэкграунд процессинг для руби, который поднимается как отдельный сервер и асинхронно выполняет код на руби. При этом, из коробки реализованы ретраи, можно делать плагины и реализован graceful shutdown. Под капотом использует редис и решает проблему с канкаренси и многопоточностью в руби приложениях. Ближайший аналог - celery из питона, который работает поверх кролика, а не редиса. Много лет назад я помогал Майку (автору) делать sidekiq и могу сказать, что Майк шарит как делать подобные системы. Ну и благодаря этой работе я смог лучше разобраться в асинхронщине в коде и полюбил редис не только как бд для кеша.
Статья выше (точнее кросспост) – это описание того как работает sidekiq. Из нее узнаете, как работает main loop который запускает задачи, как происходит обработка сигналов, как останавливается сервер, как происходит работа с очередями из редиса, работают ретраи, обрабатываются ошибки и прочее.
Забейте, что тут о руби и редисе, причина, почему статья оказалась в рассылки не в этом. Данный текст будет полезен кому угодно, кто захочет писать бэкграунд процессинг потому, не важно на каком языке и что используя для персистенса. Связанно это с тем, что в тексте описываются общие подходы и принципы написания асинхронных обработчиков. Т.е. взяв идеи из существующей библиотеки, будет проще написать свою реализацию на том же go.
#how_it_works #async_communications
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Legacy Web App Specialist
Под событиями в event-driven коммуникациях или архитектуре подразумевают изменения в системе, которые произошли. Обычно требуется, чтобы события были полезными с точки зрения использования и выразительными (т.е. говорили о том, что произошло без доп контекста). Но в реальности, во время проектирования, можно скатиться в крайность: либо делать жирные события которые говорят сразу обо всем, либо делать кучу мелких событий, которые без полного контекста не будут полезны.
Статья выше как раз объясняет как проектировать события и делает это через понятие granularity и «спектра» значений от слишком мелкого (fine) до слишком крупного (coarse). Дальше автор объясняет, что подразумевается под каждой из крайностей. Например, почему событие
#event_driven #events
—————————————
Векторные базы данных: простым языком про устройство и принцип работы
Хоть в канале уже публиковались статьи о векторных бд (раз, два), но еще одна лишней не будет. Поэтому, сегодня статья от инженеров точки (банка). Где в начале статьи дается проблема: рекомендательная система для знакомств бизнесменов, что бы экспертиза одних людей совпадала с запросами других. Как решение в лоб предлагается вытаскивать токены из описания и искать по максимальному совпадению.Но это не контекстно ориентированный поиск, поэтому автор предлагает использовать вектора.
Дальше автор дает математические выкладки о том, как искать расстояния между векторами (чем ближе - тем больше шансов, что похожи). Ну а что бы хранить вектора и не держать значения в памяти - используются векторные бд. Дальше объясняется, как работают базы, откуда там появляются вектора и как делать запросы. После чего рассказывается об индексации, что приходится балансировать между точностью и скоростью запроса. Для скорости можно либо уменьшать вектора, либо область поиска уменьшать, а в тексте объясняется каждый из подходов. В конце дается сравнение между популярными реализациями баз, с бенчмарками, и даются советы по использованию.
#db #vector_db
—————————————
Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
Лонгрид о том, как компания, которая делала соцсеть с тредами, столкнулась с проблемами и какие решения принимались. В этот раз это bluesky, которая добивались следующих свойств: децентрализация, открытость кода, высокий ттм при низкой команде.
В первой части статьи показывается таймлайн развития проекта, который разбивается на три части: экспериментальную (когда искали нишу), первые пользователи и публичный запуск. После этого рассказывается как развивалась структура системы, от постгреса и авс, до набора из четырех сервисов (персональные данные, фид генерацию, appview и relay). После чего компания переехала на федерацию для персональных данных. После рассказывается о том, как компания скейлилась на 5 миллионов пользователей (и почему постгрес заменили на scyllaDB и где использовали SQLite). В конце найдете общие выводы по проекту. Если хотите делать соцсеть с федерацией - стоит посмотреть.
#how_it_works #social_networks
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Legacy Web App Specialist
Под событиями в event-driven коммуникациях или архитектуре подразумевают изменения в системе, которые произошли. Обычно требуется, чтобы события были полезными с точки зрения использования и выразительными (т.е. говорили о том, что произошло без доп контекста). Но в реальности, во время проектирования, можно скатиться в крайность: либо делать жирные события которые говорят сразу обо всем, либо делать кучу мелких событий, которые без полного контекста не будут полезны.
Статья выше как раз объясняет как проектировать события и делает это через понятие granularity и «спектра» значений от слишком мелкого (fine) до слишком крупного (coarse). Дальше автор объясняет, что подразумевается под каждой из крайностей. Например, почему событие
AccountStatusChanged так себе решение (слишком обобщенное и не говорит о том, что случилось) и почему стоит использовать AccountClosed или AccountActivated. Или почему события CustomerFirstnameChanged и CustomerLastnameChanged лучше заменить на CustomerNameChanged. А для каждого примера объясняется почему может происходить такая ситуация.#event_driven #events
—————————————
Векторные базы данных: простым языком про устройство и принцип работы
Хоть в канале уже публиковались статьи о векторных бд (раз, два), но еще одна лишней не будет. Поэтому, сегодня статья от инженеров точки (банка). Где в начале статьи дается проблема: рекомендательная система для знакомств бизнесменов, что бы экспертиза одних людей совпадала с запросами других. Как решение в лоб предлагается вытаскивать токены из описания и искать по максимальному совпадению.Но это не контекстно ориентированный поиск, поэтому автор предлагает использовать вектора.
Дальше автор дает математические выкладки о том, как искать расстояния между векторами (чем ближе - тем больше шансов, что похожи). Ну а что бы хранить вектора и не держать значения в памяти - используются векторные бд. Дальше объясняется, как работают базы, откуда там появляются вектора и как делать запросы. После чего рассказывается об индексации, что приходится балансировать между точностью и скоростью запроса. Для скорости можно либо уменьшать вектора, либо область поиска уменьшать, а в тексте объясняется каждый из подходов. В конце дается сравнение между популярными реализациями баз, с бенчмарками, и даются советы по использованию.
#db #vector_db
—————————————
Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
Лонгрид о том, как компания, которая делала соцсеть с тредами, столкнулась с проблемами и какие решения принимались. В этот раз это bluesky, которая добивались следующих свойств: децентрализация, открытость кода, высокий ттм при низкой команде.
В первой части статьи показывается таймлайн развития проекта, который разбивается на три части: экспериментальную (когда искали нишу), первые пользователи и публичный запуск. После этого рассказывается как развивалась структура системы, от постгреса и авс, до набора из четырех сервисов (персональные данные, фид генерацию, appview и relay). После чего компания переехала на федерацию для персональных данных. После рассказывается о том, как компания скейлилась на 5 миллионов пользователей (и почему постгрес заменили на scyllaDB и где использовали SQLite). В конце найдете общие выводы по проекту. Если хотите делать соцсеть с федерацией - стоит посмотреть.
#how_it_works #social_networks
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
From Text to Models: A Comprehensive Guide to Textual Modeling and Diagrams as Code Tools in 2024
Название статьи говорит само о себе – автор собирает библиотеки для генерации диаграмм из кода. Описанные инструменты делятся на следующие группы:
- генераторы UML диаграмм;
- генераторы DB схем;
- генераторы воркфлоу диаграм;
- перевод кода в архитектурные модели;
- инструменты, которые умеют генерировать разные модели;
- мертвые проекты, на которые забили;
Удивило, что в списке не заметил mermaid. Если думали какой инструмент выбрать для схем и не хотите рисовать руками (или планируете в гите схемы держать) – стоит посмотреть статью.
#diagrams
—————————————
Async APIs - don't confuse your events, commands and state
Еще одна статья об асинхронных коммуникациях. В этот раз автор рассказывает о видах используемых событий в системах, которыми занимается. Важно: статья не претендует на истину, автор описывает персональный опыт. Например, в событиях не передаются данные, а только название события и id с чем событие произошло
В начале статьи дается определение для четырех групп «событий»:
- событиям (event);
- командам;
- «стейт событиям» (CDC или стриминг событиям);
- time series values;
Дальше подробно объясняется разница между событиями и событиями связанными со стейтом (первые говорят что произошло, вторые передают агрегат/энтити). Понравилось, что описываются трейдоффы что бы лучше выбрать что подходит больше. после автор рассказывает о командах и в чем отличие команды от событий/стейта. В конце рассказывается о временных данных.
#async_communications #event_driven
—————————————
Starting SRE at startups and smaller organizations – Boost SRE work
На первый взгляд SRE и стартапы не совместимые вещи, но автор лонгрида пытается разрушить это предубеждение.
В начале описываются проблемы, с которыми поможет SRE в стартапах: даунтаймы, перфоманс, ручная работа, бесконтрольное использование новых технологий и проблемы с нестабильностью трафика. После чего упоминаются три анти паттерна по разворачиванию SRE в стартапах:
- начать процесс найма SRE специалиста, без пониманий, что от SRE требуется;
- бездумное копировать процессы крупных компаний (автор говорит о гугле);
- пытаться сразу внедрить как можно больше практик;
После чего, в последней половине лонгрида, автор дает советы которые помогут с работой:
- вместо выделенного человека, перекинуть SRE роль на кого-то из существующей команды, например разраба;
- уменьшить количество данных для анализа работы системы;
- использовать меньше инструментов и не экспериментировать лишний раз;
После этого упоминается мысль, что можно начать с одной ограниченной области, что бы показать что подходы помогают и в тексте даются примеры что делать. Кроме этого даются советы по инструментам и на что смотреть в начале работы.
#SRE
——— одной строкой ———
- Видео объяснение того, как работет оператор сложения в питоне. Кишки интерпретатора и код на си прилагается. Чем-то напомнило ruby under a microscope, но для питонистов.
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
From Text to Models: A Comprehensive Guide to Textual Modeling and Diagrams as Code Tools in 2024
Название статьи говорит само о себе – автор собирает библиотеки для генерации диаграмм из кода. Описанные инструменты делятся на следующие группы:
- генераторы UML диаграмм;
- генераторы DB схем;
- генераторы воркфлоу диаграм;
- перевод кода в архитектурные модели;
- инструменты, которые умеют генерировать разные модели;
- мертвые проекты, на которые забили;
Удивило, что в списке не заметил mermaid. Если думали какой инструмент выбрать для схем и не хотите рисовать руками (или планируете в гите схемы держать) – стоит посмотреть статью.
#diagrams
—————————————
Async APIs - don't confuse your events, commands and state
Еще одна статья об асинхронных коммуникациях. В этот раз автор рассказывает о видах используемых событий в системах, которыми занимается. Важно: статья не претендует на истину, автор описывает персональный опыт. Например, в событиях не передаются данные, а только название события и id с чем событие произошло
В начале статьи дается определение для четырех групп «событий»:
- событиям (event);
- командам;
- «стейт событиям» (CDC или стриминг событиям);
- time series values;
Дальше подробно объясняется разница между событиями и событиями связанными со стейтом (первые говорят что произошло, вторые передают агрегат/энтити). Понравилось, что описываются трейдоффы что бы лучше выбрать что подходит больше. после автор рассказывает о командах и в чем отличие команды от событий/стейта. В конце рассказывается о временных данных.
#async_communications #event_driven
—————————————
Starting SRE at startups and smaller organizations – Boost SRE work
На первый взгляд SRE и стартапы не совместимые вещи, но автор лонгрида пытается разрушить это предубеждение.
В начале описываются проблемы, с которыми поможет SRE в стартапах: даунтаймы, перфоманс, ручная работа, бесконтрольное использование новых технологий и проблемы с нестабильностью трафика. После чего упоминаются три анти паттерна по разворачиванию SRE в стартапах:
- начать процесс найма SRE специалиста, без пониманий, что от SRE требуется;
- бездумное копировать процессы крупных компаний (автор говорит о гугле);
- пытаться сразу внедрить как можно больше практик;
После чего, в последней половине лонгрида, автор дает советы которые помогут с работой:
- вместо выделенного человека, перекинуть SRE роль на кого-то из существующей команды, например разраба;
- уменьшить количество данных для анализа работы системы;
- использовать меньше инструментов и не экспериментировать лишний раз;
После этого упоминается мысль, что можно начать с одной ограниченной области, что бы показать что подходы помогают и в тексте даются примеры что делать. Кроме этого даются советы по инструментам и на что смотреть в начале работы.
#SRE
——— одной строкой ———
- Видео объяснение того, как работет оператор сложения в питоне. Кишки интерпретатора и код на си прилагается. Чем-то напомнило ruby under a microscope, но для питонистов.
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Serverless Communication Patterns
Хоть статья о серверлесс приложениях, информация связанная с паттернами коммуникаций и reliability тактиками из текста будут полезны в любых распределенных системах. Начинается текст с описания частей из которых состоят серверлесс приложений: compute, storage, broker, event, integration и direction. После автор приводит примеры вопросов, которые возникают при выборе коммуникаций в серверлесс системах: синхронные/асинхронные, какой вид консистентности нужен, направление зависимостей и так далее.
Дальше обсуждается какие виды коммуникаций используются в серверлесс мире (request/response, polling, event-driven) и каждый вид коммуникации подробно разбирается с примерами и картинками. А в конце, автор затрагивает тему reliability в контексте коммуникаций, т.е. как сделать так, чтобы система была отказоустойчивой и как выбор коммуникаций влияет на характеристику. Для этого рассматривается пять основных тактик (каждая так же подробно описывается с картинками): fail fast, graceful degradation, reliable states distribution, compensating transaction и softening dependencies.
#serverless #reliability #communications
—————————————
Транзакция, ACID, CAP теорема и уровни изоляций транзакций простыми словами
Статья – выжимка информации по темам связанным с реляционными базами данных и консистентностью данных. Рассказывается про транзакции (в чем разница между коммитами и ролбеками), что такое ACID, немного говорится об CAP теореме (без упоминания о PACELC). В конце кусок об изоляции транзакций: сначала говорится о том, что может произойти с описанием ситуации (dirty read, non repeatable read и non repeatable read), после рассказывается о четырех уровнях изоляции транзакций и какая связь с возможными ситуациями вокруг транзакций и при чем тут перфоманс и консистентность.
Если разбираетесь в темах описанных в статье – статью можно пропустить. Если хотите вспомнить базу перед собеседованием или что-то не знаете – лучше прочитать.
#data_managment #consistency #db
—————————————
10 Must Know System Design Concepts for Interviews
Скептически отношусь к system design interview, но вижу, что подобные интервью становятся популярнее. Поэтому сегодня будет статья, в которой указываются темы, помогающие в прохождении собеседования.
Автор выделяет 10 тем:
- Scalability
- Availability
- Reliability
- Fault Tolerance
- Caching Strategies
- Load Balancing
- Security
- Scalable Data Management
- Design Patterns
- Performance Optimization
Каждый блок кратко описывает тему и приводятся паттерны/подходы, о которых стоит знать. Важно понимать, что текст не претендует на книгу, а скорее перечень тем, которые придется детально изучать самостоятельно.
Из плюсов – наличие инфографики, в которой перечисляются описанные в тексте темы.
Русский перевод
#system_design_interview
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Serverless Communication Patterns
Хоть статья о серверлесс приложениях, информация связанная с паттернами коммуникаций и reliability тактиками из текста будут полезны в любых распределенных системах. Начинается текст с описания частей из которых состоят серверлесс приложений: compute, storage, broker, event, integration и direction. После автор приводит примеры вопросов, которые возникают при выборе коммуникаций в серверлесс системах: синхронные/асинхронные, какой вид консистентности нужен, направление зависимостей и так далее.
Дальше обсуждается какие виды коммуникаций используются в серверлесс мире (request/response, polling, event-driven) и каждый вид коммуникации подробно разбирается с примерами и картинками. А в конце, автор затрагивает тему reliability в контексте коммуникаций, т.е. как сделать так, чтобы система была отказоустойчивой и как выбор коммуникаций влияет на характеристику. Для этого рассматривается пять основных тактик (каждая так же подробно описывается с картинками): fail fast, graceful degradation, reliable states distribution, compensating transaction и softening dependencies.
#serverless #reliability #communications
—————————————
Транзакция, ACID, CAP теорема и уровни изоляций транзакций простыми словами
Статья – выжимка информации по темам связанным с реляционными базами данных и консистентностью данных. Рассказывается про транзакции (в чем разница между коммитами и ролбеками), что такое ACID, немного говорится об CAP теореме (без упоминания о PACELC). В конце кусок об изоляции транзакций: сначала говорится о том, что может произойти с описанием ситуации (dirty read, non repeatable read и non repeatable read), после рассказывается о четырех уровнях изоляции транзакций и какая связь с возможными ситуациями вокруг транзакций и при чем тут перфоманс и консистентность.
Если разбираетесь в темах описанных в статье – статью можно пропустить. Если хотите вспомнить базу перед собеседованием или что-то не знаете – лучше прочитать.
#data_managment #consistency #db
—————————————
10 Must Know System Design Concepts for Interviews
Скептически отношусь к system design interview, но вижу, что подобные интервью становятся популярнее. Поэтому сегодня будет статья, в которой указываются темы, помогающие в прохождении собеседования.
Автор выделяет 10 тем:
- Scalability
- Availability
- Reliability
- Fault Tolerance
- Caching Strategies
- Load Balancing
- Security
- Scalable Data Management
- Design Patterns
- Performance Optimization
Каждый блок кратко описывает тему и приводятся паттерны/подходы, о которых стоит знать. Важно понимать, что текст не претендует на книгу, а скорее перечень тем, которые придется детально изучать самостоятельно.
Из плюсов – наличие инфографики, в которой перечисляются описанные в тексте темы.
Русский перевод
#system_design_interview
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Evolution of Monolithic Systems
Статья с рефлексией и рассказом об опыте работы с монолитами от человека с 20 летним стажем. Текст сводится к тому, что автор рассказывает о трех видах монолитов, с которыми сталкивался:
- оригинальный монолит
- организационный монолит
- “Seven Technical Monoliths”
Первый - о монолите в начальном этапе жизни, когда разработчик либо один либо пара человек. Технически это монолит с одной базой, сервером и кодом. Главный выбор такого монолита – TTM (time to market) превыше всего, но при этом, тех долг растет.
Второй - когда MVP появляется, количество разработчиков увеличивается, становится сложнее его поддерживать и предсказывать что дальше делать.
Третий состоит из семи вариантов, четыре простых (монорепа, монолитное приложение, сервер и бд) и три сложных (распределенный монолит, Cloud Native и GraphQL монолиты). Для каждого вида дается объяснение что это такое и какие ключевые свойства монолита.
Понравилось, что автор, для каждого из видов монолитов, дает список “Key Design Investments”, которые могут помочь справиться со структурой.
#monolith #system_structure
—————————————
Understanding Quality Attribute Requirements for Machine Learning Systems
Если проходили анализ систем или читали fundamentals of SA то знаете, что технические решения стоит выбирать на основе требуемых от системы свойств (например: распределенная система будет спорным выбором, если денег мало). Статья выше использует эту идею, но вместо веб приложений применяет ее к ML системам.
Вначале дается краткое описание характеристик, откуда они берутся и какие существуют (если fundamentals читали - можно пропустить эту часть). После автор переходит к ML моделям, где обычно фокусируются на точности модели, но могут забыть о доступности, перфомансе или надежности. Дальше указывается список характеристик, на которые стоит обратить внимание, причем, даются референсы на работу букинга и пейперы. После, рассказывается как использовать эту информацию – зачем нужны Quality Attribute Scenario и описывается пример использования сценария для одной из ML моделей.
#architecture_characteristics
—————————————
The Turbo-Mailbox
Статья рассказывает о способе коммуникации в мире enterprise applications, который называется Turbo-Mailbox. Данный подход работает вокруг сообщений между компонентами, роутит их и забирает на себя компромиссы из CAP теоремы. Такой паттерн работает как с синхронными вызовами, так и с асинхронными (сообщениями и событиями). При этом, для событий гарантируется «Once and Only Once Delivery», лоад балансинг из коробки, DLH, скалабилити и так далее. При этом, Turbo-Mailbox может работать как оркестратор, так как является federated. В статье найдете больше информации о паттерне, который пока выглядит слишком хорошо, но странно, что минусы и проблемы в тексте не упоминаются. Поэтому, советую скептически относиться.
#enterprise_applications #communications
Буду рад предложениям, вопросам и идеям связанным с каналом или любыми архитектурными/техническими вопросами. Можно написать в личку, а можно в анонимную форму.
—————————————
Evolution of Monolithic Systems
Статья с рефлексией и рассказом об опыте работы с монолитами от человека с 20 летним стажем. Текст сводится к тому, что автор рассказывает о трех видах монолитов, с которыми сталкивался:
- оригинальный монолит
- организационный монолит
- “Seven Technical Monoliths”
Первый - о монолите в начальном этапе жизни, когда разработчик либо один либо пара человек. Технически это монолит с одной базой, сервером и кодом. Главный выбор такого монолита – TTM (time to market) превыше всего, но при этом, тех долг растет.
Второй - когда MVP появляется, количество разработчиков увеличивается, становится сложнее его поддерживать и предсказывать что дальше делать.
Третий состоит из семи вариантов, четыре простых (монорепа, монолитное приложение, сервер и бд) и три сложных (распределенный монолит, Cloud Native и GraphQL монолиты). Для каждого вида дается объяснение что это такое и какие ключевые свойства монолита.
Понравилось, что автор, для каждого из видов монолитов, дает список “Key Design Investments”, которые могут помочь справиться со структурой.
#monolith #system_structure
—————————————
Understanding Quality Attribute Requirements for Machine Learning Systems
Если проходили анализ систем или читали fundamentals of SA то знаете, что технические решения стоит выбирать на основе требуемых от системы свойств (например: распределенная система будет спорным выбором, если денег мало). Статья выше использует эту идею, но вместо веб приложений применяет ее к ML системам.
Вначале дается краткое описание характеристик, откуда они берутся и какие существуют (если fundamentals читали - можно пропустить эту часть). После автор переходит к ML моделям, где обычно фокусируются на точности модели, но могут забыть о доступности, перфомансе или надежности. Дальше указывается список характеристик, на которые стоит обратить внимание, причем, даются референсы на работу букинга и пейперы. После, рассказывается как использовать эту информацию – зачем нужны Quality Attribute Scenario и описывается пример использования сценария для одной из ML моделей.
#architecture_characteristics
—————————————
The Turbo-Mailbox
Статья рассказывает о способе коммуникации в мире enterprise applications, который называется Turbo-Mailbox. Данный подход работает вокруг сообщений между компонентами, роутит их и забирает на себя компромиссы из CAP теоремы. Такой паттерн работает как с синхронными вызовами, так и с асинхронными (сообщениями и событиями). При этом, для событий гарантируется «Once and Only Once Delivery», лоад балансинг из коробки, DLH, скалабилити и так далее. При этом, Turbo-Mailbox может работать как оркестратор, так как является federated. В статье найдете больше информации о паттерне, который пока выглядит слишком хорошо, но странно, что минусы и проблемы в тексте не упоминаются. Поэтому, советую скептически относиться.
#enterprise_applications #communications