Что произойдёт, если загрузить новый объект с тем же key, что уже существует

Поведение зависит от хранилища: в key‑value и object storage новый объект с тем же ключом почти всегда перезаписывает старый (last write wins), а при включённом версионировании старая версия просто уходит в историю. В реляционных базах данных с уникальным ограничением такая запись обычно приведёт к ошибке, если не использовать явный `UPDATE` или UPSERT. В любом случае одновременно два «активных» объекта с одним и тем же ключом обычно невозможны — либо перезапись, либо ошибка.

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

В типичных object storage (S3‑подобные хранилища) и key‑value системах (например, Redis, Memcached) действует правило «последняя запись побеждает»: новое значение по ключу заменяет старое, и при обычном чтении старые данные больше не доступны. Если включено версионирование, старый объект сохраняется как предыдущая версия и может быть прочитан по явному идентификатору версии, но по голому ключу всегда будет возвращаться последняя успешная запись.

В реляционных базах данных с уникальным индексом или первичным ключом на поле `key` (или `id`) простая операция `INSERT` с уже существующим значением ключа приведёт к ошибке нарушения уникального ограничения. Чтобы явно задать желаемое поведение, используют отдельные операции обновления (`UPDATE`) или специальные UPSERT‑конструкции, которые либо вставляют новую строку, либо обновляют существующую в одной атомарной операции.

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

• Разрешена ли перезапись объектов по одному и тому же ключу, или требуется всегда создавать новые ключи.
• Нужно ли включать версионирование, чтобы иметь возможность увидеть историю изменений и откатиться к старой версии.
• Как обрабатываются конкурентные записи (например, через ETag/`If-Match`, оптимистические блокировки или версии строк), чтобы избежать ситуаций, когда два клиента по очереди затирают данные друг друга.

На собеседовании полезно подчеркнуть, что по умолчанию либо применяется стратегия last write wins (перезапись объекта), либо операция завершается ошибкой уникальности, а конкретное поведение зависит от типа и настроек выбранного хранилища.