49-минутный доклад инженеров Netflix на QCon San Francisco оказался не про кнопку Delete, а про то, почему удаление данных в большой распределенной системе легко превращается в отдельную инженерную дисциплину. Для русскоязычных команд это знакомый сюжет: чем больше у компании хранилищ, кэшей и сервисов, тем выше шанс, что данные либо сотрутся не там, где надо, либо не сотрутся вообще.
О платформе для централизованного удаления данных в Netflix, как пишет InfoQ, рассказали Vidhya Arvind, техлид и один из первых архитекторов Data Abstraction Platform, и Shawn Liu, Senior Software Engineer, который занимается системами жизненного цикла пользовательских данных. Их главный тезис звучит без лишней романтики: удаление нельзя считать второстепенной задачей. Если оставить его на совести отдельных команд и разрозненных скриптов, компания получает смесь из операционных рисков, роста затрат на хранение и проблем с доверием пользователей.
Авторы доклада раскладывают задачу на три опоры: durability, availability и correctness. В переводе на практический язык это значит, что данные должны быть действительно удалены и не «воскреснуть» позже, рабочая нагрузка не должна просесть из-за фоновых операций, а сама логика удаления обязана оставаться корректной на всем пути между системами. Проблема в том, что у разных хранилищ эта логика разная. Cassandra работает с tombstone-маркерами и compaction, DynamoDB поддерживает TTL через фоновую обработку, Redis и EVCache удаляют данные с оговорками, связанными с ленивой очисткой и фрагментацией памяти, а RDS и Elasticsearch вообще требуют отдельных подходов вроде планировщиков, lifecycle management или mark-and-sweep-сценариев. На бумаге все это выглядит как набор штатных механизмов. В проде получается зоопарк компромиссов.
Важная часть выступления посвящена именно цене удаления. Когда в системе накапливается слишком много tombstones или фоновых задач на очистку, за это платят не только диски. Растет потребление CPU, подскакивают задержки, чтения начинают проходить через слои уже «мертвых» данных, а где-то на горизонте появляются timeout'ы. Для разработчиков это неприятный, но полезный холодный душ: удалить запись из приложения и реально убрать ее последствия из инфраструктуры — не одно и то же. Особенно если рядом живут кэш, поисковый индекс, реляционная база и еще пара внутренних сервисов, каждый со своей семантикой удаления.
Самый показательный эпизод доклада — не теоретический, а вполне боевой. Arvind вспоминает недавний инцидент в Netflix: из-за ошибки конфигурации в кластере Cassandra процессы не перезапускались дольше 24 часов. Когда узел выпал за этот порог и затем вернулся, данные, которые уже должны были исчезнуть, фактически появились снова. Докладчики называют это «ghosts in the system» — призраками в системе. На инженерном языке это классическое data resurrection: удаление вроде бы произошло, но из-за особенностей репликации, GC grace period и восстановления ноды старые данные возвращаются и снова попадают в рабочий контур. Для команд, которые привыкли считать delete идемпотентной и предсказуемой операцией, такая история быстро снимает иллюзии.
Отсюда и идея централизованной платформы. Вместо того чтобы каждая продуктовая команда по-своему удаляла данные из своей БД, кэша и вторичных индексов, Netflix делает ставку на единый уровень оркестрации. У такой схемы сразу несколько задач: запускать удаление по многим системам без удара по live traffic, контролировать накопление tombstones, непрерывно проверять, что запись действительно исчезла везде, и формировать доверие к процессу через аудит. Здесь особенно важен последний пункт. В распределенной архитектуре «команда отправлена» и «данные реально исчезли» — это два разных состояния. Если между ними нет постоянной проверочной петли, платформа превращается в красивую панель управления с сомнительной доказательной базой.
Для бизнеса и продуктовых команд вывод тоже довольно приземленный. Удаление данных — это уже не только про compliance, запросы пользователей или сроки хранения. Это про зрелость платформы. Когда компания растет, количество мест, где живет одна и та же пользовательская сущность, увеличивается естественным образом: основная БД, кэш, поисковый слой, аналитические витрины, асинхронные очереди, сервисы рекомендаций. Без единой модели удаления начинает расти технический долг, причем тихо: пока не случится аудит, инцидент или неприятная история с «удаленными» данными, которые все еще доступны через обходной путь. Для российских команд с микросервисной архитектурой, собственными data-платформами и смешанным стеком из PostgreSQL, Redis, Kafka, ClickHouse или Cassandra это звучит не как экзотика Netflix, а как довольно реалистичный roadmap проблем.
Практическая ценность доклада в том, что Netflix не продает серебряную пулю. Скорее, компания честно показывает: безопасное удаление данных — это постоянный торг между скоростью, надежностью и стоимостью операций. Чем жестче требования к корректности, тем больше нужно автоматизации, аудита и архитектурной дисциплины. И чем сложнее распределенный ландшафт, тем труднее оправдывать старую модель, в которой каждая команда «как-нибудь сама удалит». Следующий логичный вопрос для отрасли уже не в том, нужна ли централизованная платформа удаления, а в том, на каком масштабе без нее начинает становиться по-настоящему дорого.