Ожидает прочтения

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

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

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

SQL query optimization: a comprehensive developer’s guide

Название статьи говорит само за себя. По ссылке найдете 18 советов по оптимизации как SELECT, так и INSERT и DELETE запросов в реляционных базах. Часть советов подойдет под postgreSQL и mySQL.

Советы делятся на три группы. Так советы вокруг вставки включают следующий список: напоминание о EXPLAIN, работа с индексами, куча советов по джоинам (как типизации, функциям и избеганию лишних джоинов). Кроме этого авторы описывают как использовать subquery, пагинацию, GROUP и window functions. И что делать, что бы возвращать меньше данных, либо использовать меньше данных для селекта.

В случае INSERT найдете три главных совета: посмотреть в сторону специализированных функций (например COPY), отказ от не нужных индексов и оптимизация возвращаемого результата. А для DELETE найдете советы связанные с TRUNCATE, партициями, разбивкой транзакций на чанки и использование фильтрации, вместо удаления данных.

Каждый совет делится на три части: как применить совет, какие риски или потенциальные проблемы в решении и «золотое правило» использования совета. Если плаваете в базах — освежить знания стоит.

#sql

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

How to build MongoDB Event Store

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

Начинается текст с объяснения что такое event sourcing и event store (радует, что есть ссылка, которая объясняет в чем разница между event sourcing и event streaming). Дальше описываются базовые требования к event store связанные с хранением и получением данных. Дальше описывается, как хранить события в документах, причем не одно событие в одном документе, а стрим (набор событий) в одном документе. После показывается пример реализации подобного храниения стримов в монге и как добиться optimistic concurrency. В конце найдете список трейдофов, в которые попали как размеры документов в монге (до 16 мегабайт), так и проблемы с созданием read model.

#event_sourcing #event_store

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

How Amazon S3 Stores 350 Trillion Objects with 11 Nines of Durability

Очередная статья о том, как в компании решали проблемы. Сегодня это aws, где оптимизировали работу S3 для поддержки 99,999999999% SLA (11 девяток). При этом, не ждите конкретных советов, статья скорее описание того, как работает сервис в общем и как дизайн решения привели к нужным свойствам.

Статья начинается с объяснения того, что такое s3 (object storage service) и какие свойства у сервиса сейчас: куча девяток в durability, разные виды стораджей, автоматический скейл и так далее. Далее описываются вехи «эволюции» сервиса: от рождения в 2006 году, добавление регионов в 2010, улучшение перформанса в 2015, оптимизация для AI и аналитики в 2018 и так далее. При этом, каждый этап эволюции занесен в одну из двух фаз, в которой требовались уникальные свойства от сервиса. После описывается архитектура сервиса, где найдете информацию о том, как обрабатываются запросы, индексируются и хранятся данные и происходят оптимизации. После начинается блок с объяснением того, как данные из запроса попадают в s3 и как работает индекс.

#how_it_works #durability

Event-Driven by Oskar Dudycz

How to review a software architecture diagram Knowing how to make a good diagram is one thing, and reviewing a diagram is another. While you can fill something is off, it is still useful to have a checklist for documentation review. Simon Brown shares it in his post of a 5 years ago. #documentation

I see hundreds of software architecture diagrams every year, predominantly through my software…

1000 Models at Instagram Instagram definitely runs an ML model to provide you with recommendations, but there is a thousand more cases when models are involved like rating comments, suggesting tagged people and others. Running this number of models gets you challenged from the quality, speed and underlying infrastructure perspective. Luckily, instagram engineers share their journey. #ml #performance #scalability

In this post, we explore how Instagram has successfully scaled its algorithm to include over 1000 ML models without sacrificing recommendation quality or reliability.  We delve into the intricacies…

Migrating to Postgres Sean Callahan shared his story of migrating the CockroachDB to PostgreSQL with a single script ending up saving more than $100,000 annually and discovering dozens of queries which were easy to replace on the pure PostgreSQL, than in CockroachDB due to difference in query planners and available tooling. #postgresql #db #casestudy

Since early 2022, Motion was on CockroachDB. Cockroach has many qualities going for it: effortless horizontal scaling, especially when…

Model Once, Represent Anywhere Netflix introduces UDA (Unified Data Architecture), a cutting‑edge, knowledge-graph–based framework designed to standardize and connect domain concepts—like actor and movie—across its sprawling content ecosystem. By bridging conceptual definitions with technical implementations, UDA eliminates semantic drift, enhances data quality, fosters discovery across systems, and accelerates development—especially vital in large, heterogeneous microservices landscapes. #datamodelling

Introducing UDA, the knowledge-graph-based architecture that translates conceptual domain models into consistent schemas and data…

Modulith Architecture Example Autotrader is a marketplace of used cars and spare parts. Emina from their Engineer team shares how the Modulith approach helps them dealing with the complexity of having 70+ integrations while moving fast and reliablty. The post has a follow up with the pros/cons analysis. #monolith #architecture

How our team applied clean principles using the modulith architecture paradigm — what it is, why we chose it and how we implemented it

My Dos and DON’Ts of Software Architecture 🍼 Nice checklist of the recommended actions and known anti-patterns when working on the architecture problems. Making decisions, communicating tradeoffs, recognizing misunderstandings - grab a list. #softwarearchitecture

Photo by Pixabay on Pexels

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

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

————————————— Optimistic Concurrency Control: Alice and Bob Couldn’t Sit Together

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

Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.

#sql #optimistic_lock

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

Simple tips for managing any project.

Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:

• понимание пользователей и их нужд;
• определение capabilities, которые закрывают нужды пользователей;
• понимание развития компонентов, которые связаны с capabilities;
• менеджмент компонентов.

Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.

В конце дописаны ответы на некоторые вопросы. Важно отметить, что примеры в тексте показаны только через карты, но заменив карты на поддомены и контексты из DDD, смысл не поменяется.

#management #product

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

How Stripe Processed $1 Trillion in Payments with Zero Downtime

Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.

Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью

#how_it_works #sharding

Alice and Bob want to go to the cinema together and sit next to each other. However, each will book…

Применимая в реальной работе модификация RICE

За последнее время уже с несколькими людьми из разных компаний обсуждал, как я модифицировал метод приоритизации RICE, и все говорили: «Да! У нас тоже все эти ситуации и проблемы есть!»

Да кто такой этот ваш RICE? Длинный ответ можно прочитать, например, тут https://productstar.ru/rice.

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

Критерии простые (как я люблю):

• Reach (охват) – количество пользователей, которых затронет предлагаемая фича.
• Impact (влияние) – в некоторой мере оценочное суждение, насколько важна и нужна фича, насколько сильно она повлияет на пользователей.
• Confidence (уверенность) – степень уверенности в двух предыдущих оценках. Одно дело – вы подробный рисерч провели, а другое – вы пальцем в небо ткнули на основании своих ощущений.
• Effort (усилия) – трудозатраты на выполнение.

В теории это всё. Мол, так делайте, и спина болеть не будет.

Но на практике работы в разных командах и компаниях, где у моих команд было много заказчиков, я вывел еще два дополнительных критерия.

Коэффициент обманщика (пишу вам тут литературно приемлемым языком) Помните сказку про мальчика, который кричал «Волки!»?

Так нередко встречается и в жизни. Есть заказчики, которые говорят: «Это точно очень надо», ты им делаешь, а они потом не пользуются. Или те, кто говорит: «Очень срочно!!!», ты делаешь, а они только откроют посмотреть недели через две-три. Или те, кто говорит: «Это блокер! Без этого нельзя продолжать работу!!!», а при детальном рассмотрении оказывается, что просто у пары людей из десятков что-то медленно работает и надо ждать дольше, чем обычно.

Все примеры – это настоящие истории. А то вдруг подумаете, что это я сочинил для красного словца, ведь кто будет в здравом уме обманывать и драматизировать?)

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

Коэффициент офигевшего А еще бывает порой так, что вы посчитали все коэффициенты и задача объективно не сильно важна. А иногда даже просто от неё 0 профита. НО эту задачу хочет видеть какой-нибудь высокий/важный/громкий руководитель. И тогда у вас появляется сильно повышающий множитель.

Примеры тут тоже видел разные:

• На А/Б тестировании проверили, что автогенеренные картинки и крафтовые имеют одну и ту же кликабельность и один и тот же профит. Но у важного руководителя, видимо, нет другой важной работы, он отсматривает каждую картиночку и настаивает, чтобы было «сексуально» (я не выдумываю, это цитата). В результате люди будут кратно тратить больше времени и сил, чтобы босс был доволен, что у стрелочки не прямой хвостик, а волнистый.
• Очередная пассия начальника придумала (ни с кем не обсудив, конечно) и выдала в свою соцсеть, что компания сделает какой-то ивент. Теперь у отдела маркетинга новые планы 🙂
• Один руководитель хочет положить себе в резюме недостающий кусочек менеджерского пазла, и теперь у команды новый проект.

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

Но в реальной жизни не бывает объективных и отстраненных аргументов. Даже в компаниях с культурой эффективности и продуктовости. А уж в компаниях, где такой культуры нет, тем более будет человеческий фактор очень сильно выражен.

Так что, на моем опыте, RICE подойдет для 70-90% задач (я их называю политически нейтральными), но оставшиеся 10-30% будут обмазаны дополнительными понижающими и повышающими коэффициентами, и вам придется с этим смириться. Везде так. Различается только частотой и силой проявления.

Как лучше распределить время и эффективность

https://puzzlebot.top/

Многофункциональный сервис для работы с ботами, чатами и каналами в Telegram.

Replacing a cache services with a database A prominent idea seen on x and bluesky is throwing away cache in favor of a read replica. In the end databases cache some data in memory, why not leverage it? Well, there are counter-arguments to this approach and you want to know them. #performance #caching

Why do we use caches at all? Can databases fully replace them?

Scaling Postgres to the next level at OpenAI A video for a change: OpenAI share how they deal with write amplification, single point of failure and inefficient queries while using a single master setup for ChatGPT. Useful stuff with no talking about AI! #db

Presented by Bohan Zhang at PGConf.dev 2025 (https://2025.pgconf.dev)PostgreSQL serves as a cornerstone of OpenAI’s backend infrastructure, powering many of …

Architecture Advise Process Typically the architecture decisions are made by someone with “Architect” in the title. But you either get an ivory tower architect distant from the reality or an ultimate bottleneck in the process. Andrew Harmel-Law recommends to use Architecture Advisory Process decentralising making the architecture decisions. How exactly? Find in his own article on Martin Fowler’s blog. Btw, the interview with Andrew Harmel-Law early access is already on my Patreon. #adr #architecturedecisions

Scaling architecture through a structured series of conversations

https://habr.com/ru/companies/beeline_cloud/articles/881848/

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

https://medium.com/@iamalvisng/second-system-syndrome-in-software-e5b942e6866b

Lessons from History and Modern Cases

https://www.youtube.com/live/FTKdHKjzdx0?t=5804s

Selectel Day Off 2025 — IT-фестиваль против выгоранияhttps://dayoff.selectel.ru/2025Задать вопросы спикерам и выиграть Тирекса за лучший вопрос можно через ф…

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

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

————————————— Optimistic Concurrency Control: Alice and Bob Couldn’t Sit Together

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

Статья крутиться вокруг одного примера: Алиса и Боб хотят купить билеты в кино. При этом, сделать это так, что бы сидеть рядом. Дальше Боб делает транзакцию, в которой проверяет наличие двух мест рядом и ждет, пока Алиса забронирует место, чтобы самому забронировать место рядом (транзакция все еще висит). Но в этот момент появляется Mallory, которая также хочет забронировать место (но не может из-за транзакции Боба). Дальше Боб с Алисой делают UPDATE для бронирования места и коммитят транзакцию. И по итогу, Mallory окажется без билета, а Боб с Алисой пойдут в кино. А во второй части показано как будет работать optimistic lock для aws Aurora DSQL.

#sql #optimistic_lock

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

Simple tips for managing any project.

Статья от Simon Wardley (это тот, кто придумал карты вордли), в которой рассказывает о базовых принципах в управлении проектами, который использует 15 лет. Для этого он рассказывает о проекте, в котором изначально выбрали не корректно элементы системы из-за чего начались проблемы. Дальше описываются шесть вопросов, которые помогут решить проблемы с проектами. Шаги похожи на то, что предлагает стратегический DDD и если шаги сгруппировать получите следующие направления:

• понимание пользователей и их нужд;
• определение capabilities, которые закрывают нужды пользователей;
• понимание развития компонентов, которые связаны с capabilities;
• менеджмент компонентов.

Дальше автор описывает проблемы, из-за которых происходят провалы. Тут найдете: проблемы с коммуникациями, mismatched expectations стейкхолдеров, проблемы с ясностью целей, проблемы с remote teams, культурными особенностями и проблемы с границами элементов.

В конце дописаны ответы на некоторые вопросы. Важно отметить, что примеры в тексте показаны только через карты, но заменив карты на поддомены и контексты из DDD, смысл не поменяется.

#management #product

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

How Stripe Processed $1 Trillion in Payments with Zero Downtime

Очередная статья из серии «как в компании X решили проблему Y». На этот раз это страйп, который обработал триллион долларов платежей за год без простоев. Изначально страйп использовал mongoDB, сначала казалось что база проще реляционной в работе. Но из-за нагрузки и количества данных оказалось, что вариант так себе. При этом шардирование монги не помогло (в тексте найдете кусок о том, как шардирование работает). В результате появилась DocDB, основанная на монге, где за хранение и извлечение отвечает монга, а за шардирование и миграции отвечает DocDB.

Дальше описывается, как работает Data Movement Platform — штука, которая помогает перемещать данные между шардами, особенно когда размер шарда выходит за допустимые пределы и нужно добавлять новый. Проблема тут не только в том, чтобы переместить информацию, но и сделать так, что бы связанные данные также переместились в нужный шард. Дальше описан полный алгоритм работы шардирования. А в конце найдете ссылку на оригинальную статью

#how_it_works #sharding

The questions you need to ask.

SQLZoo: интерактивный тренажёр по SQL

Если надоело читать теорию и хочется потрогать SQL ручками — SQLZoo станет идеальным выбором. Здесь сразу на сайте можно выполнять задания, строить запросы к реальным базам и видеть результат.

Есть пошаговые туториалы, задания на SELECT, JOIN, GROUP BY, подзапросы и задачки на логику.

Thousands of Software Engineers and Architects make impactful decisions every working day.

But the 90% of them struggle to make relevant, sustainable, justified and emotionally cold decisions. Find out top 5 challenges and how to deal with them. What is your top challenge?

#architecture #architecturedecisions

https://blog.vvsevolodovich.dev/the-top-challenges-in-making-software-architecture-decisions/

Making architecture decisions impact business, technical roadmap and the project future. It is a tricky endeavour, and here are the top 5 challenges.

Top 5 diagrams for documenting software architecture I refreshed my old article about documenting software architecture with 5 types of diagrams from C4 context ones to the use case diagrams. Find out why you need them, how to draw them and hear some feedbacks about using those diagrams. Tools recommendations included. #documentation

A revamp of an old article on the most useful diagrams to document software architecture and tools to create them.