# Какая технология/концепция лучше всего подходят работы агрессивными (резкими) пиками нагрузки и почему?
Примеры систем, где такие резкие высокие пики нагрузки потенциально возможны: системы массовой рассылки уведомлений (pub/sub для паблик клиентов, а не внутренних сервисов).
В случае stateless сервисов всего подходят для этого ***Бессерверные Вычисления*** (***Serverless Computing***).
Но в случае stateful сервисов можно прибегнуть к брокерам сообщений + нададить автомасштабирование обработчиков сообщений.

# Какие есть основные стратегии работы с ошибками в обработчиках (консьюмерах) сообщений очередей?
1. Повторные попытки (Retry): Автоматически повторять попытку обработки сообщения при возникновении временной ошибки.
2. Dead Letter Queue (DLQ): Перенаправление сообщений, которые не могут быть обработаны, в специальную очередь (DLQ) для последующего анализа и обработки.
Важно, чтобы было озвучено (или можно уточнить понимание), что есть Recoverable ошибки (сбои внешних систем, необходимых для обработки, сетевая нестабильность, просадка по ресурсам) и Non-recoverable ошибки (некорретный формата данных, ошибки в бизнес-логике обработчика, например, когда сообщение содержит запрос на выполнение невозможной операции). И что Recoverable ошибки лучше обрабатывать по 1-ой стратегии, а Non-recoverable - по 2-ой.

# Какие нюансы подбора нужных значениях таймаутов при взаимодействии сервисов?
Здесь главное, чтобы было сказано как можно больше чего-то кроме "да можно примерно на глаз ебануть" или "тут лучше переборщить".
Основные моменты, которые было бы круто, если будут освещены:
* backoff стратегия для увличения таймаутов (в идеале даже упомянуть проблему "thundering herd" ("грохочущее стадо");
* чем менее жесткие таймауты, тем выше отказоустойчивость межсервисного взаимодействия (меньше сыплется ошибок);
* чем более жесткие таймауты, тем выше надежность (Reliability), так как DevOps'ы/SRE как можно быстрее увидят точки отказа;
Правильный выбор зависит от SLA и требований к надежности (Reliability).

# Чем healthcheck'и отличаются от heartbeat'ов и когда чего использовать?
Основное отличие - это направление: healthcheck'и система мониторинга или один сервис должен сам запрашивать у другого, а heartbeat'ы - это то, что тот другой сервис сам присылает системе мониторинга или текущему сервису.
В большинстве случаев healthcheck'ов всем хватает, однако, если:
* нет возможности напрямую опрашивать сервис (он за NAT'ом, например);
* нужно реагирование на изменение состояния с минимальной задержкой;
то можно задуматься о heartbeat'ах.

# Какие паттерны обеспечения надежности (Reliability) межсервисного взаимодействия знаешь?
Retry Pattern, Circuit Breaker, Bulkhead, Timeout, Failover, Fallback, Rate Limiting, Cache, Queue, Batching и др