اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
2pegramming
رفتن به کانال در Telegram
Грустно об архитектуре и программировании. https://pepegramming.site Ответы на вопросы подписчиков: http://pepegramming.site/questions/
نمایش بیشتر4 507
مشترکین
اطلاعاتی وجود ندارد24 ساعت
+57 روز
+1430 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
ژوئن '26
ژوئن '26
+28
در 0 کانالها
مه '26
+60
در 0 کانالها
Get PRO
آوریل '26
+21
در 0 کانالها
Get PRO
مارس '26
+22
در 0 کانالها
Get PRO
فوریه '26
+46
در 0 کانالها
Get PRO
ژانویه '26
+41
در 0 کانالها
Get PRO
دسامبر '25
+23
در 0 کانالها
Get PRO
نوامبر '25
+43
در 0 کانالها
Get PRO
اکتبر '25
+87
در 0 کانالها
Get PRO
سپتامبر '25
+35
در 0 کانالها
Get PRO
اوت '25
+26
در 0 کانالها
Get PRO
ژوئیه '25
+48
در 0 کانالها
Get PRO
ژوئن '25
+51
در 0 کانالها
Get PRO
مه '25
+67
در 0 کانالها
Get PRO
آوریل '25
+54
در 1 کانالها
Get PRO
مارس '25
+49
در 0 کانالها
Get PRO
فوریه '25
+68
در 0 کانالها
Get PRO
ژانویه '25
+85
در 0 کانالها
Get PRO
دسامبر '24
+83
در 1 کانالها
Get PRO
نوامبر '24
+117
در 0 کانالها
Get PRO
اکتبر '24
+496
در 1 کانالها
Get PRO
سپتامبر '24
+122
در 1 کانالها
Get PRO
اوت '24
+46
در 0 کانالها
Get PRO
ژوئیه '24
+71
در 0 کانالها
Get PRO
ژوئن '24
+95
در 0 کانالها
Get PRO
مه '24
+45
در 0 کانالها
Get PRO
آوریل '24
+26
در 0 کانالها
Get PRO
مارس '24
+81
در 0 کانالها
Get PRO
فوریه '24
+35
در 0 کانالها
Get PRO
ژانویه '24
+43
در 0 کانالها
Get PRO
دسامبر '23
+72
در 0 کانالها
Get PRO
نوامبر '23
+52
در 0 کانالها
Get PRO
اکتبر '23
+67
در 0 کانالها
Get PRO
سپتامبر '23
+58
در 0 کانالها
Get PRO
اوت '23
+128
در 0 کانالها
Get PRO
ژوئیه '23
+35
در 0 کانالها
Get PRO
ژوئن '23
+94
در 0 کانالها
Get PRO
مه '23
+27
در 0 کانالها
Get PRO
آوریل '23
+40
در 0 کانالها
Get PRO
مارس '23
+53
در 0 کانالها
Get PRO
فوریه '23
+28
در 0 کانالها
Get PRO
ژانویه '23
+33
در 0 کانالها
Get PRO
دسامبر '22
+27
در 0 کانالها
Get PRO
نوامبر '22
+47
در 0 کانالها
Get PRO
اکتبر '22
+105
در 0 کانالها
Get PRO
سپتامبر '22
+172
در 0 کانالها
Get PRO
اوت '22
+105
در 0 کانالها
Get PRO
ژوئیه '22
+75
در 0 کانالها
Get PRO
ژوئن '22
+89
در 0 کانالها
Get PRO
مه '22
+83
در 0 کانالها
Get PRO
آوریل '22
+169
در 0 کانالها
Get PRO
مارس '22
+250
در 0 کانالها
Get PRO
فوریه '22
+30
در 0 کانالها
Get PRO
ژانویه '22
+29
در 0 کانالها
Get PRO
دسامبر '21
+31
در 0 کانالها
Get PRO
نوامبر '21
+84
در 0 کانالها
Get PRO
اکتبر '21
+49
در 0 کانالها
Get PRO
سپتامبر '21
+53
در 0 کانالها
Get PRO
اوت '21
+69
در 0 کانالها
Get PRO
ژوئیه '21
+49
در 0 کانالها
Get PRO
ژوئن '21
+77
در 0 کانالها
Get PRO
مه '21
+40
در 0 کانالها
Get PRO
آوریل '21
+70
در 0 کانالها
Get PRO
مارس '21
+105
در 0 کانالها
Get PRO
فوریه '21
+571
در 0 کانالها
Get PRO
ژانویه '21
+125
در 0 کانالها
Get PRO
دسامبر '20
+1 299
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 23 ژوئن | +3 | |||
| 22 ژوئن | +1 | |||
| 21 ژوئن | +1 | |||
| 20 ژوئن | +4 | |||
| 19 ژوئن | 0 | |||
| 18 ژوئن | +1 | |||
| 17 ژوئن | 0 | |||
| 16 ژوئن | 0 | |||
| 15 ژوئن | 0 | |||
| 14 ژوئن | 0 | |||
| 13 ژوئن | +1 | |||
| 12 ژوئن | 0 | |||
| 11 ژوئن | +2 | |||
| 10 ژوئن | 0 | |||
| 09 ژوئن | +1 | |||
| 08 ژوئن | +3 | |||
| 07 ژوئن | 0 | |||
| 06 ژوئن | +2 | |||
| 05 ژوئن | +2 | |||
| 04 ژوئن | +3 | |||
| 03 ژوئن | +2 | |||
| 02 ژوئن | +1 | |||
| 01 ژوئن | +1 |
پستهای کانال
Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Netflix Maps Thousands of Microservices in Real-Time
Очередная статья о нетфликсе, в которой рассказано, как в компании решали технические проблемы. Сегодня текст о том, как в компании улучшали наблюдаемость системы, а именно строили граф связи сервисов. Для этого создали Service Topology, о которой и рассказывается в тексте.
Текст начинается с описания мотивации компании: повторяющиеся вопросы о структуре распределенной системы от инженеров, которые систему чинили или меняли. Плюсом, полезно было бы сразу понимать, что заденет изменения в сервисах. Для этого решили собирать информацию с трех мест: eBPF network flow logs, IPC metrics (для эндпоинтов) и распределенные трассировки. Далее положили собранную информацию в графовую бд, подключили grpc, настроили фильтрацию (включая фильтрацию по времени работы) и получили «карту» системы. Причем, данные хранятся не как снапшот, а с привязкой ко времени, что позволяет собирать временные проджекшены.
#how_it_works #observability #distributed_systems
—————————————
Fundamental concepts of plugin infrastructures
Чем дольше живу, тем больше думаю о недооцененности системы плагинов для создания софта. В частности, недооцененность microkernel архитектурного стиля. Хоть плагины распространены в редакторах, браузерах, играх и других приложениях, но считаю собственным долгом двигать эту тему в массы. Поэтому сегодня статья о четырех концепциях для реализации плагинов.
Начинается текст с примера на python, где автор решает сделать blog engine для генерации html. Далее объясняется, при чем тут плагины и показывается подход, который нравится автору: через plugin registry, хуки и discovery через загрузку модулей. Во второй части текста описываются четыре концепции, о которых стоит помнить: discovery, registration, mount points и extension API. В конце рассматривается как в mercurial и wordpress реализованы эти четыре концепции.
#microkernel #plugin_system
—————————————
Как найти медленный запрос в PostgreSQL: три инструмента мониторинга
Продолжение статьей о том, как оптимизировать запросы в постгрес. В тексте найдете описание трех инструментов:
-
pg_stat_statements. Отслеживает статистику выполнения запросов к бд, попутно группируя одинаковые по структуре запросы. Как примеры использования, приводится поиск частых и медленных запросов, а также запросов с низким уровнем кеширования;
- auto_explain. Автоматически выполняет EXPLAIN ANALYZE для медленных запросов с записью плана в лог. Тут важно следить за количеством записанных логов;
- log_min_duration_statement. Записывает в лог запросы, которые выполняются медленнее, чем заданный порог. Тоже важно следить за размером лога.
Так как каждое из трех инструментов расширения — ставить каждое придется через изменение postgresql.conf (в статье описаны шаги для включения и настройки). В конце найдете «эвристику» для выбора, какое из расширений включать в зависимости от нагрузки и окружения (дев/стейдж/прод).
#psql| 2 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Сколько стоит ваш техдолг: методики, цифры, российская специфика
В канале раз 5 упоминались статьи связанны с тех долгом, например «вводная» статья упоминалась год назад (остальные статьи по тегу). Сегодня еще один текст о долге, только авторы решили посчитать «долг» в рублях.
Текст начинается с объяснения, почему тех долг не видит бизнес и наоборот. Авторы связывают отчетность и фокус внимания бизнеса, куда не попадает техническая составляющая, не говоря уже о долге. Далее предлагается три способа подсветить долг бизнесу: прямые опросы людей, добавление тега «tech dept» в «джиру» и git churn (показывает процент перезаписанного кода за время). В конце предлагается три способа «оценки» долга в деньга:
- Считаем время, потраченное на затупы из-за тех долга и умножаем на часовую ставку. Берем цифру и показываем, сколько денег можно сохранить;
- Берем SonarQube и SQALE, полученное значение умножаем на часовую ставку, идем к бизнесу и повторяем первый вариант;
- Считаем cost of delay. Тут нужно посчитать задержку выхода фичи, в итоге получаем два числа: сколько времени фича реально делалась и сколько делалась бы без задержек.
P.S.: Учтите, что статья в блоге компании, которая «продает» собственное приложение. На базовую информацию не влияет, но мало ли.
#tech_debt
—————————————
PostgreSQL 19: Native Graph Queries Are Here
Случайно узнал, что осенью поменяю планы и буду ковыряться с постгресом. Связанно это с тем, что в сентябре выходит 19 версия, где главная, для меня, фича — нативная поддержка графов (хотя возможно гта победит графы). Почему-то уверен, что графы появились благодаря RAG и LLM. Синтаксис запросов уже описан в ISO SQL:2023 Part 16, а язык запросов назвали SQL/PGQ (Property Graph Queries). Статья выше объясняет как будет выглядеть работа с графами в пг.
Пересказывать статью не буду, кратно расскажу как работает. Для начала работы с графами определяем property graph. Делается это через CREATE PROPERTY GRAPH, где явно указываются vertex (ноды, вершины) и edges (связи) таблицы (причем таблиц может быть больше одной). А что бы сделать запрос, используется SELECT * FROM GRAPH_TABLE (property_graph MATCH ...). Плюс стандарта в том, что язык запроса похож на cypher.
В статье найдете примеры и, что радует, автор описал ограничения: fixed-depth pattern matching. Ну и другие фичи 19 версии тоже описываются.
#psql #graph
—————————————
What Is the 3-2-1 Backup Rule and Why It's Evolved to 3-2-1-1-0?
Я не DBA, поэтому о правиле 3-2-1 слышал, но использую только для 3 наборов данных и это не о коде. Если что, 3-2-1 о том, что нужны 3 копии, на 2 видах носителей и 1 копия должна быть в другом гео месте. Поэтому удивился, когда увидел 3-2-1-1-0 схему, думая что 3-2-1 уже заморочена для 80% проектов, но киберпреступления повлияли на бекапы.
Начинается текст с объяснения 3-2-1 подхода, быстро переходя в ответ на вопрос — почему такого подхода уже не хватает (спойлер: с шифровальщиками не помогает). Поэтому, как эволюция подхода, предлагается добавить 1 иммутабельную копию, отключенную от интернета и 0 ошибок от проверки восстановления (поэтому 3-2-1-1-0). Далее рассказывается, как реализовать новое правило: локальный бекап на диске, второй бекап на другом носителе, cloud copy, копия на ленте/в облаке с object lock и автоматизация накатки бекапов. В конце описываются best practices и FAQ (вопросы — пересказ статьи).
Русский перевод
#db #backups | 1 562 |
| 3 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Scaling ArchUnit with Nebula ArchRules
Статья от нетфликса, в которой инженеры делятся опытом решения проблем с обратной совместимостью совместимостью библиотек. А так как нетфликс использует джаву, то для решения взяли ArchUnit («тесты» для структуры проекта на джаве).
Текст начинается с проблемы: библиотека обновилась с breaking changes, из-за чего развалились сервисы на джаве. Как решение управления жизненным циклом библиотек выбрали archnunit, потому что работает поверх байткода (т.е. работает в jvm стеке), позволяет добавлять правила и содержит низкоуровневый API для сложных правил. В самом начале работы, инженеры, решили настроить работу с централизованным стором правил для проектов (чтобы не копировать правила из проекта в проект). Далее описывается как запускаются правила и как работать с артефактами библиотеки. В конце описываются некоторые примеры правил (безопасность, применение nullable аннотаций и так далее)
Отдельно отмечу, что в русском переводе встречаются комментарии от джава разработчика, который раскрывает части статьи для людей вне джава экосистемы. Отдельно упомяну первый комментарий (в тексте), где дается ссылка на реддит с обсуждением использования модулей, вместо archunit.
Русский перевод
#archUnit #fitness_functions
—————————————
A Field Guide to Alternative Storage Engines for PostgreSQL
Статья из серии «а что, так можно было?» (я не настоящий DBA). В 2019 году в 12 постгресе сделали table access method API. Предполагалось, что будут добавляться новые способы для хранения данных (колонки для аналитики, undo-log для OLTP и так далее). Автор текста выше решил написать, что из себя представляет экосистема.
Текст начинается с объяснения принципов работы API. Тут важно, что TAM API не является «настоящим» pluggable storage layer, только tuple-shaped abstraction. При этом, индексы тоже не работают. Ну и механизмы разбиваются на 4 группы:
- Heap replacements;
- Columnar;
- Lakehouse-backed (тут постгрес — интерфейс запросов поверх внешнего колоночного механизма);
- Специализированные TAM модели (тут автор упоминает три решения, одно связана с TimescaleDB и уже умерло).
Для каждой группы автор приводит примеры реальных проектов, кратко объясняя как TAM работает. А в конце делится советами по выбору подходящего TAM (если конечно решитесь).
#psql
—————————————
Building a mental model for Stripe payments
Мне нравятся статьи в которых описывается реализация домена (8 лет жду аналога книги Фаулера). Статья выше — почти такая статья, потому что текст, в краткой форме, описывает принципы работы и объясняет работу стейт машины для PaymentIntent.
Начинается пост с примера: делаете магазин, доходите до страницы оформления заказа — начинаются проблемы. Как минимум, придется думать о взаимодействии с платежными системами, банком клиента, anti fraud процессах, соблюдении нормативов и так далее. Далее рассказывается о PaymentIntent объекте: намерение получить платеж от клиента. Сам объект отслеживает жизненный цикл платежа от старта и до конца (картинка с sequence diagram прилагается). Далее описываются пять этапов, через которые проходит платеж (оформление заказа, токенизация, аунтификация, capture и расчет со сверкой). В конце описывается, как работать с вебкухами страйпа, что бы знать что с платежом происходит.
Если устанете читать — на сайте сделали «терминал», где запускается змейка (вызывается на <c>).
#payments #domain_implementation | 1 780 |
| 4 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
A Promising New Metric To Track Maintainability
Стараюсь пропагандировать ADD, где ключевая идея — принятие решений на основе характеристик. В случае с исчисляемыми метриками — вопросов нет. Сложности начинаются с «субъективными» и не исчисляемыми метриками, например с maintainability или modifiability. Поэтому сегодня статья, где предлагается математическую модель для расчета maintainability.
Начинается текст с предположения, что coupling и cyclic dependencies помогут с расчетом, но, из-за вертикального и горизонтального разбиения, значения считать сложно. Как решение вводится понятие verticalization, благодаря которому, получается Maintainability Level через работу с циклами графа. Во следующей версии метрики, вводится штраф за «длину» цикла. После чего автор занимается fine tuning метрики. Для систем с малым количеством компонентов, метрика работала плохо. Вторая ситуация возникла, когда метрика показала «хорошее» значение, но разработчики были не удовлетворены поддерживаемостью. Проблема оказалась в структуре модулей, которую решили дополнительным условием.
#maintainability
—————————————
Why senior developers fail to communicate their expertise
Проблемы в коммуникации между техническим отделом и «бизнесом» — база. Причин много: отличия в «важности» (у одних — сложность реализации фичи, у вторых — как инвестора на деньги разорить), разные цели от системы и так далее. Причин много, но автор статьи решил пойти по пути разбивки «бизнеса» на два цикла: вывод продукта на рынок и работа с платящими клиентами.
Начинается текст с ситуации, когда бизнес приходит с гениальной идеей: «меняем разработчиков на LLM». От подобной идеи у разработчиков дергается глаз из-за сложности (complexity). Через конфликт, автор вводит первый цикл (в котором находятся продажники, продакт-менеджеры, CEO): компания выводит продукт на рынок и получает фидбек. В таком цикле главная проблема — неопределенность, которая решается скоростью получения фидбека. Во втором цикле, где компания предоставляет услугу пользователю и получает деньги, главное — стабильность, а со сложностью проблема. Далее автор связывает два цикла через «компанию» из-за чего получается несогласованность между людьми в разных циклах. В конце предлагаются решения, о чем уже прочтете в статье.
Русский перевод
#ppl_communications
—————————————
On mashing up modelling techniques for fun and profit
Статья заинтересовала идеей смешивания context map из ddd и c4 в одну модель. Если что, идея context map в отображении bounded context из DDD и связей между контекстами. А главная ценность — отображение паттернов коммуникаций из DDD. Добавив информацию о «типах» коммуникаций контекстов в с4, получаем больше информации о взаимодействии частей системы не только на техническом, но и на социо уровне (а software system — socio-tech system).
Начинается текст с показа автором модели совмещенного context map и c4, которую сделали для воркшопа. А после объяснения плюсов подхода показывается как подобные модели делать. Сначала делается c4 level 1 с интеграциями, после чего добавляется level 2. Далее добавляются паттерны коммуникации на level 2 (open host, anti-corruption и так далее). После чего добавляются контексты и объясняется в чем плюсы и минусы подхода. В конце дается название подходу (Model Storming). Единственное что огорчило — нет конкретных инструментов, а статья сугубо идейная.
#c4 #ddd | 1 894 |
| 5 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Seeing like a spreadsheet
Надо признаться — я фанат таблиц (которые sheets). И с каждым годом больше и больше верю, что если бизнес модель нельзя описать в таблицах, то лучше два раза подумать, перед тем как связываться с таким бизнесом. Автор статьи описывает собственные размышления о том, как таблицы поменяли бизнес в америки.
Начинается текст с того, как работали до появления таблиц: как страдали коммуникации и почему бизнес был чаще семейным. Далее появляются заводы, следовательно требования к контролю увеличиваются, что приводит к развитию инструментов координации. Но проблемы проверки и расчетов никуда не девались, что привело к появлению таблиц в 60-70тых годах. Далее автор описывает появление VisiCalc (визуальный калькулятор) — прародителя современных таблиц, благодаря которому появился сначала lotus, а потом и excel. В последней части автор описывает как таблицы повлияли на симуляцию и финансы и в конце подвязывает нейронки.
#sheets
—————————————
Путеводитель по матанализу, который скрывали от вас в вузе
На прошлой неделе упоминал статью с попыткой автора «натянуть» концепции из матанализа на код. Пока читал статью, понял, что матан уже забыл, поэтому сегодня — краткое интро в матанализ. Причем не список терминов, а логика развития идей Аристотеля, которые в конце придут к матанализу (в институте был только Коши, поэтому статья и появилась в канале). Сразу скажу, по ссылке лонгрид, также отмечу, что комментарии посмотреть тоже стоит (всего их 325 штук).
Текст целиком пересказывать не буду из-за объема (3 части и 11 глав в сумме). Вместо этого расскажу о том, что самому было интересно прочитать. Во первых, понравилась, сама идея объяснения анализа через логические рассуждения, без эпсилон-дельта приколов (пример логического доказательства найдете в самом начале). Также понравилось, как размышления философов подвязали с бесконечностью и множествами. Плюсом, понравилось как вывелось определение производной через «о-малое».
#math
—————————————
Payment systems don’t move money. They move promises.
Статья из серии «как работает Х». В тексте выше, автор, объясняет как работает payment processing, при чем тут две системы («быстрая» и «медленная», которые называет clocks) и почему в момент оплаты ничего, кроме «обещания оплаты» не происходит.
Начинается текст с объяснения того, как работает «быстрая» система (говорит, что клиент намерен что-то сделать с доступным балансом). При этом, банк, в этот момент, не включается в процесс. В него только уходит намерение, которое может обрабатываться от секунд, до дней. «Медленная» система уже получает событие из банка и работает с ledger. Далее описывается «стандартная» ошибка: posting to the ledger inside the bank callback (нормального перевода не придумал, поэтому цитатой), что приводит к расхождению данных, дублям и другим проблемам. Далее описывается payout table, таблица, в которую пишутся намерения из «быстрой» системы и которую обновляет колбэк из банка. Ну а ledger уже использует payout table. А в конце, автор отвечает на популярные вопросы (зачем нужен баланс и ledger в разных местах, почему не взять CQRS или сагу и так далее).
#payment #fintech | 2 148 |
| 6 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo
Очередная статья, в которой компания описывает, как решала проблемы в технической системе. Сегодня страйп, который сделал один из самых больших руби монорепозиториев (50+ миллионов строк). А возникшая проблема — как перестать гонять миллионы тестов на каждый PR. Спойлер: написали собственный анализатор измененных файлов, на основе которого запускаются только нужные тесты. Мне тема интересна, потому что в топтале (когда я там работал), тесты гонялись полчаса в 60+ потоков. А для решения похожей проблемы для подобной проблемы использовались сети петри.
Текст начинается с описания проблемы: 50к сборок в неделю, 1.2 миллиона тестов, каждый раз гонять такое количество тестов возможности нет. Для решения проблемы в компании решили построить граф зависимостей, основанный на том, какие файлы вызываются во время прогона тестов (единственный способ для руби из-за «динамичности»). Сделали это с помощью библиотеки на с++, которая перехватывает «открытые» файлы на уровне ОС. Далее описываются корнер кейсы: что делать с тестами, которые только ищут файлы, что делать с областью видимости, как работает планировщик и выбирает тесты для нового кода. В конце описывается, где хранится мета по тестам (спойлер: в монге) и как хранятся «релизы».
#how_it_works #testing
—————————————
Математический анализ для разработчика: что действительно нужно понимать
В институте проходил и матанализ и линал, в реальной жизни пригодился только линал (матрицы, вектора и пересечения плоскостей). А вот с матанализом не срослось, мозги вправило, но неопределенные интегралы, градиенты и любые эпсилоны больше нуля так и остались воспоминанем. Статья выше — попытка предположить, где абстракции из матанализа могут помочь в анализе кода.
Так, автор начинает с области видимости функции. В качестве примера используется функция 1/x, которая не определена в точке 0, что приводит к ошибкам. Далее рассказывается о пределах, который привязывается к bigO. После рассматривается непрерывность и производные. Причем производная привязывается к определению «скорости» роста метрик (latency в случае текста). Далее рассматривается приближения и разложения Тейлора (когда сложная функция раскладывается на бесконечную сумму степенных функций) и многомерный анализ. Хоть текст написан нейронкой (уверен на 90%), статья дает повод подумать о том, где и как использовать абстрактные понятия в работе.
#math
—————————————
How to Pick a Database for Your System \(Without Guessing\)
Еще одна статья о том, как выбирать базу данных, на основе требуемых свойств. В отличии от других статей, упоминавшихся в канале, автор решил выбирать по PACELC, а не CAP. Хотя текст и начинается с объяснения CAP теоремы, автор приходит к обсуждению ситуации, при которой availability и consistency не достижимы одновременно. Благодаря этому происходит переход к PACELC. А после показывается как выбирать между 6 бд (упоминается кассандра, монга, постгрес, редис, динамоДБ и cockroachDB). Для этого автор предлагает в основе выбора использовать характеристики из PACELC и вид бд. А в качестве дополнительных критериев — internal mechanisms и юзкейсы каждой из бд.
#db | 2 174 |
| 7 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Instacart Built a Search for Billions of Products
Статья от компании instacart (аналог купера), в которой рассказывается о том, как решалась проблема поиска. Идея в том, что люди по разному ищут продукты. Запросы выглядят как «здоровые продукты», «соус для пасты 227г» и так далее. При этом, результат семантического поиска и поиска по ключевым словам должен соответствовать ожиданиям. Для этого, в компании, решили сделать два параллельных способа поиска, о чем в статье рассказывается.
Текст начинается с описания проблемы с параллельными флоу поиска. Причем, особенность поиска в том, что товары быстро появляются и также быстро «пропадают» со склада. Для этого ввели два параметра для оценки поиска — полнота и точность. Далее описывается, почему отказались от elasticsearch (переиндексация на изменения подвела) и как переезжали в постгрес. Следующий этап — добавление семантического поиска с помощью FAISS, который заменили на pgvector. В конце найдете информацию о проблемах подхода и рассуждения о скейлинге поиска.
#how_it_works #search
—————————————
Going Critical
С начала этого года разбираюсь в network science, поэтому сегодняшняя статья по теме. Текст выше о диффузиях в сетях, т.е. о том, как «информация» распределяется в сети (пожары, мемы в интернете, сплетни, вирусы и так далее). Причем статья интерактивная, что редкость для подобных текстов. А если думаете зачем читать о сетях — подобным образом можно симулировать отказы в software systems.
Начинается текст с создания «простой» модели в виде сети 7х7, в центре которой «зараженная» нода. При этом, «заражение» происходит с 100% вероятностью для заражений. Далее вводится понятие SIR model, которая состоит из нод в трех состояниях (восприимчивый, зараженный, удаленный). Но такая модель не симулирует ситуации, когда «зараженная» нода перестает быть зараженной и становится снова восприимчивой. В таких случаях помогает SIS simulation (вместо удаления, нода снова становится восприимчивой). Далее рассказывается о critical threshold, точке «перелома» между субкритической и сверхкритической сетью. Также рассказывается о том, как симулируются «заражения» в разных частях сети, иммунитеты у нод, влияние degree (количество связей у ноды, причем, через degree можно «симулировать» города). Ближе к концу найдете примеры симуляции «знаний». А в конце автор рассматривает feedback loop между технологиями и знаниями (знания создают технологии, которые увеличивают знания).
#network_science
—————————————
The Map of System Topologies
Текст выше — не статья в привычном смысле, скорее это попытка систематизировать архитектурные стили и паттерны вокруг структуры кода. Т.е. автор раскидал паттерны на плоскости, в результате чего получил пять «регионов», о которых и рассказывается в статье.
В начале текста описывается методология, которой придерживался автор. Так предлагается делить паттерны на техническое разделение (слои), бизнес разделение (сервисы) и шардирование. В результате чего, от шардирования пришлось отказаться, как и от экзотики (в итоге я насчитал 40 паттернов). Далее, автор выделяет пять групп:
- Monolithic, система целиком — один компонент;
- Layered, система делится технически на слои;
- Services, система делится по бизнес функциям;
- Fragmented systems, система состоит из множества мелких частей;
- Plugins, система состоит из cohesive core и модулей.
В самом тексте подробно описывается каждая группа, причем с разбивкой на виды. Так монолиты бывают с плагинами, с auxiliary layers и так далее. А в конце найдете выводы автора по топологии.
#patterns | 2 128 |
| 8 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Why Root Cause Analysis doesn't work in Complex Systems
Главная идея Root Cause Analysis — у каждой проблемы существует причина. Поймете причину — проблема больше не повториться. Звучит логично, но для «сложных» систем причины не явно связаны между собой, о чем рассказывает автор в статье выше.
Текст начинается с объяснения идей и подходов из Root Cause Analysis. Тут найдете упоминание диаграмм Исикавы (если видели диаграммы в виде скелета рыбы — это оно). А также описываются «5 why?» и другие методы. Далее описываются недостатки RCA: наличие проблем возникающих из суммы причин, а RCA в такие проблемы не умеет. Эта мысль раскрывается через feedback loops, где изменения в одном месте, усиливает/ослабляет эффекты в других частях системы.
В качестве альтернативного подхода, к анализу проблем, автор предлагает рассмотреть теорию ограничений (которую автор называет протосистемным подходом), flow diagrams и карты feedback loops. А в последней части текста автор предлагает 3 подхода к улучшающему вмешательству (PDSA и эксперименты)
#system_analysis #system_thinking
—————————————
Anti-patterns in event modelling - Passive-Aggressive Events
Отсутствие событий — ситуация, с которой сталкиваюсь в каждом первом проекте, где реализуют асинхронную коммуникацию. Под «отсутствием событий» подразумевается то, что сообщения, которые передаются либо являются данными (UserEvent), либо командами (CalculatePrice), а не событием (фактом того, что что-то произошло). Статья выше о «скрытых» командах, т.е. «событиях», которые автор называет пассивно-агрессивными.
Начинает автор с аналогий из реального мира, где встречается пассивно-агрессивный тон. Далее подводится идея, что подобный тон в событиях говорит о «скрытых командах», т.е. сообщение передает информацию, но ждет, что будет что-то сделано. Подобное поведение, автор, сократил до следующей фразы: «я свою работу выполнил, теперь твоя очередь». Далее возникает утверждение, что если передаем команду, а не событие, то придется делать синхронный вызов. На что приводятся мысли Сэма Ньюмана (написал книгу о микросервисах), что синхронная от асинхронной коммуникации отличается только блокировкой. После чего появляется еще один вид сообщений — документ (если курсы проходили, то это репликация). Ну и в конце рассказывается где использовать события, команды и документы.
#event_driven
—————————————
Why scrum is stressing you out
Модели жизненного цикла принято критиковать за то, что модели перестали быть тем, что изначально закладывали авторы. Такая судьба постигла waterfall, аджайл и другие подходы. По ссылке выше, автор решил описать собственные мысли, почему скрам вызывает столько стресса. Важный момент: в тексте описывается не «каноничный» скрам, а то, что сейчас называют скрамом.
В тексте найдете четыре причины почему скрам вызывает стресс:
- спринты не кончаются. Т.е. нет периодов нагрузки и отдыха, как в том же waterfall;
- отсутствие контроля у команд с какой скоростью надо деливерить и работать;
- игнорирование подготовительной работы (обдумывание, обучение, отдых, рефакторинг и так далее);
- создание scrumfall, гибрида scrum со спринтами и нагрузки из waterfall в «важный» дедлайн (релиза).
Русский перевод
#ppl_managment | 2 099 |
| 9 | Запустился шестой поток курса по анализу систем и принятию технических решений, старт 20 мая
В течение месяца будем учиться анализировать системы — определять элементы, связи и свойства (как системы, так и элементов). А благодаря анализу научимся обоснованно выбирать наиболее подходящее техническое решение. Если ждете выбор и работу с конкретными технологиями, подготовку к aws сертификации или подготовку к прохождению system design interview — курс не поможет. Вместо этого, акцент делается на мышлении, идеях, концепциях и как все складывается в одну картину.
Что будет:
- Работа с требованиями и стейкхолдерами;
- Взрослый поиск элементов, основанный на бизнес стратегии (и зачем на самом деле нужен DDD);
- Работа с характеристиками (их еще не функциональными требованиями или quality attributes называют) и внешними ограничениями;
- Принятие решений по структуре, видам баз данных, коммуникаций и паттернам, основываясь на характеристиках;
- Обсуждение способов описания архитектурных решений и почему важно отвечать на вопрос «что надо сделать?», вместо «как это делать?»;
- Как взаимодействовать с командой, основываясь на подобном описании;
- Урок, целиком связанный с распределенными системами (добавление, вынос, рефакторинг сервисов, фикс энтити сервисов и так далее);
- Отсылки на диско элизиум, заумь о космонавтике и бизнес эксплуатирующий кошачьи удовольствия;
Курс не сделает из вас солюшен архитектора, тем более за месяц, но поможет собрать информацию вокруг темы в кучу и ответит на вопрос, почему «зависит от контекста» единственный вариант принятия решений. А если сталкивайтесь с LLM, курс поможет собрать необходимый контекст, что бы нейронка меньше фигни вайбкодила.
При этом, я рассчитываю, что контента хватит на год самостоятельной работы и изучения (со всеми доп материалами и прочим). Получилось 5 уроков, в каждом - герой анализирует одну и ту же систему, используя больше и больше инструментов. При этом, каждый раз оказывается, что ситуация меняется, из-за чего приходится переосмыслить подходы и инструменты. В итоге получим оптимальную для реализации системы, удовлетворяющую всем требованиям бизнеса и других заинтересованных лиц.
Ну и самое удивительное для такого интроверта как я – p2p проверка домашек идеально вписалась в курс (это когда вам приходит N чужих домашек на проверку). Благодаря этому ученики прокачали насмотренность (что отмечалось как один из главных плюсов курса), вместо того, чтобы вариться соло (хоть и были ситуации, когда на проверку забивали).
Полная программа и половина первого урока — на странице курса. Начало 20 мая, а до 30 апреля действует промокод SA6PEPE на 10% скидки.
Eсли ждете коммуникации систем — курс будет где-то в конце 2026 года, можете записаться в вейтлист. | 0 |
| 10 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Keeping a Postgres queue healthy
Статьи, связанные с реализацией очередей на постгресе, упоминались в канале еще шесть лет назад. Сегодня текст, который фокусируется на перфомансе очередей в инстансе постгреса, где содержатся основные данные.
Начинается текст с описания проблемы: берем пг, в него пихаем очередь, а что делать с нагрузкой в таком случае не понятно. Причем, паттерн поведения в очереди строится вокруг того, что данные пишутся, единоразово читаются. А после, старые данные, необходимо удалить, чтобы база не распухала. Вот тут и начинается проблема, так как появляются dead tuples, т.е. записи, которые для базы «удалены» (запросы игнорируют данные), но в реальности, данные удалятся только после VACUUM. Далее приводится пример очереди jobs, состоящей из 4 колонок (pk, json, status и run_at). И подробно объясняется проблема dead tuples, которую автор симулирует. После объясняется работа вакуума и приводится список решений, которые помогут в удалении «мертвых» данных.
#psql
—————————————
The Math of Why You Can't Focus at Work
В пятничных ссылках редко встречаются тексты связанные с продуктивностью. Связанно это с тем, что 99% подобных статей либо «сео» статьи, либо банальщина вокруг очередной настройки obsidian или todoist. Текст выше крутится вокруг относительно «капитанской» идеи: «меньше прерывания, больше сфокусированной работы, больше удовлетворения работой». Но вы читаете эту подводку из-за того, что автор решил доказать это утверждение используя мат модель, что редкость для подобных статей.
Начинается статья с постановки проблемы, связанной с прерываниями. Для этого показывается «хороший» день, когда прерываний мало и в наличии 2 блока на 2+ часа для «глубокой» работы. А также показывается «плохой» день, где времени на «глубокую» работу — меньше двух часов в сумме. Из этого, автор выделяет три главных фактора «хорошего» дня: сколько раз в час прерывают, сколько времени требуется на восстановление концентрации, минимальная продолжительность блока осмысленной работы. И тут же появляется мат модель, которую автор визуализируют. А самое интересное начинается, когда берутся данные о количестве прерываний из исследований, а в визуализации нет времени на работу. Во второй части статьи автор делится советами, как улучшить ситуацию (с проверкой через модель).
#productivity
—————————————
Какой минимум симптомов нужен врачу для постановки диагноза
Не смотрите на название статьи, текст о теории грубых множеств и о том, как определить «значимые» факторы из выборки. Просто для примера автор решил определить важные симптомы для определения диагноза болезни.
Текст начинается с истории появления теории грубых множеств, основанной на теориях вероятности и нечеткой логике. А главная идея вертится вокруг согласованности, т.е. ситуации, когда нет объектов с одинаковыми признаками или симптомами, но разными «диагнозами». Причем, размер выборки не важен, даже 10 строк в таблице хватит. Кроме согласованности, придется еще разобраться с вектором значимости и суперредуктом и редуктом. Далее, на примере симптомов и болезни, описывается алгоритм поиска важных признаков. А в конце приводится пример кода на julia.
Если говорить о применимости теории в IT, то первое о чем подумал, когда читал текст — было бы интересно воспользоваться теорией для анализа постмортемов. Т.е. берем происшествия, выделяем признаки, после чего получаем вектор значимости для признаков. А на «важные» признаки тратим больше ресурса на проверку в релизах и ежедневной работе.
#data_analysis | 0 |
| 11 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
The Myth of Individual Excellence: Why Systems Matter More Than Talent
Addendum: The Myth of Individual Excellence
Сегодня две философские статьи по цене одной. Обе раскрывают идею: «хотите эффективности — думайте об изменении системы».
Автор начинает с вопроса «почему компании с ресурсом так плохо достигают результатов?», что приводит к мифу индивидуализма. Точнее к тому, что результаты достигаются благодаря таланту, интелекту, труду и так далее. Но по итогу, рассуждения приводят к тому, что ответ сложнее и эффективность, в первую очередь, зависит от конкретной системы. Т.е. если в школе учитель будет тратить 90% времени на заполнение документов и 10% на обучение, то эффективность обучения будет хуже, чем в школе, где пропорция обратная. В случае эффективности рабочих команд и технических систем — проблемы аналогичны. По этой же причине, со слов автора, изменения проваливаются, так как не учитывают структуры и условия систем, а фокусируются на отдельных людях.
Вторая статья появилась из-за недопонимания идеи из первого текста. И во второй попытке, автор, пытается глубже раскрыть связь эффективности и системы через три примера из жизни. Из интересного: понравилась идея, что противопоставлением individual-as-cause будет method-and-system-as-cause, а не коллектив.
#system
—————————————
Как построить банк на 130 миллионов клиентов с помощью Clojure
Сложно придумать подводку к тексту, поэтому как есть. Автор рассказывает внутрянку бразильского банка Nubank, которые выбрали clojure с datomic и по итогу стали крупным бизнесом (не факт, что благодаря технической системе).
Начинается статья с исторической справки появления банка (в бразилии была «монополия» пяти банков, ставки по кредиткам 450% и население не пользовалось банками). В итоге, сделали кредитку, проект выстрелил и овнеры остались довольны. Дальше начинаются технические детали: первое техническое решение связано с выбором datomic (иммутабельная бд), из-за чего выбрали clojure как язык для бекенда (как единственный вариант). В результате такого выбора, в 2020 году, банк выкупил компанию Рича Хики, о чьих идеях автор рассказывает. Далее описывается что такое datalog (подмножество пролога, которое с бд работает) и как в datalog упрощены рекурсивные вызовы.
#clojure
—————————————
Designing the Unknown
Одно из моих хобби — изучать абстрактные концепции. Сегодня речь пойдет о concept-knowledge theory, которую придумали в 2003 году для работы с инновациями. Появилась концепция из-за того, что люди научились работать с четко определенными проблемами, а с неизвестными штуками возникли проблемы. И главная идея оказалась в вопросе: «а что если начать изучать проблемы как развивающиеся во времени». А по ссылке выше найдете вводную информацию в c-k theory.
Текст начинается с объяснения причин появления c-k theory. А дальше описываются главная идея — выделяют два пространства, концепций и знаний. По этой логике, работа с инновациями сводится к четырем шагам:
- k->c. Благодаря знаниям появляется концепция;
- c->c. Концепция усложняется и развивается;
- c->k. Изучая концепцию появляются новые знания;
- k->k. Знания, полученные из концепции, развиваются, превращаясь в новые знания, которые создают новые концепции.
Во второй части автор описывает плюсы подхода и приводит пять примеров, когда использование c-k помогло в решении проблем. Главный минус текста — слишком абстрактно и практическая применимость сводится к «нарисуйте овал, который превратиться в сову».
#c_k_theory #rnd | 0 |
| 12 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Emergent properties
Если верить теории систем, отличие между «связанными элементами» и «системы» — в наличии эмерджентных свойств. Это такие свойства, которые образуются только во время работы системы целиком, т.е. свойства, которых нет у отдельных элементов системы. Любимый пример: песочные часы умеют отсчитывать время, а песок, стекло и подставка по отдельности — нет. При этом, свойства могут быть как «хорошие» (отсчет времени), так и «плохие» (шатдауны, которые strong emergence). В статье выше, автор, решил разобраться в эмерджентности чтобы доказать, что llm не только генераторы токенов.
Текст начинается с понятия редукционизма (чтобы понять систему нужно понять элементы системы), где возникают resultant свойства. Подход работает ровно до момента, когда свойства появляются как результат действия и тут автор переходит к эмерджентности (отдельно отмечу пример с «креативными» статуями). После чего появляются понятия времени и «неизвестного неизвестного». Дальше объясняются виды эмерджентности (strong и weak, еще встречается simple, не описанный в статье). Отдельно понравилось, что рассказывается о характеристиках систем с эмерджентными свойствами. Ну и в конце подвязывается LLM и наличие у модели эмерджентных свойств (до тех пор, пока не поймем «магию» работы).
#system_theory
—————————————
Pace Layering
Сразу предупреждаю, текст и тема не формат ссылок. Но концепция pece layering, описанная в ссылке выше, помогает взглянуть на тренды и технологии под другим углом. Ну и я редко слышу об этой концепции от других людей, что повлияло на добавление ссылки.
Концепция предложена Stewart Brand (футуролог), во время работы над развитием зданий (каждый раз поражаюсь количеству идей из строительства, которые не ушли в другие области). Идея в том, что разные части здания развиваются с разной скоростью и «сдвигаются» относительно друг друга. Выделяют 6 слоев: fashion (меняется быстрее остальных), commerce, infrastructure, governance, culture и nature (меняется медленнее остальных). Слои обмениваются информацией между собой, благодаря чему верхние слои «влияют» на нижние. Так, благодаря двум энтузиастам появился markdown, который стал «стандартом» (в тексте найдете пример ежегодным обновлением авто благодаря моде). В обратную сторону обмен тоже присутствует: так без нижних слоев не будут работать слои выше (прибыль от научных исследований ждать не выгодно, поэтому государство спасает, а без науки коммерция не продаст новую технологию).
В конце добавлю, что иногда полезно остановиться и подумать в каком слое происходят изменения. И как эти изменения влияют на слой, в котором вы крутитесь.
#changes
—————————————
Building a graph database using kafka
Разбавлю абстрактные тексты статей от автора, который любит делать базы данных поверх кафки. Сегодня текст о том, как взяв кафку получить графовую, document и wide column базы данных.
На самом деле, автор читерит и вместо реализации с нуля, берется HGraphDB, которая работает поверх клиента к HBase. А так как никто не мешает реализовать идентичный HBase API в другой бд, то задача сводится к созданию wide column store поверх кафки. Что автор и сделал, взяв за основу KCache (об этой k-v бд упоминалось в ссылках ранее). А что бы реализовать document DB, берется HDocDB — document DB базой поверх HBase (а реализация API через кафку уже написана). В конце автор описывает эксперимент с JanusGraph, который также может работать через HBase. Но вместо HBase, автор интегрирует KCache в JanusGraph (janus поддерживает k-v через BerkeleyDB).
#kafka | 0 |
| 13 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Datadog Built a Custom Database to Ingest Billions of Metrics Per Second
Очередная статья от компании, в которой описывается решение специфической проблемы. Сегодня это datadog (мониторинг приложений), который столкнулся с проблемой хранения и управления данными. Для чего создали monocle — time series storage для хранения реалтайм метрик.
Текст стартует с описания структуры платформы метрик, которая отвечает за сбор, обработку и отображение информации по метрикам. Главная идея в том, что есть два места, где метрики храниться могут, либо в долгосрок, либо для real-time штук. Далее описывается, что надо хранить для реалтайма — данные (дата + значение) и метаданные (теги). И в этот момент появляется кафка, в которую сначала попадают все данные, а после раскидываются по инстансам базы, которую написали в компании. Так как решение кастомное, то и схему хранения данных переписали на map вида «хеш метаданных -> список пар (timestamp, value)», что позволило хранить данные в одном месте. В конце статьи найдете описание того, как бд работает и как происходит параллелизация.
#hot_it_works #data_managment
—————————————
Holistic Engineering
Так как software systems — социо-технические (код и люди которые работают с кодом), то заниматься только технической составляющей не выйдет. Так, «идеальный» с точки зрения ТТМ код, приводит к задержкам в релизах из-за отсутствия навыков или иными предпочтением у разработчиков. Поэтому, при проектировании решений придется учитывать еще и социальный аспект, о чем рассказывает ссылка выше.
Текст начинается с обсуждения трех ситуаций, в которых «социо» влияет на «техническое»:
- над одной частью системы работают разные люди со своими целями, знаниями и мотивацией;
- разные вещи называют одним словом (пример — user, который и клиент и админ и кто угодно);
- когда для решения задачи, не к месту, вкладываются знания из прочитанных книг за последние 3 года.
Во второй части описывается холистический подход к проектированию, в котором придется еще учитывать не технические факторы, которые автором делятся на внешние (тренды, события и так далее) и внутренние (сотрудники, орг структура, системы вознаграждений). В конце найдете четыре примера использования холистического подхода для решения проблем.
#socio_tech_systems
—————————————
Rewilding Software Engineering
Создатель ворлди карт (Саймон Вордли) пишет новую книгу онлайн. Книга называется Rewilding Software Engineering и пока публично доступно шесть глав. Сегодня ссылка на шестую главу, где рассматриваются мифы вокруг software разработки. Сразу предупрежу — «статья» прямо лонгрид лонгрид, поэтому, вместо краткого пересказа — опишу что жать от текста.
В главе рассматривается восемь мифов, которые автор пытается развенчать (в скобках его позиция):
- Software engineering только о том, чтобы функционал реализовывать (на самом деле о структуре);
- Технический рефакторинг не нужен бизнесу (нужен, так как знания о бизнесе, из голов сотрудников, утекли в код);
- Software engineering — инженерия (нет и для объяснения мифа используется тестирование);
- LLM заменят разработчиков (тут о переосмыслении использования LLM и трансформации разработки в инженерию);
- Архитекторы принимают решения (решение принимает тот, кто делает, а не кто придумывает)
- Жить с легаси тяжело (нет, если инвестируете в инженерию);
- Не технические люди не могут понять код (с инструментами могут);
- Тех долг (идея в том, что причина тех долга в скалярных величинах, например KPI, которые жить мешают).
#software_engineering | 0 |
| 14 | Пятничное чтиво
Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
How Netflix Tudum Supports 20 Million Users With CQRS
Очередной текст о том, как работает netflix. Сегодня статья фокусируется на Tudum — платформе для бекстейдж видео, интервью и прочем подобном. Изначально проект делался по заветам CQRS, деля запись и чтение. Но спустя время возникли проблемы с задержками между сохранением материала и его предпросмотром, инфраструктурной стоимостью и затратами времени на создание постов. Текст выше рассказывает о эволюции сервиса.
Начинается статья с описания изначальной структуры: вызываем команды, асинхронно (с eventual consistency) реплицируем данные в read model. Важный момент, что в write model хранится метаинформация, при этом, в read model, данные уже подготовлены для пользователей и без лишней информации. Далее описываются проблемы (процессы, кеш, eventual consistency, апдейты и так далее). В качестве решения взяли RAW Hollow — compressed, distributed, in-memory object store, вместо кафки (в тексте найдете основные свойства базы).
#hot_it_works #cqrs
—————————————
What We Learned Migrating to a Pub/Sub Architecture
Еще одна статья о том, как в компании решались технические проблемы. В данной статье описывается ритейл платформа, с 4к+ рпс. Проблема оказалась в монолитном решении, которое переписали на микросервисы с асинхронной коммуникацией (конечно же с кафкой).
Текст начинается с объяснения мотивации миграции на сервисы. Тут про масштабируемость, отказоустойчивость и проблемы с ТТМ. В начале, в компании, описали «основные» события и сделали драфтовую модель новой структуры, для масштабирования думали горизонтально скейлить кафку. Далее описывается новая структура коммуникаций, где взяли каждый элемент продюсит собственные доменные события с версиями и подписывается на то, что нужно для работы. После описывается как скейлили кафку через партиции (очевидная история с количеством партишенов == количеству консьюмеров в групе), плюсом подумали об ack. В части моделирования событий описывается опыт версионирования и использования schema registry. А для reliability используют DLQ и ретраи. Понравилось, что есть секция с обсервабилити, где описывают как логируют, какие метрики используют и упоминают correlation. В конце найдете выводы и советы, если захотите подобное разворачивать у себя.
#how_it_works #async_communications
—————————————
Surviving the 300,000 Request Spike: How I Built a Self-Healing Rate Limiter
В случае специфического контекста «стандартные» решения могут только навредить. Текст выше описывает такой случай. Идея в том, что автор решил взять готовый rate limiting и на нагрузке в 30к возникла проблема с работоспособностью системы. В результате пришлось писать собственную реализацию, которая выдерживает 55к рпс.
Начинается статья с объяснения работы Token Bucket алгоритма (на каждый запрос проверяем наличие токена в сторе), который используется по дефолту для реализации rate limiting. Причем, реализуется алгоритм поверх redis и скриптов с lua, которые нужны для исправления race condition. И для высокого рпс, большая часть времени запроса проходит в redis. В качестве решения, автор предлагает собственный подход, основанный на distributed mesh и трех уровнях (клиентском, агрегаторах и контроллерах). А что бы rate limiter заработал, вводится понятие drop ratio, которое говорит на сколько необходимо уменьшить текущий трафик. Кроме этого, в статье найдете расчеты и минусы подхода.
#high_load | 0 |
