В чем отличие асинхронного подхода от синхронного
Что проверяют
Аналитика спрашивают не про код, а про способ взаимодействия систем: понимаете ли вы, как выбор влияет на требования, сценарии и работу пользователя.
Как отвечать
Синхронное взаимодействие это запрос и ответ в одном обращении: клиент ждёт результат, и пока ответа нет, процесс стоит. Асинхронное это передача задачи дальше через очередь или событие: система отвечает «принято», а результат приходит позже отдельным сообщением или доступен по опросу статуса.
Что меняется для проектирования:
- пользовательский сценарий: в синхронном случае человек видит результат сразу, в асинхронном нужен экран ожидания, статус заявки, уведомление о готовности и понятный текст на случай долгой обработки;
- надёжность: асинхронный обмен переживает недоступность получателя, сообщения ждут в очереди. Синхронный вызов в этот момент просто падает;
- требования, которые обязан описать аналитик: таймауты и что показывать по их истечении, повторные попытки, идемпотентность (повтор не должен создавать второй заказ), порядок обработки, срок жизни сообщения, действия при неудаче после всех попыток;
- согласованность: асинхронность почти всегда означает согласованность в конечном счёте. Данные какое-то время расходятся между системами, и это надо описать явно, а не считать багом;
- отслеживание: сквозной идентификатор операции, чтобы поддержка могла найти заявку во всех системах.
Правило выбора простое: если ответ нужен прямо сейчас для продолжения сценария, берут синхронный вызов; если операция долгая, тяжёлая или зависит от внешней стороны, асинхронный.
Где спотыкаются
Описывают асинхронный процесс, но забывают про экран статуса и уведомление, и пользователь остаётся в неизвестности.
Не задают правила повторов и получают дубли операций.
Считают асинхронность всегда лучше. Для проверки кода из СМС или оплаты на кассе ожидание ответа обязательно.