Кожна інтеграція — це обіцянка, яку дає чужа команда й яку ти не контролюєш. Їхній API колись відповість повільно. Колись поверне помилку, якої немає в документації. Колись просто ляже посеред дня. Питання не в тому, чи це станеться, а в тому, чи потягне їхнє падіння за собою й твою систему.
Найпоширеніша помилка, яку я бачу, — синхронний ланцюжок довіри. Твій сервіс кличе чужий, чекає відповіді, тримає з'єднання. Чужий гальмує — твої запити стають в чергу. Черга росте — закінчуються потоки. Потоки закінчились — уже й твій сервіс не відповідає власним клієнтам. Один повільний зовнішній API поклав систему, яка технічно взагалі не ламалась. Це і є каскад: чужа проблема стала твоєю через відсутність межі.
Тому я ставлюсь до кожної зовнішньої залежності як до тимчасово ненадійної. Таймаути — завжди, і короткі, а не «за замовчуванням тридцять секунд». Circuit breaker, щоб перестати гатити в сервіс, який очевидно лежить, і дати йому піднятись. Ретраї з backoff та джитером, а не десять миттєвих повторів, які лише добивають того, хто вже задихається. Ідемпотентні ключі, щоб повтор не створив другого платежу чи другого замовлення.
Окремо — деградація замість падіння. Якщо сервіс рекомендацій лежить, сторінка товару має показатись без рекомендацій, а не з помилкою. Якщо не відповідає система знижок, замовлення оформлюється за повною ціною, а перерахунок іде фоном. Користувач майже завжди пробачить трохи менше функціоналу. Він не пробачить білий екран.
І контракти. Я ніколи не вірю, що чужий API повертає рівно те, що написано в доці. Валідую вхідні дані на своєму боці, ставлюсь до відсутнього поля не як до катастрофи, а як до очікуваного випадку. Версіоную свої API так, щоб мати змогу змінюватись, не ламаючи тих, хто інтегрувався зі мною.
Стійка інтеграція — це не та, де всі сервіси ідеальні. Таких систем не буває. Це та, де падіння одного вузла лишається падінням одного вузла й не перетворюється на падіння всього.
– Sergey Shinder
