Code of Leadership #56 - Interview with Alexey Gorbov about system administration & databases (Рубрика #Engineering)

Интервью с Алексеем Горбовым, моим коллегой, который в Т-Банке занимается базами данных и разивает нашу Cassandra as a Service. Параллельно этому Леша курирует нашу секцию собеседований по траблшутингу для SRE, которую я когда-то курировал сам, а также рассказывал про нее на конференциях. За полтора часа мы обсудили множество тем

- Введение и представление гостя
- Детство, образование и первые шаги в IT
- Работа в «Одноклассниках»: начало карьеры
- Инцидент в ОК и переосмысление надежности
- Переход к системной надежности
- Работа с Cassandra и автоматизация процессов
- Новые технологии и взаимодействие команд
- Миграция дата-центра: проект и организация
- Уход из «Одноклассников» 
- Первые шаги с Cassandra в новой роли
- Развитие Cassandra как сервиса в Т-Банке
- Проблемы архитектуры и декомпозиции кода
- Практические выводы и преимущества Cassandra
- Рекомендации инженерам по поводу развития и роста

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#SRE #Architecture #Reliability #Management #Staff #Engineering #Processes #Databases #DistributedSystems

[1/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Наконец-то я дочитал оригинальный whitepaper про эту интересную систему для работы с time-series данными от Google. Идея появилась после моего погружения в архитектурный whitepaper, где эту систему перепроектировали с использованием quality-based подхода и UML диаграмм. Если кратко, то суть примерно такая, что в 2020 году вышла статья на VLDB Endowment про эту самую масштабную в мире базу для временных рядов
1) Monarch - это глобально распределённая, мультитенантная in‑memory БД временных рядов для мониторинга почти всех пользовательских и инфраструктурных сервисов Google. Ежесекундно принимает терабайты метрик и обрабатывает миллионы запросов. Архитектура - разделенная по регионам с глобальным plane запросов и конфигурации.
2) Ключ к масштабу: лексикографическое шардирование по “target”, агрегация на этапе сбора, компактные индексы подсказок (Field Hints Index), двухуровневые исполнители запросов (Root/Zone Mixers).
3) На июль 2019: почти 950 млрд рядов в оперативной памяти (~петабайт сжатых данных); средняя агрегация при сборе 36:1 (до 1 000 000:1); индексы позволяют срезать fan-out до десятков тысяч лишних leaf‑узлов.

Как это примерно работало
- Система мультитенантная и глобальная. Региональные зоны автономно принимают и хранят данные в памяти, а глобальные плоскости обеспечивают единый запрос и конфигурацию. Это снижает зависимость от внешней персистентности и повышает доступность мониторинга во время инцидентов.
- Модель данных и запросов отличается от предшественника Borgman (кстати, именно Borgman стал прототипом Prometheus - об этом можно глянуть в документалке, о которой я рассказывал). В отличие от “строчных ключей” прежних систем, Monarch использует типо‑насыщенную реляционную модель метрик (включая распределения/гистограммы) и выразительный язык запросов, что упрощает статический анализ и оптимизации.
- Архитектура обработки выглядела примерно так
-- Ингест: клиенты → ingestion routers → зона → leaf router → Leaves (in‑memory). Уже здесь может работать collection aggregation.
-- Запросы: Root Mixer распределяет по зонам (Zone Mixers); Index Servers (в т.ч. Field Hints Index) заранее исключают нерелевантные узлы, резко уменьшая фан‑аут.
- Отдельно были сделаны оптимизации
-- Collection aggregation: в среднем 36 входных рядов → 1; в экстремуме до 10⁶:1. Экономит память/CPU и трафик.
-- Field Hints Index (FHI): зоны с >10 000 leaves и триллионами ключей; FHI позволяет отсечь ~73 000 нерелевантных leaves для сложных выборок.
-- Лексикографическое шардирование по target: все метрики одного объекта попадают на один leaf → локальные агрегации/джойны, меньше fanout.

В продолжении рассказ, а что было с этой системой дальше.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

[2/2] Monarch: Google's Planet-Scale In-Memory Time Series Database (Рубрика #Architecture)

Но на этом история монарха не закончилась. Уже в 2023 году на конфе ICSE‑SEIP’23 ребята из Google опубликовали whitepaper-продолжение (что я уже разбирал).
Тезисно этот paper можно сократить до следующих пунктов
1) Причина: двукратный рост год‑к‑году QPS и числа рядов, проблемы с поддержкой и дальнейшим попаданием в SLO
2) Команда решила провести редизайн с опорой на quality‑attribute сценарии + лёгкие UML‑модели
3) Фактически, декомпозицировали Leaf на Leaf (KV‑хранилище), Leaf Index Server и Leaf Mixer.
4) Это повлияло в плюс на доступность и сопровождаемость, а latency выросла умеренно, хотя хопов стало больше на 2  (рост с ~12–14 до 16–18 RPC)

Но и это было не все - принципы Monarch легли в основу облачного Managed Service for Prometheus: это сервис на том же бэкенде Monarch, которым Google мониторит свои сервисы. Запросы PromQL частично вычисляются на стороне Monarch. Для инженерных команд это даёт из коробки «глобальный» Prometheus‑опыт. Кстати, вопрос масштабирования отдельных Prometheus возникает у крупных компаний часто и для решения этого вопроса появился проект Thanos. Еще можно глянуть на VIctoriaMetrics, этот проект тоже борется с ограничениями Prometheus, но по другому (можно глянуть мой разбор подкаста где автор проекта про это рассказывал)

Если подбивать уроки из истории Monarch, то стоит
- Собирать метрики ближе к источнику, аггрегировать рано (уменьшение кардинальности и стоимости)
- Дешёвый предикатный индекс → дешевле распределённые запросы (урезать fanout до выполнения)
- Строго разделять stateful и stateless части (проще сопровождать, легче выдерживать SLO при росте) - фокус на этом во втором whitepaper про редизайн
- Шардирование по бизнес‑ключу (target) - локальные агрегации/джойны дешевле.

#Software #Architecture #DistributedSystems #SRE #Engineering #Databases #Data

Техношоу «Дропнуто»: выпуск 1 (Рубрика #SRE)

Посмотрел вчера интересный выпуск нового шоу "Дропнуто" от моих коллег из Т-Банка. В этом шоу ребята говорят об инцидентах на дата‑платформах, с честным разбором причин и выводов. Интересно, что шоу идет в прямом эфире, что должно вселять надежду в минимум редактуры и зап...ния. Формат выдержан в духе blameless postmortems, где мы подходим к постмортемам без обвиненений и даже с прицелом на обучение - чель поговорить про то, а почему отказы случаются, как их предотвратить и что изменить в процессах/архитектуре для повышения надежности (кстати, про надежность в Т-Банке хорошо рассказывал Леша Мерсон в статье, о которой я писал раньше).

В первом выпуске подкаста гостем был Александр Крашенинников из Т‑Банка, практик в области платформ данных/ETL/DWH, а также просто человек с хорошим чувством юмора и навыками импровизации, что можно увидеть из его рассказа о двухнедельном инциденте в датаплатформе, о котором он рассказывает в этом эпизоде. Цепочка инцидента выглядит кратко примерно так: удаление/потеря метаданных → падение чтения в Trino → нет бэкапа/медленное CDC‑восстановление → критичный инцидент → разворот на новую Kafka‑архитектуру + контракты → унификация схем, параллельные загрузки → валидация и исправление расхождений → восстановление сервиса с возможной частичной потерей → восстановление сервиса из бекапов и дозагрузка исторических данных.

Инженерам может понравитсья этот «боевой» разбор инцидента
- Эксплуатация CDC (change data capture): где Debezium удобен, его архитектурные варианты, типовые грабли
- Паттерны целостности: outbox‑подход для надёжного обмена событиями между сервисами и границы применимости.
- Наблюдаемость пайплайнов: какие SLI поднимать для «скорости данных» (freshness/latency), целостности (дупликаты/пропуски), устойчивости коннекторов.

Руководителям эпизод полезен для управленческой оптики:
- Единый язык риска: связать цвет/серьёзность инцидента с бюджетам ошибок и фризом релизов
- Культура обучения на сбоях: blameless‑постмортемы как системный инструмент качества и коммуникации между командами данных/продукта/SRE.
- Управление SLO: перевод пользовательских метрик (например, «данные в витрине свежи ≤ X минут 99,9% времени») в алерты и план/факт по риску.

#SRE #SystemDesign #Software #Architecture #Metrics #SoftwareArchitecture #Engineering #Databases #Data

Топ-3 книги издательства Питер, что я могу порекомендовать в этом году (Рубрика #Software)

Все три приведенные ниже книги я считаю стоящими, но надо отметить, что читал я их еще в оригинале и в тот момент, когда они были опубликованы (на русском я их пока не перечитывал)

1️⃣ AI-инженерия. Построение приложений с использованием базовых моделей
Последние годы проходят во многом под знаком AI. Уровень хайпа просто бомбический, но это не значит, что за хайпом ничего не стоит, а сами технологии ничего не дают. Напротив, результаты есть и они масштабные, но только у тех, кто умеет пользоваться инструментом правильно. А эта книга как раз про то, как строить приложения с использованием фундаментальных моделей. Я уже рассказывал про эту книгу раньше и считаю, что она будет полезна инженерам

2️⃣ Паттерны проектирования API
Про эту книгу я тоже рассказывал раньше, но в рамках хайпа про AI она мне кажется становится важнее. Суть в том, что 2025 год прошел под знаком AI агентов и эта движуха дальше будет только разгоняться - осенью 2024 года был представлен протокол MCP (model context protocol), который описал формат API вызова инструментов моделями, весной 2025 года Google представил A2A протокол (agent to agent), но все эти штуки живут поверх хороших подходов к управлению API. А эта книга как раз про это, причем автор, Джей Джей Гивакс, работал в Google и был соавтором статьи "API Governance at Scale" про подходы в Google (см. мой разбор). Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta (видимо там тоже нужно поработать над API Governance).

3️⃣ Распределенные данные. Алгоритмы работы современных систем хранения информации
Про эту книгу "Database Internals" я уже рассказывал и мы даже ее разбирали в подкасте "Code of Architecture". Если подвязывать эту книгу к теме AI, то можно много сказать про хранение данных, про важность их для контекста ... Но я не буду этого делать - я выбрал эту книгу, потому что она хорошо рассказывает про движки для хранения данных, а также про архитектуру распределенных систем. Автор книги, Алекс Петров, контрибьютил в Cassandra, поэтому у него релевантный опыт для рассказа об этих темах.

В общем, книги достойные - я получил большое удовольствие, когда их изучал:)

#Databases #Software #Engineering #Architecture #AI #ML #DistributedSystems #Architecture #API

[1/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Изучил ежегодный обзор рынка баз данных от Andy Pavlo, крутого преподавателя и исследователя мира БД из Carnegie Melon University. Ниже краткое саммари основных моментов

🐘 PostgreSQL правит бал
Доминирование PostgreSQL продолжается и именно вокруг Postgres сосредоточена большая часть энергии и инноваций в СУБД.
В 2025 это подтвердилось громкими сделками:
- Databricks купил облачный PostgreSQL-сервис Neon (~$1 млрд)
- Snowflake – Crunchy Data ($250 млн)
- Microsoft запустил свой PostgreSQL-DBaaS (HorizonDB)

Появились проекты масштабирования Postgres по горизонтали (шардинг):
- Supabase нанял соавтора Vitess для проекта Multigres
- PlanetScale анонсировал систему Neki – Postgres-на-стероидах для больших нагрузок
Pavlo приветствует эту волну "шардированного Postgres", хотя напоминает, что попытки сделать масштабируемый Postgres предпринимались и раньше.

🤖 MCP для LLM в каждый дом
Если 2023-й был годом "векторных индексов" в каждом движке, то 2025-й – годом поддержки Anthropic MCP (Model Context Protocol) во всех СУБД. После поддержки OpenAI этого протокола практически каждый вендор выпустил MCP-сервер к своей базе – от OLAP-систем (ClickHouse, Snowflake и др.) до NoSQL (MongoDB, Neo4j, Redis); а провайдеры PostgreSQL‑DBaaS написали свои реализации. По мнению Andy Pavlo появление такого стандарта взаимодействия ИИ с БД - это благо, но стоит нужно ограничивать и мониторить эти реализации (например, только read-only запросы, лимиты на результат и таймауты), иначе рано или поздно случится факап

⚖️ MongoDB против FerretDB – судный день?
Впервые за историю индустрии СУБД одна компания подала в суд на другую за имитацию её API. MongoDB, Inc. обвинила стартап FerretDB (прокси, переводящий запросы MongoDB в PostgreSQL) в нарушении авторских прав, патентов и лицензии. Andy Pavlo сравнивает этот иск с процессом Oracle vs Google за Java API – тогда суд встал на сторону свободной реализации. Исход дела неясен, но есть пикантный нюанс: FerretDB изначально назывался "MangoDB". Интересно, что параллельно Microsoft в 2025 открыла исходники собственной Mongo-совместимой базы DocumentDB (передав проект в Linux Foundation) – то есть фактически занялась тем же, в чём Mongo обвиняет FerretDB.

📁 Война форматов данных
Почти 15 лет формат Parquet царил в колонночных хранилищах, но в 2025 сразу пять новых open-source форматов бросили ему вызов (ещё несколько появились в 2024-м). Среди них – проекты от академиков (FastLanes, F3, AnyBlox), стартапов (Vortex от SpiralDB) и гигантов (Microsoft Amudai, правда, его тихо прикрыли к концу года). Сообщество Parquet встрепенулось и взялось за модернизацию стандарта. Andy Pavlo отмечает, что главная проблема Parquet – не в самом формате, а в фрагментации реализации: слишком много парсеров/писателей в разных языках, поддерживающих разный поднабор фич. В результате 94% файлов «в живой природе» до сих пор созданы с фичами v1 образца 2013 года. Никто не будет переписывать петабайты старых паркет-файлов, да и невозможно быть уверенным, что любая система прочитает новейший файл – вдруг ей не хватит поддержки специфичных опций. Новые форматы пытаются решить проблему совместимости по-разному. Например, формат F3 (разрабатываемый в том числе при участии Pavlo) встраивает в каждый файл собственные декодеры: и в виде нативных модулей, и в виде WASM-кода, лежащего прямо в файле. Идея в том, что база данных сможет прочесть колонку даже нового, незнакомого формата – исполнив прикреплённый WASM-декодер. Другие (AnyBlox) генерируют единый WASM для всего файла. Пока неясно, чей подход победит – Parquet повсеместен, и инерция огромна. Следующее сражение развернётся за поддержку GPU в форматах, прогнозирует Pavlo, но одно ясно уже сейчас: битва за эффективное хранение данных вошла в новую фазу.

В продолжении я расскажу про остальные пункты.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future

[2/2] Databases in 2025: A Year in Review by Andy Pavlo (Рубрика #Databases)

Продолжая рассказ об обзоре рынка баз данных от Andy Pavlo, расскажу про оставшиеся тезисы.

💸 Деньги, слияния и поглощения
2025-й оказался богат на крупные сделки в мире данных
- Продолжилась охота на PostgreSQL-компании: Neon ушёл к Databricks, Crunchy Data – к Snowflake (за $250 млн)
- IBM не остался в стороне и забрал себе DataStax (Cassandra) примерно за $3 млрд
- Salesforce раскошелился на старейшую ETL-платформу Informatica (~$8 млрд)
- Даже MariaDB Corp. умудрилась в том же году дважды купить «саму себя» – вернув под своё крыло отколовшуюся облачную дочку SkySQL
- Неожиданностью года стало слияние Fivetran и dbt Labs – две взаимодополняющие компании объединились в ETL-колосс, метящий на скорый IPO

📉 Инвесторы охладели к новым СУБД
Хайп вокруг векторных баз спал, венчуры в 2025 меньше инвестировали в молодые DB-стартапы, предпочитая нести деньги в AI. Зато лидеры отрасли продолжают получать огромные раунды:
- Databricks привлёк $5 млрд (два раунда) за год
- ClickHouse – $350 млн
- Supabase – суммарно $300 млн (Series D + E)
- И даже совсем молодые проекты вроде SpiralDB (создатели Vortex) поднимают десятки миллионов.

💀 Не все выжили
Ряд компаний не пережил этот год
- Закрылся FaunaDB – амбициозный распределённый СУБД‑стартап с сильной консистентностью (Pavlo был у них техконсультантом и советовал добавить SQL, но его не послушали)
- Проект PostgresML (машинное обучение внутри PostgreSQL) тоже не взлетел
- Команда Hydra (коннектор DuckDB↔️Postgres) разбрелась кто куда
- Даже классика: Apache Derby (Java-СУБД с 1997 года) объявлен "read only" – разработка остановлена за отсутствием мейнтейнеров.
GPU-базы данных тоже постигла нелёгкая судьба
- Стартап-супергруппа Voltron Data с инвестициями $110M так и не успела выпустить свой GPU-ускоренный движок Theseus
- HeavyDB (ранее OmniSci/MapD, пионер GPU-СУБД) тихо прекратил самостоятельное существование – команду поглотила Nvidia
Andy Pavlo резюмирует: нишевые решения вроде Kinetica и Sqream по-прежнему где-то на периферии, а заметно потеснить классические CPU-ориентированные СУБД GPU-решения пока не смогли. Производительность современных колонночных систем на CPU уже настолько высока, что решающее значение имеют не сырые оптимизации, а удобство для разработчиков и «умность» оптимизатора запросов. Впрочем, Pavlo намекает, что в 2026-м мы услышим о новых попытках задействовать GPU на полную мощность – гонка продолжается.

🏆 Ларри Эллисон – вершина успеха
Для основателя Oracle этот год стал поистине триумфальным. В 81 год Ларри Эллисон возглавил список богатейших людей планеты, впервые «коронованный» как самый богатый человек в мире (состояние оценивалось около $393 млрд). Oracle взлетел в цене благодаря облачным сделкам в сфере ИИ, и в сентябре 2025 акции Oracle выросли на 40% за день, сделав Эллисона не только №1 в мире, но и самым богатым человеком в истории (с поправкой на инфляцию обошёл даже Рокфеллера). Правда, спустя пару месяцев стоимость Oracle откатилась и Ларри потерял порядка $130 млрд – в масштабе миллиардера это как для нас с вами лишиться одной зарплаты, шутит Pavlo. В течение года Oracle/Эллисон засветились в крупных событиях: Oracle выступил ключевым партнёром в сделке по «американизации» TikTok и финансировал попытку поглощения Warner Bros (через принадлежащий семье Эллисона холдинг Paramount). Andy Pavlo признаётся, что был даже рад услышать новость о том, что “благодаря базам данных кто-то стал самым богатым на земле” – наконец в нашей сфере случилось нечто позитивное. Он иронизирует над критиками Эллисона: мол, Ларри уже завоевал мир корпоративных баз данных, выиграл регаты и построил сеть люкс-спа для техно-богачей, так почему бы ему не купить новостной телеканал? Эллисон не обращает внимания на разговоры, делает что хочет – фанаты и новая жена его поддерживают, а остальное неважно.

#Database #Architecture #Management #DistributedSystems #Software #Engineering #Future

Сайт по system design (Рубрика #Architecture)

Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.

Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Update по System Design Space (Рубрика #Engineering)

Я запустил этот сайт чуть больше недели назад и продолжил его активно дорабатывать и решил поделиться lessons learned.
- Дорабатывать сайт ипользуя только Lovable дорого - кредиты улетают как не в себя - я прошел такой путь за месячную подписку всего за полтора месяца 0$ -> 25$ -> 50$ -> 100$ -> 200$
- Как второй и основной помощник я сейчас использую OpenAI Codex, где подписки в 200$ хватает как на веб, deep research, так и на написание кода (сразу для целой пачки ресурсов)
- Я добавил очень много новых глав + отдельный раздел, что посвящен документальным фильмам про технологии
- Для сложных тем я сделал визуализации архитектуры и процесса работы - смотрите примеры из части с кейсами
- Я добавил светлую тему, оглавление, поменял верстку под мобилу и еще кучу всего
- Сайт успел за неделю полежать пару раз. Один раз мы с Codex оптимизировали сборку и lazy загрузку React, что локально все работало, а на внешнем хостинге нет - пришлось откатить эту оптимизацию. Второй раз была проблема с DNS - я забыл подтвердить email регистратору доменных имен и дальше делегирование сайта было преостановлено (дальше прожал кнопочку подтверждения из email и буквально всего через 2 часа все вернулось, а могло и через 2 дня)
- Как-то я попросил отрефакторить проект и агент ушел локально колбасить что-то на всю ночь - утром пришел проверил, сделал несколько фиксов и все полетело
- Тесты у меня есть, но из-за того, что я часто меняю внешний вид сайта, то я часто их просто заново гененрирую, а не прогоняю для проверки (главы - это отдельные ts файлы, поэтому изменения обычно хорошо локализованы и дают мало внешних эффектов)
- Я занимаюсь этим по выходным, а также по вечерам после работы и это затягивает - иногда в 2 часа ночи ловлю себя на мысли, что надо выдать задачку помасштабнее и наконец-то пойти спать:)

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

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Local-First Software: Taking Back Control of Our Data | a mini-doc (Рубрика #DistributedSystems)

Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.

Основные идеи концепции такие
1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа.
2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным.
3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы.
4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.

Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее
- Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета)
- Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка.
- Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена.
- Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака.
- Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.

В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.

P.S.
Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)

P.P.S.
Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.

#DistributedSystems #Architecture #SystemDesign #Software #Databases

Update: SDS (System-Design.Space)

С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.

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

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software