System Design: backend

Как и обещал — задачка с бэковой секции Яндекса. На system design там реально дают «спроектируй ленту новостей, как в Твиттере/ВК, где новостные посты выдаются на основе подписок на авторов»: человек подписан на кучу людей, открывает приложение и видит их посты, свежие сверху. Погнали.

Базовая идея — идти от базы: на открытии ленты делаем SELECT * FROM posts WHERE author IN (на кого подписан) ORDER BY time LIMIT 50. В деве летает. Но в продовой бд так не прокатит: у юзера тысяча подписок, у каждого тысячи постов, и так одновременно долбят миллионы людей. Лента открывается на каждый заход — чтение это самый горячий путь, и вот на нём база и ляжет. Дальше обсудим, какое примерное решение от тебя ждут на собесе.

Уточняем детали
Сначала уточни границы: сколько подписок у среднего юзера, сколько постов в день, какая задержка ок. Но главный вопрос один: есть ли у нас звёзды — аккаунты на миллионы подписчиков? Звучит как продуктовая мелочь, а на деле именно он разворачивает всю архитектуру — сейчас увидишь как.

Попробуем зайти от обратного
Ключевая идея, ради которой задача и придумана: не собирай ленту в момент, когда её открыли. Собери заранее. Когда автор публикует пост, мы разносим (fan-out) его по заранее посчитанным лентам всех подписчиков — кладём в «инбокс» каждого. Тогда открыть ленту — дешёвое чтение готового списка, без тяжёлого запроса по всем подпискам. Смысл манёвра: дорогую работу мы перенесли с частого чтения на редкую запись. Пост пишут один раз, а ленту с ним открывают тысячи раз — вот пусть будет тяжело один раз на записи, а не тысячу раз на чтении.

Возвращаемся к звёздам
А теперь тот самый вопрос. Fan-out на записи прекрасен — пока блогер с 40 миллионами подписчиков не нажмёт «опубликовать». Один пост превращается в 40 миллионов записей, разом, всплеском. Одна звезда убивает всю схему. Поэтому — гибрид. Обычные аккаунты разносим по подписчикам на записи. А посты звёзд не разносим: их мало, зато подписчиков тьма. Их подтягиваем в момент чтения и подмешиваем в готовую ленту. Разложил систему на два пути ровно из-за вопроса про звёзд — это ответ уже не ниже мидла.

В целом вся задача это пример из «Designing Data-Intensive Applications» Клеппманна, первая глава там ровно про ленту Твиттера. Готовишься к систем дизайну — тогда стоит ознакомиться с этой книжкой, не пожалеешь.

Где запнуться можно
Всё вытекает из мысли «работаем на записи». Забыл — провалился. Разнос — асинхронный, через очередь. Автор нажал «опубликовать» — его запрос не ждёт, пока пост доедет до десятков тысяч лент: кинули задачу в брокер, ответили сразу, подписчики увидят через секунду. Тут ок eventual consistency — лента не банковский баланс. В инбоксы кладём не посты, а их id. Хранить полный текст в ленте у каждого из тысяч подписчиков — копия одного и того же миллион раз. Держим ссылки, сам пост подтягиваем при чтении. Не разноси мёртвым душам: если юзер не заходил полгода, гонять его ленту на каждый пост подписок — жечь ресурсы впустую. Соберём на чтении, если вернётся. И идемпотентность: разнос будет ретраиться при сбоях, один и тот же пост не должен лечь в ленту дважды.

На что нацелена задача по итогу
Проверяют этой задачей одно: видишь ли ты, где в системе на самом деле тяжело. Наивный SELECT по подпискам — «лента как страница в базе», его напишет и джун. А инженер замечает, что ленту открывают в тысячи раз чаще, чем пишут пост, и переносит всю тяжесть туда, где она случается редко — на запись. Дальше это само тянет за собой и очередь, и гибрид под звёзд, и хранение по ссылкам: весь дизайн — следствие одного решения, считать ленту заранее, а не на лету. Дожал эту мысль — секция твоя.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

System Design: backend

Задача с реального собеса Яндекса. Условие: приходит уведомление — id, тип (EMAIL/SMS/PUSH), получатель, текст. У получателя есть разрешённые каналы и блок-лист отправителей. Нужно отфильтровать уведомление и не отправить дубль, если такое же уже было за последние 24 часа. Хранилище реализовывать не надо — только контракты и логика. Погнали.

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

Определим рамки задачи
Сначала границы: какие каналы поддерживаем, откуда берём настройки получателя, что считаем «таким же» уведомлением для дедупа.

Например, что значит «такое же»? «Ваш заказ №123 готов» и «Ваш заказ №124 готов» — дубль или нет? А если одно пришло по EMAIL, а второе по SMS?

Поэтому уточняем:
* дедуп общий для всех каналов или отдельный;
* что именно считается одинаковым уведомлением;
* что считается успешной отправкой;
* какие ожидаются RPS.

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

Ядро решения
Ключевая мысль: фильтрация — это цепочка независимых проверок, через которую уведомление либо проходит целиком, либо отсеивается на первом же несоответствии.

Не один раздутый if, а pipeline из мелких фильтров:
- канал разрешён у получателя;
- отправитель не в блок-листе;
- уведомление не дубль за последние 24 часа.

Первый же фильтр, сказавший «нет», отсекает уведомление — остальные не гоняем. Такую систему легко расширять: новый фильтр = ещё одно звено, а не правка портянки.

Возвращаемся к дедупликации
Дедуп за 24 часа означает, что система должна хранить след недавно отправленных уведомлений. Ключ вроде: recipient + type + id. А по нему — время отправки. Пришло новое — считаем ключ и смотрим, существует ли такой за последние 24 часа. И два неочевидных момента.

Первый — что именно входит в notificationIdentity. Сырый текст не всегда подходит: если в нём динамические данные, побайтовое сравнение может дать неправильную семантику. Поэтому сначала выясняем у интервьюера, что бизнес считает дублем. Второй — TTL. Записи должны сами протухать через 24 часа, иначе хранилище будет расти бесконечно.

Где сыпятся
Порядок фильтров: дешёвые и отсекающие проверки — вперёд. Канал и блок-лист — настройки. Дедуп — поход в стор. Глупо лезть в стор за дедупом, если уведомление и так отсечётся выключенным push.

Но есть ещё одна ловушка — гонка на дедупе. Поэтому check() и запись факта отправки должны быть атомарными. Например, через операцию tryReserve(key, ttl): первый запрос получает true, второй — false. А дальше интервьюер вполне может спросить: что будет, если мы зарезервировали уведомление, а внешний провайдер упал? Вот тут уже нужно отдельно определить семантику: защищаемся от повторного вызова сервиса или гарантируем отсутствие повторной доставки пользователю? Это разные задачи.

Контракты, а не реализация
Откуда берутся настройки и история отправок — прячем за интерфейсами: SettingsProvider, HistoryStore, и неважно, Redis там, PostgreSQL или внешний сервис. На собесе мы проектируем логику, а не привязываемся к конкретному хранилищу.

Что тут на самом деле проверяют
Проверяют одно: видишь ли ты, что это не «класс Notification с четырьмя полями», а конвейер фильтров с памятью о недавних отправках. Красивые модели нарисует и джун — и утонет в них, не дойдя до логики. Инженер сразу думает: что проверяем → в каком порядке → где храним состояние → что считаем дублем → что произойдёт при гонке.

А дальше строит pipeline от дешёвых проверок к дорогим, прячет источники данных за контрактами и понимает, что дедупликация — это не просто get() в Redis.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

Обычно здесь разбираем бэкенд и фронтенд, но сегодня о другом.

У Авито сейчас идёт набор на курс по QA. Регистрация была до 16 августа, а до 19-го нужно ещё пройти тест.

Кто уже подался и тест пока не решил — забирайте разбор выше: 32 вопроса, от базы тестирования и приоритетов багов до основ кода, HTTP и командной строки, с подробным объяснением каждого ответа. Сам тест не то чтобы сложный, но лучше сверить логику заранее, чем гадать на скрининге.

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

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

System Design: Frontend

Эту задачу мне давали на собесе в одну из аутсорс компаний. Задача звучит следующим образом. Есть большой продукт с несколькими темами - светлая, тёмная, брендовые под разных заказчиков или разные ивенты. Темы должны переключаться на лету, без перезагрузки, и переиспользоваться между приложениями и командами. Спроектируй темизацию.

Есть соблазн сделать несколько CSS-файлов и переключать их, или прокидывать объект темы через контекст в каждый компонент. Второе к тому же вызовет перерендер всего дерева при смене темы. Задача про то, где физически живёт «текущая тема» и как менять её дёшево.

Первое, что стоит спросить у интервьюера - нужно ли переключение в рантайме без перезагрузки (почти всегда да) и шарятся ли токены между несколькими приложениями или микрофронтами. Второе определяет, куда выносить токены. Заодно уточни, нужны ли пользовательские кастомные темы.

Дальше поток. Дизайн-токены - это единый источник правды для цветов, отступов, шрифтов, радиусов. Не хардкод «#1E90FF» по компонентам, а семантические токены («color-primary», «spacing-md»). Компоненты ссылаются на токены, а не на конкретные значения.

А теперь про очки, и это ключевое решение. Переключение темы в рантайме проще и дешевле всего на CSS-переменных: компоненты используют var(--color-primary), а смена темы — это подмена значений переменных на корневом элементе. Никакого перерендера React вообще - браузер сам перекрашивает. Объясни, почему это лучше передачи темы через JS/контекст: контекст дёргает перерендер всего поддерева, CSS-переменные - нет. Токены выносим в отдельный пакет/слой, чтобы шарить между командами и микрофронтами. Честно назови trade-off: CSS-переменные требуют дисциплины - ни одного захардкоженного цвета в компонентах, иначе тема поедет частично. Проговорил «CSS-переменные вместо JS ради отсутствия перерендера» - это ответ архитектурного уровня.

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

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

Мы тут постоянно разбираем system design — и по фронту, и по бэку. Но у теории есть одна засада: паттерны легко выучить как список названий. Гидратация, оптимистичное обновление, идемпотентность и т.д. — все слышали, многие даже перескажут определение. А на собесе или в проде вопрос звучит иначе: не «что такое circuit breaker», а «почему у тебя порог в 5 ошибок подряд не сработал» и «что бы ты поменял». И вот тут список названий не помогает.

Поэтому запускаем новую рубрику. Формат простой: берём известный опенсорсный проект — React, etcd, Excalidraw, Kafka, Postgres-обвязки — открываем их реальный код, PR или issue, и смотрим, какой паттерн там применён и, главное, зачем. Не абстрактное «есть коробочка, туда идут запросы», а конкретно: вот была проблема, вот как её решили, вот где решение всё равно упирается в потолок и какой компромисс инженеры сознательно приняли.

Почему это вам поможет. Во-первых, паттерн, увиденный в реальном коде, запоминается совсем не так, как определение из статьи — вы видите, от какой именно боли он спасает и что ломается без него. Во-вторых, это прямая подготовка к собесам: сильные вопросы по систем дизайну почти всегда звучат как «вот тут сделали так, а не иначе — почему?», и после этой рубрики у вас будут заготовленные ответы на реальных примерах, а не на выдуманных. В-третьих — и это, наверное, главное — вы будете учиться на чужом коде крупных проектов и вытаскивать оттуда идеи, возможно, некоторые даже пойдут и прочитают исходники после разборов. И так у вас будет формироваться навык, который отличает мидла от джуна сильнее, чем знание любого конкретного фреймворка.

Что планируется по бэку. Распределённые системы (консенсус, выборы лидера, репликация и почему «сервер подтвердил» ещё не значит «сохранено»), устойчивость под нагрузкой (circuit breaker, rate limiting, backpressure), и работа с данными (очереди, идемпотентность, изоляция транзакций).

Что будет по фронту. Тоже не про «как сверстать кнопку», а про архитектуру: как устроен прерываемый рендеринг в React, почему undo/redo в коллаборативных редакторах переписывают с нуля, как работает изоляция расширений и почему она защищает не от всего, что не так очевидно в optimistic update и реактивности.

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

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

«Кабанчика» обязан знать каждый уважающий себя айти специалист, но осилить 700 страниц сплошного текста не так уж и просто.. Чтобы ты не тратил нервы и силы, я пересказ всю книгу всего за минуту. Смотрим!

https://www.youtube.com/shorts/i0nsmAUByZk

Открываем новую серию постов. Смысл такой: берём известный проект, смотрим, как в нём решили какую-нибудь неочевидную проблему, и разбираемся, чем этот приём полезен лично тебе в твоём коде. Без душной теории — только то, что реально пригодится. И начать хочу с истории, которая случалась с каждым, кто хоть раз что-то куда-то сохранял.

Ты сохранил данные. Сервис ответил «готово». Ты выдохнул и пошёл дальше. Знакомо? А теперь неприятная новость: «сервис ответил готово» и «данные действительно на месте» — это два разных события. Между ними есть щель, и данные умеют в неё проваливаться. Причём случается это ровно в тот момент, когда что-то ломается, — то есть в самый неподходящий. Чтобы увидеть эту щель во всей красе, посмотрим, как с ней воюет Kafka. А потом вернёмся к твоему коду, потому что проблема там ровно та же.

Как Kafka бережёт данные. Она хранит каждую порцию сообщений сразу на нескольких серверах: один главный, он принимает записи, остальные — его копии, они за ним повторяют. Звучит надёжно. Но вот ловушка, в которую попадают почти все. Главный сервер принял сообщение, записал у себя, ответил «принято» — и в следующую секунду умер. А копии не успели повторить за ним. На его место встаёт одна из копий, но у неё этого сообщения нет. Всё, сообщение исчезло. А отправитель-то уверен, что всё хорошо, — ему же ответили «принято».

Как эту дыру закрывают. У отправителя есть настройка, которая решает, когда считать сообщение сохранённым. Можно сказать «мне хватит, что его принял главный» — быстро, но это ровно та история с исчезновением. А можно потребовать «считать сохранённым, только когда его повторили и живые копии тоже». Вот тогда появляется настоящая гарантия: даже если главный умрёт, сообщение уже есть на других.

Но и это не всё. Что, если копии отстали и по одной повыпадали, а живым остался только главный? Тогда правило «пусть подтвердят копии» тихо превращается в «пусть подтвердит главный» — и мы снова там же, откуда начали. Поэтому есть ещё одна настройка-предохранитель: «если живых копий осталось меньше, чем нужно, — вообще перестань принимать записи и честно скажи об этом». Лучше отказать сразу, чем сделать вид, что всё сохранилось, и потерять данные молча.

И вот тут главная мысль, ради которой всё затевалось. Это выбор, а не значение по умолчанию. Хочешь надёжность — требуй подтверждения от нескольких копий, но тогда при поломке части серверов запись может встать колом (некому подтверждать). Хочешь, чтобы запись шла всегда, — ослабляешь требования, но растёт шанс что-то потерять. Идеального варианта «для всех» нет. Для денег ты выберешь надёжность и переживёшь, что иногда нельзя записать. Для какой-нибудь статистики — наоборот, пусть пишется всегда, а пара потерянных точек погоды не сделает.

А теперь — зачем тебе это, даже если ты Kafka в глаза не видел. Принцип простой и универсальный: ответ «готово» стоит ровно столько, сколько мест реально успели сохранить твои данные. Так что каждый раз, когда твой код получает «ок» откуда-то извне, спроси себя — «ок» от кого и что за ним стоит.

Пара примеров из обычной жизни. Пишешь в базу, у которой есть копии для чтения. Запись прошла, но копии могли ещё не успеть её получить. Читаешь сразу после записи из копии — а там пусто. Та же щель, вид сбоку. Или дёргаешь чужой сервис по сети и получаешь 200. Это значит «я принял твой запрос», а вовсе не «я довёл дело до конца» — если тебе важен именно результат, надо его проверить, а не верить на слово. И везде, где надёжность важнее скорости, ты за неё платишь — тем, что иногда придётся подождать или получить отказ. Это нормально. Ненормально — надеяться, что «да обычно долетает».

Если совсем коротко: надёжность — это не галочка «включил копии и забыл», а осознанное решение, сколько подтверждений тебе достаточно и чем ты за это готов заплатить. Почти все истории про «данные загадочно пропали» — и в Kafka, и в обычном коде — на самом деле про неправильно понятое слово «готово».

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

Второй пост серии про паттерны на реальном коде. В прошлый раз говорили, почему «сохранилось» и «точно сохранилось» — не одно и то же. Сегодня — про идею, на которой держится половина софта вокруг нас, хотя мало кто задумывается про нее.

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

Посмотрим, как это сделано в VS Code — там всё честно и наглядно. Расширения крутятся не внутри редактора, а в собственном процессе, у него и название есть — extension host. Замысел в одну строчку: что бы ни стряслось с расширениями, редактор обязан устоять.

И он выдерживает. Процесс с расширениями рухнул целиком — а редактор даже бровью не повёл: курсор мигает, текст на месте, файл спокойно сохраняется. Разработчики так и ставили задачу — пусть расширения хоть все разом отвалятся, но ни строчки твоей работы пропасть при этом не должно. Когда процесс падает, сверху выезжает плашка «расширения отключились, перезапустить?», жмёшь — и он поднимается заново. На то он и отдельный, что пересоздать его можно, ничего вокруг не задев.

А теперь то, из-за чего у людей годами пригорает. Стена стоит между редактором и расширениями — но между самими расширениями никакой стены нет. Все они набиты в один общий процесс и делят на всех единственный поток выполнения. А в JavaScript поток ровно один. И получается некрасивое: стоит одному расширению уйти в тяжёлые вычисления и занять поток надолго — как замирают вообще все расширения сразу. Не только виновник, а все соседи по процессу. Человек видит, что редактор целиком отупел и не реагирует, ругает VS Code последними словами — а нашкодило одно расширение, просто остальные заперты с ним в одной комнате.

Показательно, что и сама команда эту штуку архитектурно не победила — пошла в обход. VS Code теперь приглядывает за процессом с расширениями, и если тот перестал отвечать, тихонько включает профайлер: выясняет, кто съел весь поток, находит виновника и предлагает написать его автору. Проблему не убрали — её хотя бы вытащили на свет.

Тут есть тонкость, которую легко проскочить. Отдельный процесс спасает ровно от одного: сломанное расширение не утянет за собой редактор. Но заставить расширения не мешать друг другу он не может — это не входит в его задачу. Чтобы одно зависшее расширение не морозило соседей, пришлось бы городить следующий этаж защиты: свой процесс под каждое, тяжёлые задачи в фоновые потоки, лимиты по времени. И всё это не бесплатно — лишняя память, возня с общением между частями, более медленный запуск. В VS Code прикинули цену и решили, что оно того не стоит: одна общая крыша над всеми расширениями — осознанный размен между надёжностью и расходами.

Чему тут стоит научиться, даже если ты никогда не будешь писать редактор кода. Когда проектируешь что-то, что запускает не свой код — плагины, пользовательские скрипты, обработчики от сторонних команд, — заранее спроси себя: от чего именно я тут защищаюсь. «Чтобы чужое не уронило моё» и «чтобы одно чужое не мешало другому чужому» — две разные задачи, и вторая решается дороже. Их легко перепутать и поставить границу не там: думаешь, что защитился, а закрыл только половину. И второе: если задачу нельзя решить чисто — не грех сделать её хотя бы заметной. VS Code не смог развести расширения по-настоящему, но научился показывать пальцем на виновника, и это уже куда лучше, чем молча тормозить. Иногда честная диагностика ценнее красивого, но недостижимого решения.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art

System Design: frontend

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

Почему такое вообще спрашивают. Геодезист выезжает на объект — поле, стройка, лес за городом, — и связи там может не быть весь день. А работать надо: открыть карту участка, занести замеры, отметить точки, что-то поправить. Если приложение при потере сети показывает белый экран, им попросту нельзя пользоваться в поле. Значит, оно должно работать так, будто интернет и не нужен, а сеть подхватывать само, когда специалист вернётся в зону покрытия.

Первое, что хочется ляпнуть, — «закешируем данные и всё». И вот это ловушка. Как только ты разрешаешь не только читать офлайн, но и менять данные, ты, по сути, строишь маленькую распределённую систему: у тебя появляется две копии правды (на устройстве и на сервере), и они умеют разъезжаться. Все классические боли распределёнки — конфликты, рассинхрон, порядок операций — теперь твои. Не подумал про них — решение развалится на первом же реальном сценарии.

Поэтому до того как проектировать, спроси интервьюера две вещи. Первая: что именно должно пахать офлайн — только чтение или запись тоже? Это небо и земля по сложности. Чисто чтение — задачка на кэш. Запись — уже та самая распределёнка. Вторая, и это гвоздь всей задачи: что делать, если геодезист поменял данные офлайн, а на сервере их за это время тоже кто-то поменял — например, коллега в офисе? Пока ты не ответил, как разруливать такой конфликт, — задача не закрыта.

Теперь как устроено внутри. Данные храним прямо на устройстве. Для структурированных данных — IndexedDB (это встроенная в браузер база; localStorage не годится — он крохотный и синхронный, тормозит всё вокруг). Картинки, стили, саму оболочку приложения кладём через Service Worker — это прослойка между приложением и сетью, которая отдаёт сохранённое, когда интернета нет. Читаем офлайн — берём из локальной базы. А с записью интереснее: когда человек что-то меняет без сети, мы не пытаемся тут же достучаться до сервера, а складываем изменение в локальную очередь. Появилась сеть — по очереди, в том же порядке, отправляем всё накопленное.

И вот мы уперлись в главное — в конфликты. Тут надо не просто сказать «ну разрулим», а назвать конкретный подход и объяснить, почему он. Самый простой — кто последний записал, того и правда. Работает, но молча затирает чужие изменения, а для замеров по объекту это чревато: перезатёр чью-то правку — и на объект поедут неверные координаты. Честнее — версии: у каждой записи есть номер версии, и если геодезист пытается сохранить поверх данных, которые на сервере уже обновились, сервер такое отклоняет, и мы решаем, что делать. Самый аккуратный, но и самый муторный вариант — сливать изменения по отдельным полям: один поправил координаты точки, другой — её описание, оба изменения выживают. Важно не назвать «правильный» ответ (его нет), а показать, что ты понимаешь разницу и осознанно выбираешь под ситуацию.

Ещё пара вещей, без которых разбор неполный. Синхронизацию лучше делать в фоне — есть Background Sync, который сам достучится до сервера, когда связь вернётся, даже если вкладку уже закрыли. И обязательно — честно показывать статус. Если человек поменял что-то офлайн, а на экране всё выглядит как «сохранено», он уйдёт довольный, а изменения висят в очереди и могут вообще не уехать. Маленькая плашка «изменения ещё не отправлены» снимает кучу боли.

Если совсем коротко: тут проверяют, понял ли ты, что offline-first — это не «кэш прикрутить», а полноценная распределёнка со своими конфликтами и с тем, что данные какое-то время живут несогласованными. Назвал конкретную стратегию разрешения конфликтов и вспомнил про честный статус для пользователя — значит, в теме.

Подписаться: @codeof_art
Вступить в чатик: @code_of_art