Как я понял, задача сводится к общению в классическом примере слабой связи между объектами - типа однонаправленного интерфейса. Классический веб к этому относится. Также обычно происходит общение через однонаправленные порты, типа serial port. Ну или всякие MVC-MVVM с их "запретом" на движение данных в двух направлениях одновременно.

Data exchange between component models in a unidirectional composition... | Download Scientific Diagram (researchgate.net)

Сюда же косвенно относится Dependency inversion principle с точки зрения потоков информации.

Тогда ты создаёшь систему состояний на сервере, и клиент, создавая запросы входит в эти состояния. Сервер отсылает клиенту инфу, в каком клиент сейчас состоянии для сервера. В принципе, таким образом обработку любого запроса можно раздуть до любого времени - необязательно укладываться в таймайт ответа от сервера - хоть годами обрабатывать. И состояние может быть сколь угодно сложным. И обработка может даже прерываться и возобновляться. Классический пример - ММО игры. Игрок проходит игру, качается по уровням - для сервера это как обработка большого запроса на доведение игрока до конца игры. Эта обработка может длиться годами, а игрок может брать сколь угодно долгую паузу в любой момент обработки.

Ну и состояние может храниться и на клиенте и отсылаться серверу, чтобы сам сервер его не сохранял. Но опять же, если севрер не доверяет клиенту, то лучше, если сам сервер будет всё хранить или хотя бы дублировать дынные клиента. Короче, всё опять сводится к классической схеме клиент-серверных ММО с недоверчивым сервером, который сохраняет состояние клиента и верифицирует его.

Ещё раз, готовые библиотеки скорее всего всё это тоже делают, только инкапсулируют и предоставляют простой и удобный интерфейс наружу. Какие-нибудь навороченные - вообще поднимают сервер на клиенте, как тут уже говорили. Но последнее можно сделать разве что для платформ с широкими полномочиями, которые могут, скажем, запускаться как отдельные программы на машинах клиентов или как службы в операционной системе... или можно сделать клиентский сервер на джаваскрипт, живущий в контексте текущего запроса, но сохраняющий свои данные в куки и восстанавливающийся, если запрос прервался?

Впрочем, всё вышеописанное настолько усложнено, что, я думаю, запросы топикстартера скорее уложатся в таймаут ответа сервера, чем потребуется создание системы состояний... Кроме случая потери связи с сервером.