Лимиты и идемпотентность

При работе с Control Plane полезно разделять две темы:

• продуктовые лимиты аккаунта;
• устойчивость автоматизации к сетевым сбоям и повторным вызовам.

Продуктовые лимиты

Для trial‑плана действуют hard limits по количеству tenants, баз, compute‑времени и egress. Поэтому при массовой автоматизации стоит заранее учитывать, на каком плане работает аккаунт.

Идемпотентность: безопасный практический подход

Для API v2 лучше не строить критичную automation на предположении, что любая write‑операция поддерживает специальный Idempotency-Key. В текущем пользовательском контракте полезнее следовать более надёжному шаблону:

1. отправить write‑запрос;
2. при сомнительном результате перечитать состояние ресурса;
3. только потом решать, нужен ли повтор.

Почему это важно

Создание и удаление ресурсов в SPG99 могут быть асинхронными. Поэтому один и тот же объект может какое‑то время находиться в creating или deleting, и повторный blind‑retry здесь только запутает automation.

Хорошая стратегия

• используйте GET как главный источник истины после спорной write‑операции;
• логируйте payload и ответ API;
• не повторяйте destructive‑действия до проверки состояния;
• проектируйте automation так, чтобы она была устойчива к 409 Conflict и LimitExceeded.

Такой подход обычно надёжнее, чем попытка любой ценой сделать «идеально идемпотентный create» поверх динамического serverless‑каталога.