Сильно зависит от бизнеса, задачи, бэка и дизайна.
Вообще есть две стратегии обновления данных - пессимистическая и оптимистическая.
1я - ожидание полной загрузки данных и в частности отказ от обновления их на фронте => стучимся на бэк если, например, изменили счет и все есть чтобы его мутировать.
Плюсы - проста в реализации; тривиальная обработка результата запроса; простой дизайн; не напрягаешь бэк с обработкой их кухни на фронте.
Минусы - постоянные запросы - постоянные ожидания. Крутящиеся спинеры, ездящие прогрессбары и мерцающие скелетоны, это все тут.
2я - принудительная выдача результата запроса и в частности мутация данных на фронте, без ожидания ответа на запрос.
Плюсы - время ожидания пользователя существенно сокращается; пользователю кажется что все летает => пользователь счастлив=)
Минусы - сравнительно с предыдущей сложна в реализации; вереница доп. обработок ошибок; в некоторых случаях необходим продуманный UI/UX; иногда приходится перенести на фронт то что было на бэке (порой из за того что они одеяло слишком перетянули)
Если вы думаете стоит ли оптимистическую стратегию внедрять архитектурно, нужно прежде всего понимать каков это гемор.
Если же местечково, для обновления счета например, то почему бы и да?!