Добавьте слой метаданных: users → buckets → objects, где объект связывает (bucket_id, key) с идентификатором внешнего Storage. Доступ проверяет ваш API.
Разработать упрощённый сервис, аналогичный S3
Добавьте слой метаданных: users → buckets → objects, где объект связывает (bucket_id, key) с идентификатором внешнего Storage. Доступ проверяет ваш API.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Условие
Предположим, что у нас уже существует файловый Storage, который не хранит никакой информации о метаданных файлов и предоставляет простой HTTP‑интерфейс: POST для загрузки файлов в хранилище (в ответ возвращается строковый идентификатор), GET для получения файла по этому идентификатору и DELETE для удаления файла из Storage. При проектировании сосредоточимся на базовом наборе функций, включающих создание пользователя, создание bucket'а для этого пользователя, загрузку объекта в bucket под заданным ключом и удаление объекта.
Ответ
Добавьте слой метаданных: users → buckets → objects, где объект связывает (bucket_id, key) с идентификатором внешнего Storage. Доступ проверяет ваш API.
Для загрузки сначала создайте запись операции со статусом uploading, затем передайте файл Storage и атомарно зафиксируйте storage_id и active-версию объекта. Уникальный ключ (bucket_id, key) и version check защищают одновременные записи. Правило перезаписи ключа должно быть явным.
Операции БД и внешнего Storage не образуют одну транзакцию: зависшие загрузки и сиротские файлы убирает reconciliation. При удалении сначала ставят tombstone и задачу очистки, DELETE повторяют идемпотентно. API проверяет владельца bucket и квоты; произвольный storage_id не должен обходить авторизацию. Создание пользователя и bucket также нуждается в уникальности и безопасной обработке повторов.