Анализ точек отказа в системе

Условие

В схеме представлены основные элементы инфраструктуры: API‑шлюз (балансировщик нагрузки, аутентификация, TLS, ограничение запросов), сервис TinyUrl с методами POST и GET, кэш‑слой (LRU), распределённые SQL‑шарды с репликами, внешний генератор коротких ссылок, реализующий real‑lock, распределённый журнал/очередь, а также аналитическая подсистема.

Необходимо выявить критические места отказа:

• Определить, какие из компонентов являются единой точкой отказа (single point of failure, SPOF).
• Предложить способы повышения отказоустойчивости: репликация, автоматический перезапуск, стратегии повторных попыток, механизмы отката.
• Описать поведение системы при падении: генератора ссылок, отдельного шарда или его реплики, кэш‑слоя, очереди, обслуживающей аналитический модуль.
• Разделить компоненты на stateful и stateless.
• Сформировать перечень средств мониторинга и систем оповещения, необходимых для контроля над отказами.

Ответ

SPOF определяется числом независимых экземпляров и механизмом переключения, а не названием компонента. Особенно важны генератор кодов и лидеры шардов.

API обычно stateless и масштабируется репликами. БД, очередь и генератор с состоянием требуют репликации, устойчивого хранения и защиты от split-brain; кеш — восстановимое, но нагрузочно значимое состояние.

При отказе генератора можно временно запретить создание, сохранив переходы. Отказ кеша требует ограниченного fallback в БД, а не лавины запросов. При потере шарда переключение допускается только на подходящую реплику с понятной потерей данных. Аналитику буферизуют с ограничением очереди и явно выбранной политикой потерь. Мониторят ошибки, задержки, replication lag, очередь, cache hit rate, насыщение ресурсов; retries ограничивают и делают безопасными для повторов.