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

Сходил на собеседование в Шушу. Предложили интересную задачу: спроектировать агрегатор проституток. Смотрим! Смотрим! По ссылке:

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

System Design: backend

Сегодня разберём задачу, которую мне давали на собесе в Яндекс. Штука на стыке проектирования и алгоритмов: мало накидать красивую схему на доске — надо ещё нормально объяснить, как данные поедут через систему. И вот тут сразу видно, шаришь ты или просто заучил модные слова.

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

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

Но прежде чем что-то проектировать, я бы задал интервьюеру один вопрос. Как по мне, ради него задачу и придумали. Что делать, если данные сожмутся хуже обещанного, и очередной сжатый кусок всё равно вылезет за 100 мегабайт? Полтора-три раза — это как средняя температура по больнице, а не гарантия. Попадётся кусок, который жмётся плохо (уже сжатое видео, случайный мусор), — и он не влезет в лимит. Если ты сам спотыкаешься об этот момент, до того как тебя носом ткнули, — считай, полдела сделал: дальше этот вопрос всё равно вылезет. Заодно спроси, нужна ли параллельность и надо ли уметь продолжить с места обрыва, если всё грохнется на середине.

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

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

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

И ещё пара штук, которые отличают продуманное решение от учебного. Первая — контрольная сумма на каждый кусок. Иначе бэкап может тихо побиться, а узнаешь ты об этом в самый неподходящий момент — когда полез восстанавливаться, а там каша. Вторая — уметь продолжить с последнего нормально записанного куска, а не гнать терабайт по новой из-за обрыва на 90%. Для этого достаточно отмечать, что уже доехало.

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

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

Товарищи, Поступашкам нужны контент мейкеры в основной канал по алгоритмам и другим дисциплинам. Если вы творческая личность, интересующейся алгоритмами (или другим), вам нравится писать посты/ придумывать идеи для контента, то обязательно пишите @vice22821. Оплата сдельная, ориентировочно за один пост от 2 тыс до 15 тыс рублей.

Обязательно делитесь с ребятами, которым это может быть интересно.