TGViewer
BA & SA | 10000 Interview questions BA & SA | 10000 Interview questions @systemanalystinterview · 10.3K subscribers
Post #12240 568
☀Объяснение:

Проблема с немедленными повторами:
Если внешний API временно перегружен или восстанавливается после сбоя, множество клиентов, увидев ошибку, начнут повторять запросы одновременно. Это создаёт «шторм повторных попыток» (retry storm), который ещё сильнее перегружает сервис и затягивает его восстановление. Фиксированная задержка (например, 1 секунда) синхронизирует все повторы, создавая пиковые всплески нагрузки.

Что такое экспоненциальная задержка с джиттером:
Экспоненциальная задержка (Exponential Backoff) – интервал между повторами увеличивается в геометрической прогрессии: 1с, 2с, 4с, 8с, 16с. Это даёт внешнему сервису время на восстановление и разносит пики нагрузки во времени.
Джиттер (Jitter) – добавление случайного небольшого смещения (например, ±30%) к каждой задержке. Это предотвращает синхронизацию повторов от разных клиентов. Например: 1.2с, 2.5с, 3.8с, 9.1с вместо строгих 1, 2, 4, 8.
Пример реализации (Python):
python
import time, random

def call_with_retry(func, max_retries=5, base_delay=1):
for attempt in range(max_retries):
try:
return func()
except Exception:
if attempt == max_retries - 1:
raise
delay = (base_delay * (2 ** attempt)) + random.uniform(0, 0.5)
time.sleep(delay)

Сравнение с другими вариантами:
A (фиксированная задержка) – приводит к синхронизированным пикам нагрузки, создаёт retry storm.
C (единственный повтор через 10 секунд) – недостаточно надёжен для кратковременных сбоев, не даёт шансов на восстановление.
D (без повторов) – снижает надёжность системы, пользователь получает ошибку даже при временной проблеме.

Реальный пример:
AWS SDK для вызовов к S3 и DynamoDB реализует экспоненциальный backoff с джиттером по умолчанию. Stripe также рекомендует эту стратегию для обработки временных ошибок.

Что должен зафиксировать аналитик:
«При интеграции с внешними сервисами использовать повторные попытки с экспоненциальной задержкой и джиттером».
«Максимальное количество попыток — не более 5».
«После исчерпания попыток — помещать сообщение в Dead Letter Queue (DLQ) для ручного разбора».

Вывод: Экспоненциальный backoff с джиттером – это отраслевой стандарт для отказоустойчивых интеграций, предотвращающий перегрузку внешних систем и повышающий вероятность успешной обработки запроса.
More from @systemanalystinterview
  1. Sep 3, 2026А ИИ действительно экономит время? На деле ИИ может взять на себя рутину: анализировать да…
  2. Aug 26, 2026До 1 сентября остаётся меньше недели, и мы с вами официально вступаем в самую активную пор…
  3. Aug 21, 2026Если вы работаете в сфере IT, развиваетесь в технологиях или просто хотите быть в курсе са…
  4. Aug 20, 2026🔈 Как найти работу в 2026 году Вы все слышали о том, что происходит с рынком труда (если…
  5. Aug 20, 2026Post #12336
  6. Aug 20, 2026№4931 категория вопросов: #REQUIREMENTS
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →