ENIGMA AI
ENIGMA AI

Является ли Google Cloud Storage реактивным по своей природе?

встречается 1× Google Cloud Platform middle architecture

Как ответить

Короткий ответ: нет, Google Cloud Storage не является реактивным по своей природе. Это объектное хранилище с RESTful API, где запросы выполняются синхронно через HTTP или клиентские библиотеки. Никаких встроенных механизмов push-уведомлений или событийной модели там нет — всё строится на опросе (polling) или внешних триггерах.

Однако GCS легко интегрируется в реактивные архитектуры. Для этого используется механизм Cloud Storage уведомлений (Object Change Notification), который отправляет события в Cloud Pub/Sub при изменениях в бакете. Типичный сценарий:

  • Загрузка файла в бакет → триггер Cloud Storage отправляет сообщение в Pub/Sub → подписанная Cloud Function или Cloud Run обрабатывает файл (например, ресайзит изображение, запускает ETL).
  • События: OBJECT_FINALIZE (создание/загрузка), OBJECT_DELETE, OBJECT_ARCHIVE и другие.

Задержка между загрузкой объекта и получением уведомления обычно составляет менее секунды, но не гарантируется строго — это best-effort. Важно: порядок сообщений не гарантируется для конкурентных операций с одним объектом. Например, если файл быстро перезаписывают дважды, подписчик может получить уведомление о первой версии после второй. Поэтому обработчик должен быть идемпотентным.

Настройка уведомлений делается через gsutil или Terraform:

gsutil notification create -t my-topic -f json gs://my-bucket

После этого все события по умолчанию (create/delete) будут публиковаться в топик. Можно отфильтровать по префиксу/суффиксу объекта.

Таким образом, GCS не реактивен из коробки, но с Pub/Sub и serverless вы получаете реактивный пайплайн. Альтернатива — поллинг через list-запросы (не рекомендуется из-за задержек и стоимости). Для строгой реактивности с гарантированной доставкой и порядком лучше использовать Cloud Pub/Sub или Change Data Capture через BigQuery.

Ключевые тезисы

  • GCS — синхронное REST-хранилище, не имеет встроенной реактивной модели
  • Реактивность достигается через Cloud Pub/Sub + Cloud Functions/Cloud Run
  • События: OBJECT_FINALIZE, OBJECT_DELETE, OBJECT_ARCHIVE (best-effort, без гарантии порядка)
  • Обработчик должен быть идемпотентным из-за возможной повторной доставки
  • Поллинг бакетов — антипаттерн для реактивных сценариев

Что спросят дальше

  • — Как вы будете обрабатывать дублирующиеся уведомления от Cloud Storage?
  • — Что значит eventual consistency для уведомлений и как это влияет на архитектуру?
  • — Как реализовать строгий порядок обработки изменений одного объекта?

Готовьтесь к собеседованию с ENIGMA AI

AI-суфлёр подсказывает ответы прямо на собеседовании в реальном времени — незаметно для интервьюера.

Скачать приложение