⭐️ О канале

Привет! Меня зовут Никита Ульшин, я руководитель разработки в Positive Technologies, ex-TeamLead в Т-Банк. В этом канале я пишу обзоры материалов по system design, архитектуре высоконагруженных систем, базам данных и прочим техническим темам.

⭐️ Обо мне

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

⭐️ Почему канал так называется?

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

Из аналогии со спортом и родилось название канала. Как регулярная физкультура помогает развивать и держать в форме наше тело, так же и регулярное изучение технических материалов помогает поддерживать и подкачивать хард-скиллы.

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

⭐️ Как поддержать канал?

Если материал оказался полезным — подписывайтесь и ставьте лайки 👍. Так я буду лучше понимать ваши интересы и подбирать максимально ценные источники информации.

Ещё я буду благодарен, если вы поделитесь заинтересовавшим вас обзором со своими друзьями и коллегами. Это поможет мне развивать канал и распространять хорошие идеи.

⭐️ Навигация по каналу

#architecture@tech_fit - архитектура кода и систем
#databases@tech_fit - базы данных
#systemdesign@tech_fit - дизайн систем
#book@tech_fit - обзоры технических книг
#talk@tech_fit - обзоры публичных выступлений и подкастов

➖➖➖➖➖➖➖➖➖➖➖
// Обязательно подпишись на канал, чтобы не пропустить новые статьи

Как Figma масштабировали свою БД, часть 1

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

На выходных прочитал замечательную эпопею о том, как Figma столкнулись с проблемами роста своей БД. У них был заряженный по железу монолитный Postgresql, который всё-таки начал упираться в свои пределы.

Из интересного в статье:
➡️ Базовые тактические действия, когда БД начинает не вывозить
➡️ Почему Figma отказались от переезда на другие БД
➡️ Как инженеры Figma делали вертикальное партиционирование (вытаскивали таблицы в отдельные базы) без даунтайма (но есть нюанс)

Рекомендую к ознакомлению всем, у кого база потенциально может начать задыхаться. Будете знать, к чему готовиться 🙂

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#architecture@tech_fit #databases@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Как Figma масштабировали свою БД, часть 2

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

Во второй части рассказывается о том, как они переделали архитектуру БД и достигли (почти) бесконечного scalability:
➡️ Разделение таблиц на группы (colocations), которые объединены ключом шардирования и физическим размещением данных
➡️ Зачем инженеры Figma написали свой роутер подключений к БД
➡️ Как проверить поведение продакшн трафика до релиза в продакшн

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

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#architecture@tech_fit #databases@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Идемпотентность от А до Я

Отличная статья от Яндекса про идемпотентность. Сама по себе идемпотентность — тема непростая, и традиционно о ней вспоминают только тогда, когда что-то ломается.

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

⭐️ Интересные идеи

➡️ Идемпотентный метод API — это метод, который при повторном вызове не меняет состояние. Однако результат вызова метода может меняться. Например, методы GET, PUT и DELETE формально идемпотентны.

➡️ Для обеспечения идемпотентности применяется так называемый ключ идемпотентности — токен, сгенерированный на стороне клиента. Этот ключ предназначен для идентификации запроса на бэкенде при многократном повторении.

➡️ При работе с идемпотентностью важно учитывать не только success scenario, но и различные варианты отказов. Также не стоит забывать о ретраях, таймаутах и других паттернах защиты.

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#architecture@tech_fit #systemdesign@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Паттерны отказоустойчивой архитектуры

Замечательный доклад на тему паттернов проектирования, которые применяются для построения отказоустойчивой архитектуры. И снова мой любимый формат — история, в которой система постоянно развивается. Этот доклад я пересматривал минимум три раза, потому что он даёт хорошее понимание основ распределённых систем.

Искренне жаль, что Саше не хватило времени рассказать всё запланированное, и часть контента он пробежал галопом по Европам. Было бы очень интересно послушать полный вариант.

⭐️ Интересные идеи

➡️ Сеть может сбоить. Сервер может сбоить. База может сбоить. Всё что угодно может сбоить. Мы живём в неидеальном мире, и нужно сразу закладывать в систему возможность работать при любых обстоятельствах.

➡️ Не нужно сразу запихивать все паттерны в свою систему. Двигаться следует от простого к сложному и чётко понимать, что и почему мы делаем.

➡️ Сами по себе паттерны проектирования довольно просты, но сложно их настраивать для эффективной работы. Сколько попыток нужно заложить в Retry? Какое время устанавливать в Timeout? Какой бюджет ошибок выставить у Circuit Breaker? Это непростые вопросы, и от их правильного решения зависит эффективность паттернов.

Приятного просмотра!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#architecture@tech_fit #systemdesign@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Просто используй Postgres

Статья посвящена одной простой идее: если вы создаёте новое приложение и вам нужно персистентное хранилище, по умолчанию берите Postgres — и не парьтесь.

Большая часть статьи — это ответ на вопрос «Почему не Х?» Например, почему не Mongo, SQLite, Cassandra, Kafka и т. д.?

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

⭐️ Интересные идеи

➡️ Cassandra и Mongo довольно сложно настраивать, особенно в разрезе поиска данных. Если мы не знаем сценариев поиска, то получим целый мешок сложностей, которых можно было бы избежать с Postgres.

➡️ Valkey (он же Redis на стероидах) больше подходит для кеширования, но его возможности масштабирования вполне позволяют организовать на его основе персистентное хранилище. Однако RAM стоит адово дорого по сравнению с ROM, поэтому вариант так себе.

➡️ AI-based БД скорее представляют собой пузырь, чем полноценные решения. Как и многое в AI-мире. Скорее всего, вам достаточно будет просто написать import openai.

➡️ И лишь Google Таблицы не имеют недостатков. Пользуйтесь на здоровье. ❤️

Статья тут. Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#systemdesign@tech_fit #databases@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Хорошие программисты думают о структуре данных

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

«Плохие программисты думают о коде, хорошие — о структуре данных.»

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

Автор приводит личный опыт (к сожалению, без деталей), когда при оптимизации сложного алгоритма функцию на 500 строк заменили функцией на 50 строк и грамотно спроектированной структурой данных.

⭐️ Интересные идеи

➡️ Данные легче понимать, чем программную логику. Поэтому часть сложности кода можно переносить в структуру данных. Этот подход спорный, но в нём определённо есть смысл.

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

➡️ Код тоже важен! Просто сначала лучше разобраться со структурой данных и взаимодействиями, а уже потом писать код.

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#programming@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Балласт памяти в Go или как полюбить кучу

Крайне занимательная статья о том, как в Twitch одним маленьким изменением добились снижения потребления CPU на фронтовых серверах на ~30% и уменьшили 99-й перцентиль времени ответа API на ~45%.

Их приложение страдало от пиков нагрузки, в остальное время работало стабильно. При нагрузке API latency сильно деградировало. Очевидной идеей было держать дополнительные мощности, но стоимость кусалась.

Потыкав pprof-ом, они выяснили, что при нагрузках огромное потребление приходится на garbage collector. Происходило множество триггеров GC (8-10 в секунду) и выделений памяти, поэтому сборщик мусора пожирал те самые ~30% CPU.

⭐️ Интересные идеи

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

➡️ Балласт не убивается GC, потому что на него висит постоянный референс из main.

➡️ Балласт не потребляет столько памяти на самом деле, потому что в *nix-системах память адресуется виртуально и маппится только при реальном обращении к ней. Поэтому балласт фактически занимает место только в виртуальном адресном пространстве программы.

➡️ Решение привело к уменьшению циклов GC на 99% (до 2 в минуту) и снижению потребления CPU на те самые ~30%. Ну и отказоустойчивость, конечно, повысилась.

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#programming@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Аномалии транзакций и их связь с уровнями изоляции

Хороший refresher по аномалиям, возникающим при выполнении транзакций в многопоточной среде. Автор верно замечает, что понимание уровней изоляции транзакций приходит только после осознания аномалий, которые могут возникнуть.

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

А ещё в статье есть красивые схемы и классное саммари по уровням изоляции.

⭐️ Интересные идеи

➡️ Мир был бы намного проще, если бы мы могли выполнять все транзакции последовательно. В принципе, это возможно, но производительность такого решения была бы ужасной.

➡️ Всего три транзакции могут генерировать шесть возможных последовательностей выполнения (3! = 6). Число вариантов растёт экспоненциально, поэтому чем выше OLTP-нагрузка в системе, тем выше вероятность возникновения аномалий.

➡️ Write Skew — аномалия, о которой часто незаслуженно забывают. А ведь она довольно интересная: транзакции читают одни и те же данные и на их основе выполняют изменения, что приводит к конфликтам записи.

Приятного чтения!

// Понравился пост? Ставь 💛
// Есть классный материал? Пришли ссылку в комментах

#programming@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
📝 @tech_fit

Надёжный процессинг триллионов сообщений Kafka в день

Крутая статья о том, с какими трудностями столкнулись инженеры Walmart при работе с Kafka на своей нагрузке. Особенно интересны условия: 25K+ консюмеров, специфичные юз-кейсы с SLA 99.99, куча приложений на разных языках программирования.

⭐️ Интересные идеи

➡️ Walmart сильно страдал из-за ребалансировки консюмеров. Любое изменение конфигурации подов в consumer group могло вызвать ребалансировку. Это решение даёт системе высокую устойчивость, но негативно влияет на latency, из-за чего многие системы не могли соответствовать своим SLA на обработку.

➡️ Ещё одной проблемой стала блокировка консюмера (партиции) в случае, если в него попадает сообщение, которое никогда не будет обработано (например, из-за бага). Такое сообщение никогда не пойдёт дальше и в результате забьёт канал, пока инженеры не выкатят фикс.

➡️ На большой нагрузке Kafka начинает стоить адски дорого. Единственный способ масштабирования — добавлять больше партиций, но есть мягкое ограничение в 4000 партиций на брокер (в статье есть ссылка на другую статью, пока не читал).

➡️ Решение они придумали тоже довольно специфичное: внедрили Messaging Proxy Service (MPS), который выступил в роли прослойки между Kafka и реальными потребителями. Его задача — остановить постоянный процесс ребалансировки консюмеров и обеспечить обработку ошибок.

➡️ MPS разделяет чтение из Kafka и отправку сообщений потребителям. Легковесный читатель тащит данные из Kafka и складывает в свою очередь, писатель читает из этой очереди и рассылает сообщения потребителям. Параллельно отдельный поток коммитит оффсеты.

➡️ Писатель использует экспоненциальный retry и после нескольких неудачных попыток отправляет сообщение в специально созданный топик Dead Letter Queue (DLQ).

➡️ Решение реализовано на Kafka Connect, поэтому работает достаточно надёжно и масштабируемо. К тому же оно stateless, поэтому легко масштабируется.

Короче, ребята немножко переизобрели свою Kafka. Но решение сработало :)

Приятного чтения!

#highload@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Как бороться с техдолгом в проектах с кучей легаси

Занятная статья о нестандартных подходах, которые можно применить для борьбы с техдолгом.

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

Гораздо более интересной является вторая половина статьи, посвящённая Behavioral Code Analysis (поведенческому анализу кода). Этот подход направлен на выявление самых "горячих точек" в коде и рефакторинг этих участков в первую очередь. Также упоминается инструмент для поведенческого анализа.

⭐️ Интересные идеи

➡️ В первую очередь стоит выделить "горячие точки" — участки кода, где происходит наибольшее количество изменений. Скорее всего, улучшение этих 20% проекта приведёт к 80% результата.

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

➡️ Ещё одна интересная метрика для выбора точки приложения усилий — соотношение сложности и частоты изменений файла. В первую очередь стоит рефакторить сложные и часто изменяемые файлы.

Приятного чтения!

#programming@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи

Нюансы паттерна Retry

Ещё одна классная статья от Яндекса, на этот раз о особенностях паттерна Retry. Она продолжает тему идемпотентности (если не читали, начните с неё — вот ссылка на пост) и объясняет, как простое решение может создать множество проблем в высоконагруженных системах.

Сам по себе Retry прост как пять копеек: запрос упал — нужно повторить. Но всё становится гораздо интереснее, когда мы начинаем говорить о конфигурации повторов в высоконагруженной системе.

⭐️ Интересные идеи

➡️ Если API идемпотентное, запросы можно безопасно повторять, и внедрение Retry может быть хорошим решением. Однако простые перезапросы могут вызвать так называемый retry storm, который добьёт сервис, которому уже не очень хорошо. В качестве решения стоит использовать exponential backoff — экспоненциальное увеличение времени ожидания между повторными попытками.

➡️ Следующий подвох: если сервису стало плохо, его клиенты могут синхронизироваться даже с учётом exponential backoff и начать слать пачки запросов в одно и то же время. В таком случае используется jitter — дополнительная случайная задержка в паузах между ретраями, которая помогает уменьшить вероятность повторного скопления запросов.

➡️ Если сервис будет в нерабочем состоянии слишком долго, то даже exponential backoff не спасёт. Он лишь отложит нагрузку, но при длительном даунтайме она рано или поздно начнёт расти каскадно и точно добьёт систему. Решение: использовать паттерн Circuit Breaker. В качестве альтернативы можно использовать бюджет на ретраи, но этот подход усложняет логику клиента.

Также в тексте упоминаются ещё несколько интересных паттернов, о которых я напишу позже.

Приятного чтения!

#highload@tech_fit #systemdesign@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи