Архитектура распределённых систем ломается не в коде, а на границах ответственности

Архитектура распределённых систем ломается не в коде, а на границах ответственности

Когда автоматизация растёт, самая частая ошибка — собрать всё в один оркестратор. Он быстро превращается в точку отказа, а дальше начинается классика: ретраи, дубли, гонки состояний и ручные «подчистки». Правильнее разделять контуры: приём задач, их планирование, исполнение, аудит. Между ними — явные очереди и контракт на формат события, а не «вызов соседнего сервиса по памяти».

Статистика показывает следующее. Система устойчивее, если у каждого узла есть одна задача и один источник истины:
— очередь для буферизации и сглаживания пиков;
— идемпотентные операции на исполнителе;
— журнал событий для разборов и отката логики;
— отдельный слой дедупликации, а не надежда на удачу.

Оптимизируем пороговые значения. Таймауты, ретраи и лимиты параллелизма должны быть разными для чтения, записи и внешних интеграций. Универсальные настройки почти всегда вредят: они либо душат throughput, либо размножают ошибки. Если сервис может повторить действие без побочных эффектов — делайте его идемпотентным. Если не может — вводите корреляционный ключ и строгий контроль состояния.

Мониторинг в такой архитектуре нужен не ради красивой панели, а чтобы ловить расхождение между очередью, исполнением и журналом. Развертывание прошло в штатном режиме только тогда, когда после сбоя система умеет продолжить с того же места без ручного ремонта. Иначе это не автоматизация, а хорошо упакованная последовательность аварий.